DEV Community: bakle

The Factory Method Pattern

bakle — Mon, 24 Jan 2022 12:09:17 +0000

Defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method let a class defer instantiation to subclasses.

When talking about factory method, we talk about a pattern that solves a common problem in software development (that’s why it’s a design pattern). That problem it’s called class dependency.

Of course it solves other problems and in this article I’m going to mention some of them.

So, according to the definition, we need to define an interface (remember that when we talk about interface is not necessary an “interface” type, it could be an abstract class or any super class). But what does the interface need to have? What methods we have to define? Also, does it need properties?

Well, the answer is simple, we need the Factory Method. Be careful that when we say that the interface needs the factory method it doesn’t mean that is the only method the interface can have. The Factory Method is the method that have all the logic to create an object.

Creating the class diagram

Let’s begin by creating the part where it say “Defines an interface for creating an object, but lets subclasses decid which class to instantiate.”

Pretty simple, right?

Now we have to complete the second part of the diagram. For this, we need to think that the subclass is in charge of creating the objects, and because this class decides which object is going to create, the only way to return the same type of an object is by creating another interface for this object.

What I mean with this is that if we have a ConcreteFactoryClass this class can instantiate different concrete classes. For example we can have a DatabaseFactory, and this factory can return an instance of MySQL, MongoDB, PostgreSQL, etc. This is not right because this factory needs to return a type that is common for every Database classes, and that is why every concrete database needs to implement an interface.

So, with this definition, the Factory Method Pattern class diagram looks like this.

Applying The Factory Method Pattern

Let’s imagine that we need to create multiple database classes like MySQL, PostgreSQL and MongoDB. They are simple classes that have some methods like “select”, “insert”, “update” and “delete”.

Each class know the syntax to execute each statement.

Our class diagram looks like this.

Notice that the create method in the factory is our FactoryMethod.

Questions you may ask

Why do we need a FactoryInterface if there is only one ConcreteFactory?

Each case is different, we provide an interface because we need to make sure that the ConcreteFactory have this method. In some cases is possible you could have many ConcreteFactories (maybe a company and its branch offices).

Why this pattern solve class dependencies?

Imagine if we have in the main class (where we use the factory) a lot of if statements asking if the type is “mysql” or “postgresql”, etc. For each specific case it instantiate the concrete class. Thus, the main class will depend on every concrete DB class. Applying the factory method, the main class will depend on the DB abstract class.

Can this pattern solve an Open-Close principle violation?

Of course, let's the take the example of the previous question (the one where we have many if statements). So every time we need to add a new concrete DB class we have to change the code of our main class. By applying the factory method, any new concrete class will be added in our factory not in the main class.

Code implementation

Factory Method Pattern

Follow me on: Twitter

The Observer Pattern

bakle — Sat, 30 Oct 2021 15:51:10 +0000

The Observer Pattern defines a one-to-many dependency between objects, so that when one object change state, all of its depedents are notified and updated automatically.

When we talk about the observer pattern you can think of a newspaper and its subscribers, or an application that has to send notifications to their users. In both examples we can define each actor as subject(i.e: newspaper) and observers(i.e: subscribers).

Let's take for example an e-commerce platform, so when a user makes a purchase they receive a notification about the order. For example, I can go to my settings and check the checkboxes to receive a notification via Email, SMS and Phone Call. So, when I make a purchase, an order is created and then I receive a notification for each channel.

If we see the image above, we can see that the relationship between the subject and the observers is the one-to-many relationship that we defined earlier.

The subject is the object that contains the state, and the observers use that state, so when the data changes in the subject (the order) the observers are updated.

Now that we understand the definition of the Observer Pattern we can take a look at the class diagram.

Explaining the class diagram

The Observer pattern class diagram tell us that we need to have two interfaces (when we say interface we are referring to a contract, not a specific interface type, we can define either an abstract class or an interface type). One interface defines the methods that any subject needs to implement, and the other interface defines the methods that observers need to implement.

Also, the Subject interface Has-A (Filled arrow) observer interface. This means that the subject needs to have the observers list.

Finally, we have our concrete classes that implements our interfaces, so we have the ConcreteSubject and the ConcreteObserver (There could be many ConcreteObserver)

Applying the class diagram

So, in the case of our example of the order and the notification channels we can have the following class diagram.

Benefits of this pattern

The Observer pattern provides an object design where subjects and observers are loosely coupled.

Why?

Because subject doesn’t depend on concrete classes but interfaces.
The only thing subject knows about an observer is that it implements an interface (The observer interface).
We don’t need to modify the subject to add new types of observers.

Variations

This pattern can have some variations, for example:

