Solid principles/ Software architecture/ By Nima Shokouhfar

1. others

1.1. styles

1.1.1. bad

1.1.2. good

1.1.3. not as good

1.1.4. not as bad

1.1.5. important

1.1.6. warning

1.2. author

1.2.1. others

1.2.1.1. styles

1.2.1.1.1. bad

1.2.1.1.2. good

1.2.1.1.3. not as good

1.2.1.1.4. not as bad

1.2.1.1.5. important

1.2.1.1.6. warning

1.2.1.2. author

1.2.1.2.1. Nima Shokouhfar

2. Main

2.1. Principles

2.1.1. Interface Segregation Principle

2.1.1.1. description

2.1.1.1.1. Client should not be forced to implement an interface that it will never use or interface that is irrelevant to it.

2.1.1.2. good link

2.1.1.3. example

2.1.1.3.1. problem

2.1.1.3.2. Solution

2.1.1.4. example 2

2.1.1.4.1. seperate online payment from offline payment

2.1.1.5. Advantages

2.1.1.5.1. By implementing smaller interfaces we are able to separate responsibilities

2.1.1.5.2. By implementing smaller interfaces we are able to distribute responsibilities among multiple interfaces and thus achieve abstraction.

2.1.1.5.3. Classes can use relevant interfaces and thus implement functions that are required by the classes. So we are able to keep the class clean by keeping out code that is of no use to the class.

2.1.2. Liskov Substitution Principle

2.1.2.1. description

2.1.2.1.1. Any function or code that use pointers or references to base class must be able to use any class that is derived from that base class without any modifications

2.1.2.2. All implementation of a interface should be perfectly implemented and swappable

2.1.2.2.1. This principle suggests that you should write your derived classes in such a way that any child class (derived class) should be perfectly substitutable in place of its parent class (base class) without changing its behaviour.

2.1.2.3. In short

2.1.2.3.1. all drived classes should give the same output for the given input.

2.1.2.3.2. a fact

2.1.2.4. Link much better explanation

2.1.2.4.1. If substituting a superclass object with a subclass object changes the program behavior in unexpected ways, the LSP is violated.

2.1.2.4.2. Why this is an issue?

2.1.2.4.3. How to Identify LSP Violations?

2.1.2.5. example

2.1.2.5.1. example 1

2.1.2.6. Advantages

2.1.2.6.1. Makes subclasses swappable

2.1.3. Open Close Principle

2.1.3.1. description

2.1.3.1.1. A software class or module should be open for extension but closed for modification

2.1.3.2. If we have written a class then it should be flexible enough that

2.1.3.2.1. we should not change it (closed for modification) until there are bugs

2.1.3.2.2. but a new feature can be added (open for extension) by adding new code without modifying its existing code.

2.1.3.3. This principle says that it should be possible to extend functionality in classes without modifying the existing code in the classes

2.1.3.3.1. it should be possible to extend the behaviour of the software without modifying its core existing implementation.

2.1.3.4. implementation

2.1.3.4.1. By open for extension

2.1.3.5. example

2.1.3.5.1. how to do it wrong

2.1.3.5.2. correct approach

2.1.3.6. Advantages

2.1.3.6.1. loose coupling

2.1.3.6.2. Avoid modification of existing code

2.1.4. Single Responsibility Principle

2.1.4.1. description

2.1.4.1.1. Each software module or a class should have one and only one reason to change

2.1.4.1.2. it performs one single task

2.1.4.2. Example

2.1.4.2.1. What not to do

2.1.4.2.2. solution

2.1.4.3. Why not?

2.1.4.3.1. If you add more than one responsibility or task into a single class then we end up with TIGHTLY COUPLED functionalities that should have not been together

2.1.4.3.2. This is difficult to maintain as a change in one functionality might impact other functionality.

2.1.4.3.3. this is against atomic design

2.1.4.4. Advantages

2.1.4.4.1. Reusability

2.1.4.4.2. Improve maintainability by Minimizing data coupling impact

2.1.4.4.3. Improves testability

2.1.4.4.4. Minimize modification

2.1.4.4.5. seperation of concerns

2.1.4.4.6. easier design and implement

2.1.4.4.7. readability

2.1.4.4.8. easier debuging

2.1.4.5. Summary

2.1.4.5.1. By using the single responsibility principle we can reduce dependency between functionalities and hence can better manage our code for implementing new features over the long run.

2.1.5. Dependency Inversion Principle

2.1.5.1. description

2.1.5.1.1. High level classes should not depend on low level classes instead both should depend upon abstraction.

2.1.5.1.2. Abstraction should not depend upon details infact details should depend upon abstraction

2.1.5.1.3. This principle suggests that there should be loose coupling between high-level and low-level classes and to achieve this loose coupling components should depend on abstraction.

2.1.5.1.4. names

2.1.5.2. example

2.1.5.2.1. example 1

2.1.5.3. Advantages

2.1.5.3.1. Make the code more testable

2.1.5.3.2. we can mock interfaces easily

2.1.5.3.3. implementations become swappable

2.1.5.3.4. Classes depend on abstraction and not on concrete types

2.1.5.3.5. High-level and low-level classes are loosely coupled

2.1.5.3.6. As long as you are not changing contracts change in one class will not trigger a change in another class

2.1.5.3.7. Since classes depend on abstraction change in one class will not break another class

2.2. why

2.2.1. maintenance

2.2.1.1. as a result, you need to modify the code

2.2.1.2. example

2.2.1.2.1. add features

2.2.1.2.2. fix bugs

2.2.1.3. The design of the solution should be such that it should be easy to modify or extend existing code

2.2.2. scalability

2.2.3. reusability

2.3. Solution

2.3.1. implement code such that you are able to make a design with considerations for

2.3.1.1. flexibility

2.3.1.2. extendibility

2.3.1.3. readability

2.3.1.4. maintainability

2.4. link