SOLID Principles

[hellosagar]

Explained the SOLID principles in my language

[hellosagar]

S: Single responsibility principle - Class should do only one thing no more or less.

[hellosagar]

O: Open for extension close for modification

---

[hellosagar]

LSP1: https://www.youtube.com/watch?v=ObHQHszbIcE&list=PLrhzvIcii6GMNEfebXDXuphcdlZE1-qHG&index=2

LSP2: https://www.youtube.com/watch?v=bVwZquRH1Vk&list=PLrhzvIcii6GMNEfebXDXuphcdlZE1-qHG&index=4

L: Liskov's substitution -
It states that Child classes should never break the parent class’ type definitions. This follows the Robosutness principles (Which means you should be liberal in what you accept and conservative in what you send) in a way that the pre-conditions should be the same or weaker, and post-conditions should be the same or stronger and the same goes for invariants should be same or stronger.

Here,
Pre-conditions: It's a sort of entry condition for the method, to be able to call that method whatever is stated in the pre-conditions it must be true.

Post-conditions: It's on the other end of the spectrum, it says that whatever post-condition must be true when a method has been called.

Invariants: Stay true at all times in the program

Soln: Prefer composition over inheritance, it is predictable when there is a lot of subtyping to avoid this problem

---

[hellosagar]

(ISP: https://www.youtube.com/watch?v=xahwVmf8itI)
I: Interface segregation-

(It's the easiest to understand because it's easy it's complex in a way that THAT's ALL IT IS?)
It states better to have many small interfaces rather than a few large interfaces. or if you restate it too remember easily too many is better than too few.

Explaining problem statement:

Stay away from this:

Prefer this:

After having different species (advantage of using small and concise interfaces):

Soln: You say what the benefits of operating it into different interfaces, we are favoring composition over inheritance and decoupling over coupling.

and in a practical thingy, if we have a other species which can only sleep and eat and not move, and if we're using inheritance then we've to create a new class but in case of small roles for each task, its easy to pick exactly which the class wants

[hellosagar]

D: Dependency inversion

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.

advantages:

1. we can easily swap a low-level module with a different one because a high-level module and low-level module both depend on abstraction.
2. Easily able to test in isolation, as we can pass the class specific to testing through the constructor. Example sending the dispatcher through constructor in ViewModel in the android instead of hard-coding dispatcher
3. Minimized risk to affect old functionality, since we don’t change it.

references:

• https://www.youtube.com/watch?v=S9awxA1wNNY&list=PLrhzvIcii6GMNEfebXDXuphcdlZE1-qHG&index=5
• https://medium.com/android-news/android-development-the-solid-principles-3b5779b105d2 (search: The Dependency Inversion Principle (DIP))