The way we register the observers (each observer could register themself via constructor or we could have an array to register all observers to the subject).
The way we get the data from the subject (subject can push the data to the observer or the observer can pull the data from the subject).

In conclusion, the whole idea of this pattern is to communicate a state to a group of objects in a loosely coupled way.

Code implementation

Observer Pattern

Follow me on: Twitter

Laravel URL Presenters

bakle — Tue, 08 Jun 2021 02:05:01 +0000

Usually, we always find new ways to make our backend code cleaner, readable and flexible by applying design patters, software principles, refactoring strategies, etc.

This time, the strategy we are going to apply is about communication of backend and frontend and how the backend code can provide much more information to our views.

Most of us render the application routes directly in the view, and sometimes we find that we are repeating these same routes along the view.

We can see that we are repeating the same url in lines #19 and #28. This is the good way, some people use (see line #2):

So, how can we make this a little bit cleaner and reusable along the application? Well, we can apply a Url Presenter.

There are many ways to do it, so I'm going to show you one of them.

Some people like to do it inside the model, which I think is not the best way because we are giving a responsibility to the model that should not have, I mean, why the model should know about urls?

Let's begin with the first step.

Creating an interface

When I talk about interface I mean that it could be an abstract class or interface, that depends on your need. This time we are going to make a simple interface for a url resource (index, show, edit, ...).

Creating concrete url presenter

Now, we just create a concrete url presenter, in this case we are going to create a UserUrlPresenter

Using the presenter

Let's suppose we have our UserController, we just have to pass the url presenter to the view.

Final view

Now, we can use the url presenter inside the view.

Bonus

I know I said that I am not a fan of url presenters inside the model, but I will give you an example of how to do it.

Creating the interface

Creating concrete url presenter

The presenter in the model

Using the presenter

Final View

Laravel fit models.

bakle — Sat, 03 Oct 2020 14:32:51 +0000

Time ago in the Laravel community, people were talking about how to balance responsibilities between models and controllers. Some people say that it was better making fat models and thin controllers, while others say the opposite. This time I'm going to talk about a strategy to reduce a model when it becomes too "fat".

The concept of "fit models" came up from the need of reducing the amount of methods within a model. Months ago I was looking and thinking for a better way to reduce the amount of methods in a "fat" model and I came up with a solution, and searching for some articles I didn't found anyone who applied this, until I recently found that Freek Van Der Herten tried this same approach.

In a medium-large scale application is normal to have lots of methods for relationships, accessors, mutators and more.

Let's look at this example:


class User extends Authenticatable
{
    use HasFactory, Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password',
        'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
        'birth_date' => 'datetime',
    ];

    public function posts(): HasMany
    {
        return $this->hasMany(Post::class);
    }

    public function followers(): HasMany
    {
        return $this->hasMany(Follower::class);
    }

    public function favorites(): HasMany
    {
        return $this->hasMany(Favorite::class);
    }

    public function socialNetworks(): HasMany
    {
        return $this->hasMany(SocialNetwork::class);
    }

    public function addresses(): HasMany
    {
        return $this->hasMany(Address::class);
    }

    public function phones(): HasMany
    {
        return $this->hasMany(Phone::class);
    }

    public function messages(): HasMany 
    {
        return $this->hasMany(Message::class);
    }

    public function getFullNameAttribute(): string
    {
        return $this->first_name . ' ' . $this->last_name;
    }

    public function getShortNameAttribute(): string
    {
        return $this->first_name . ' ' . Str::limit($this->last_name, 1);
    }

    public function getAgeAttribute(): string
    {
        return now()->diffInYears($this->birth_date);
    }

    public function getCreatedDateAttribute(): string
    {
        return $this->created_at->toFormattedDateString();
    }

    public function getProfilePicturePathAttribute(): string
    {
        return storage_path('pictures/' . $this->id . '/' . $this->profile_picture);
    }

    public function setFirstNameAttribute(string $firstName)
    {
        $this->attributes['first_name'] = Str::studly($firstName);
    }

    public function setLastNameAttribute(string $lastName)
    {
        $this->attributes['last_name'] = Str::studly($lastName);
    }
}

This User model has some relationships, accessors and mutators, also remember that methods could increase a lot. At this time we can see too many things in our code and it is hard to read despite it's not a "fat" model.

Moreover, in a collaborative project developers try to define how to organize those methods. In the previous code we saw that relationships were first, then accessors and then mutators. When new relationships or accessors come in, developers will try to keep that structure, but when the team is growing new developers will add new methods wherever they want, making this previous structure a mess.

Traits to the rescue

So, what are traits? In simple words, they are a way to reuse code and reduce limitations of single inheritance. Although, a trait is something that can't be inheritable and is more like an extension of a class.

