Traits, tests and things I learned

Traits
In the Merriam Webster, a trait is defined as:
an inherited characteristic
a distinguishing quality

In programming languages that support it, for example PHP, Java, Rust, etc., a trait provides a set of methods that implements behaviour to a class, and require that the class implement a set of methods that parameterise the provided behaviour.

An object defined as a trait can be used by other classes without requiring multiple inheritance. When you use multiple traits that have a method with the same name in it, you must distinguish which trait method to use to resolve the conflict. In PHP, you can resolve trait method conflicts by using the word “insteadof”. Here’s an example below:

When you use the container class, instantiate the Container object, and use the exampleMethod method, it will output “Example” because we wrote in the class to use the ExampleOne trait method instead of the ExampleTwo method trait.

Traits can be seen as a “mixin”. A mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes.

Testing with Static Analysis

This morning I did a random search on PHP on Twitter, just to see what people were talking about. This morning Fabien Potencier (His website: http://fabien.potencier.org/) wrote a tweet “If your unit tests cover 100% of your code, you’re doing it wrong. Just my 2 cts.” In the thread of replies to this tweet, another person linked to an article he wrote about strong types and static analyses. You can see the article link in the references section.

The concept posed in this article is very interesting. I haven’t thought of doing something like what he wrote. Ondrej Mirtes wrote that “…our aim as software developers is to make sure it does what it ought to do and to keep the number of defects as low as possible. We should also strive to make our lives easier, to counter external circumstances like tight deadlines and ever-changing requirements causing the exact opposite. That’s why we’re always looking out for tools and practices to help us with our jobs.”

What Ondrej is proposing is to use type safety in your code. If you make your code type-safe, you don’t need to have unit tests for every function you create. There will be many who agree and disagree with this idea, that you don’t need to write unit tests for every function even if you make your code type-safe, but I feel as a developer, we should constantly learn new things, and over time we can refine how we write code and improve the reliability and readability for everyone.

Instead of writing a function and checking if it’s null or undefined each time, you can create a class which does this for you. When you instantiate the class object, you would define the email address, if the email string is invalid, it throws an error, otherwise it will give you the ability to return the address string. When you create your new function, it accepts the class in the parameter. Using this method will force you to type all your code, thus reducing some values to be integer or null accidentally.

Interfaces

An interface can be seen as a collection of methods a class must implement, without defining how the methods must be implemented. All methods defined in an interface must be public. To use an interface, you use the “implements” keyword in a class.