One of the fundamentals of Object Orientation is no exposure of the implementation details of an object. I’ve talked a few times this in another articles.

So we use the encapsulation of the implementation, so do not put our objects and we have a better maintainability of our classes and since this encapsulation ensures the integrity of our objects can also ensure that the user will only be able to access our objects defined through a contract with a public interface.

But often we begin to implement these rules defining our attributes as private and only allowing access to these through getters and setters:

Read More…

When we read the name of the pattern Decorator would imagine that silly name, meaningless. Good is not as meaningless as well.

The Decorator works exactly as the name describes.

Definition:

Decorator is a design pattern software that allows you to add a behavior to an existing object at runtime, or dynamically adds additional responsibilities to an object.

This pattern adds responsibilities dynamically to a class, generating more flexible alternative for certain classes use subclasses through inheritance or composition.

Using Decorator, we have more momentum in the inheritance, we can use inheritance without the problem of transforming our class’s into God class’s.

To help us understand the pattern, let’s create a scenario and a code example.

Read More…