What if we separate each type of methods and put them in a trait? This way we can create a specific trait for each one. For example, we can create a HasUserAccessors for keeping all user's accessors and a HasUserMutators for keeping all user's mutators.

With this approach our User model will look like this:

class User extends Authenticatable
{
    use HasFactory, Notifiable;
    use HasUserAccessors;
    use HasUserMutators;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password',
        'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
        'birth_date' => 'datetime',
    ];

    public function posts(): HasMany
    {
        return $this->hasMany(Post::class);
    }

    public function followers(): HasMany
    {
        return $this->hasMany(Follower::class);
    }

    public function favorites(): HasMany
    {
        return $this->hasMany(Favorite::class);
    }

    public function socialNetworks(): HasMany
    {
        return $this->hasMany(SocialNetwork::class);
    }

    public function addresses(): HasMany
    {
        return $this->hasMany(Address::class);
    }

    public function phones(): HasMany
    {
        return $this->hasMany(Phone::class);
    }

    public function messages(): HasMany 
    {
        return $this->hasMany(Message::class);
    }

}

Better?

In fact, we can go further by creating a HasUserRelationships:

class User extends Authenticatable
{
    use HasFactory, Notifiable;
    use HasUserAccessors;
    use HasUserMutators;
    use HasUserRelationships;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password',
        'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
        'birth_date' => 'datetime',
    ];

}

I know that some of you will say that is not a valid approach because we are not reusing a trait and it goes against the definition of trait, but remember that just because something can be reused doesn't mean that you have to. For example, classes can be extended but do you extend every class? Of course not, you create them for specific purposes with no need to apply inheritance.

Remember when I said that traits are not inheritable? It is because you cannot have a class that extends a trait, also you can't hide a trait's properties. If you have a private property inside a trait, when you use that trait in a class that class will own the property, it is like creating the property directly inside the class.

This is why I think using traits to reduce models is totally valid because is like creating methods inside the model but making the model looks fit.

Laravel assertions: The difference between asserts.

bakle — Sun, 16 Feb 2020 22:09:12 +0000

Laravel assertions: The difference between asserts.

I'm sure that most of us have had the doubt of which assertion to use when we are testing our application.
Many times we use them without knowing how they really work.

It's true that some of them are confusing, but each one has it own purpose, even though they are similar.

Let's see some of them.

assertOk() Vs assertSuccessful()

Let's see what assertOk() does:

public function assertOk()
{
    PHPUnit::assertTrue(
        $this->isOk(),
        'Response status code ['.$this->getStatusCode().'] does not match expected 200 status code.'
    );

    return $this;
}


public function isOk(): bool
{
    return 200 === $this->statusCode;
}

As we can see, this assertion show us that the response status code must be excatly 200.

This assertion is useful for cases when we want to check exactly this status 200. For example, when we make a get() request.

Now, let's see what assertSuccessful() does.

public function assertSuccessful()
{
    PHPUnit::assertTrue(
        $this->isSuccessful(),
        'Response status code ['.$this->getStatusCode().'] is not a successful status code.'
    );

    return $this;
}


public function isSuccessful(): bool
{
    return $this->statusCode >= 200 && $this->statusCode < 300;
}

This assertion is not precisely to verify a 200 status response code.
If we use this to check an HTTP response and the response code is 200, it will pass.
But, what would happen if the response is 201 (Created) or 204 (No content)?
Do we want this response code or we really want a 200?

Check HTTP Response Status codes here.

assertSee() Vs assertSeeText()

Let's see what assertSee() does:

public function assertSee($value)
{
    PHPUnit::assertStringContainsString((string) $value, $this->getContent());

    return $this;
}

So, what this assertion does, is getting the content of the response and then checks if the value we are passing is within the content.

For example, if we want to check if the content has "My App" in somewhere, we do this:

$this->assertSee('My App');

But what if the content is wrapped inside a span tag like this:

My <span class='text-blue'>App</span>

The assertion we did before will fail. But why?

Because in the content we have My App and we are looking for My App without anything else around.

So, this assertion is helpful when we want to check a whole HTML tag too, for example, if we want
to check that in the content we have a link to Google and the link text is "Google", we could do this.

$this->assertSee('<a href="https://www.google.com/">Google</a>');

Now, let's see what assertSeeText() does.

public function assertSeeText($value)
{
    PHPUnit::assertStringContainsString((string) $value, strip_tags($this->getContent()));

    return $this;
}

Can you see the difference?

Yes, the only difference is the strip_tags() function.

This function removes all HTML and PHP tags in the content, so in the previous example (My App), the strip_tags() will remove the  tag and the content will be My App.

Then, what will happen if we have My App and we do

 $this->assertSeeText('My App');

It will work, because all HTML and PHP tags will be removed before it checks if the string is within the content.