The principle states that classes should achieve code reuse through aggregation rather than inheritance. For example the Composite design pattern and the Decorator design pattern use this approach.

The idea here that concrete classes can delegate tasks for other concrete classes. Delegation will provide loser level coupling then inheritance. Hence, provide your system more flexibility.

Disadvantages of Composition:

The biggest drawback of composition is that you must provide implementations for all behavior without the benefit of inheritance to share code. This means that you might have very similar implementations across the classes.

To manage complexity, one idea is that a class should be designed so that it does not need to know about and depend upon almost every other class in the system. By limiting which classes communicate with each other, you can enforce the principle of Least Knowledge. This principle is also realized in a rule known as The Law of Demeter.

The underlying idea of this Law is that classes should know about and interact with as few other classes as possible. This means that any class should only communicate with its “immediate friends”. These “friends” would be other classes that one class should only know about. It helps to reduce coupling and provide stability to a system.

• A method, M, is an object, O, can call on any other method within O itself (encapsulated within the same object).
• A method M, can call the methods of any parameter P (encapsulated within an object that is in the parameters of M).
• A method M, can call a method, N, of an object, I, if I is instantiated within M (encapsulated within an object that is instantiated inside of M).
• Any method, M, in object O, can invoke methods of any type of object that is a direct component of O (encapsulated within an object that is referenced in an instance variable of the class for M).

To summarize the rules, a method should not invoke methods of any object that is not local.

Classes should know as little as possible about your system as a whole, this will help to reduce amount of coupling and prevent unwanted effects from cascading through your entire system.

The Interface Segregation principle states that a class should not be forced to depend on methods it does not use. This means that any classes that implement an interface, should not have “dummy” implementations of any methods defined in the interface. Instead, you should split large interfaces into smaller generalizations.

The example before applying the Interface Segregation principle:

The best way is to apply Interface Segregation principle applying splitting the ICashier interface into 2 smaller. This will allow each interface to be more accurate with its description of expected behaviors, and it will allow you to pick and choose which correct combinations of interfaces a concrete class should implement.

Continue reading “SOLID (I) – Interface Segregation Principle” →

Classes should be open for extensions but closed for change.

You should consider a class as being “closed” to editing once it has been:

• Testing to be functioning properly.
• All the attributes and behavior are encapsulated.
• Proved to be stable within your system.

Once you’ve reached a point in development where you’ve already finalized most of your design decisions, and have implemented the most of your system, then you should consider “closing” your classes. It’s needed to avoid introducing undesirable side effects (of course it’s still acceptable to modify the code if need to fix bugs).

Continue reading “SOLID (O) – Open/Closed Principle” →

Dependency is an important topic, because it will determine how easily you can make changes to your system. The Dependency Inversion principle help to make a system more robust and flexible.

The principle states that high level modules should depend on high level generalizations, and not on low level details. This means that the client classes should depend on an interface or abstract class instead of referencing to concrete resources.

High level resources: interfaces and abstract classes.

Low level resources: concrete class.

Class diagram comparison between the low and high level resources:

Continue reading “SOLID (D) – Dependency Inversion Principle” →

In simple words: the subclass should be able to substitute a base class when needed and don’t lost sense/don’t change behavior after substitution.

As inheritance allows the subclass to become polymorphic, because inheritance lets the subclass become a subtype of the base class.

Subtyping also allows subclasses to be used as substitutes for their base class. Substitution states that:

Any class, S, can be used to replace a class, B, if and only if, S is a subtype of B.

Simply put, any subclass can stand in for its base class. Because of inheritance, a subclass is expected to have the same characteristics and behave in the same way.

The base class is the more generalized class, and therefore, its attributes and behaviors should reflect it. The names given to the attributes and methods, as well as the implementation of each method must be broad enough that all subclasses can use them.

If inheritance is not used correctly, it can lead to a violation of the “Liskov Substitution Principle”. This principle uses substitution to determine whether or not inheritance has been properly used. The Liskov Substitution Principle states that:

If a class, S, is a subtype of a class, B, then S can be used to replace all instances of B without changing the behaviors of a program.

Continue reading “SOLID (L) – Liskov Substitution Principle” →

The pattern is useful when UI is needed.

The Model contains the underlying data and logic that users want to see and manipulate. A key part of the MVC pattern that the model is self-contained. It has all of the state, methods and other data that it needs to exist on its own. Model focuses solely on managing the information for the system.

The View gives a user a way to see the model or at least parts of it (with buttons, images and other user interface). Responsible only for visual appearance of the system.

The Controller corresponds with control object that receives the events and coordinate actions.

Imagine the next situation, you have the smart home where devices communicate to each other and do one or another action dependent on the state of another device.

The visualization looks complicated and will be even more complicated if needed additional connections between the devices. To simplify the design, must to implement the Mediator pattern, this is how it should looks:

Continue reading “Mediator Pattern” →