-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SOLID Principles #32
Comments
S: Single responsibility principle - Class should do only one thing no more or less. |
O: Open for extension close for modification |
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 - Here, 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 |
(ISP: https://www.youtube.com/watch?v=xahwVmf8itI) (It's the easiest to understand because it's easy it's complex in a way that THAT's ALL IT IS?) Explaining problem statement: 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 |
D: Dependency inversion
advantages:
references:
|
Explained the SOLID principles in my language
The text was updated successfully, but these errors were encountered: