Design Pattern & SOLID Design

Finally I get to learn about this pattern that haunts me, everytime they talk about this and I had no idea what were they.

Design Pattern

- Decorator pattern

In my own word . this is like implementing interface but it adds another subclass with a constructor if needed. when would be appropriate to use this pattern or maybe like inheritance? ask yourself would you be needing the whole function of the class(inheritance) or maybe just to adjust specific function.

- Adapter pattern

This is to make the same class but wrapped in different behavior. Like open a book in real is is to open a book but to open a book in Kindle open book in Kindle way- the template method pattern. Extract the same method to an abstract class Abstract in a abstract class, Any subclass is required to get this method

- pick a strategy

define a family of algorithm2. encapsulate and make them interchangeable

- the chain of responsibility

gives us the ability of chain object calls while giving each object the ability to either end the execution and handle the request or if it can't handle the request it'll send of the request of the chain. Benefit to this approach when its relevant, the client can make a request without knowing how that request was made

- the specification pattern

It allows you to take any business rule and promote it to a first class citizen.

- observer pattern

the change in one object need to have a nice flexible decoupled way to notify other object of this change and that way they can respond how the need to.

Solid Design

- Single Responsibility

a class should have one, and only one, a reason to change
an object should only have a single reason to change
When there are multiple objects, you should extract  them to a dedicated object

- Open closed

Entities should be open for extension but closed for modification
Change the behavior of the class without modifying source code
Avoid code rot
Separate extensible behavior behind an interface and flip the dependencies
whenever you find yourself type checking, you are breaking this rule
The goal is to get a point where you can never break core system

- Liskov substitution

Let q(x) be a property provable about object x of type T then q(y) should be provable for objects y of type S
where is a subtype of T
derived classes must be substitutable for their base class

1. signature must match
2. precondition can't be greater
3. post condition at least equal to
4. exception type must match simple explanation : the output should be same, or add blockdoc for output

- Interface segregation

a client should not be forced to implement an interface that it doesn't use

- Dependency inversion

Depend on abstraction not on concretion
dependency inversion is not equals to dependency injection
all of this is about decoupling code
high level code isn't as concerned with detail
slow level code is more concerned with details and specifics

Subscribe to You Live What You Learn

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]