Solid Principles

Transcript

1. SOLID PRINCIPLE The First 5 Principles of Object Oriented Design Abid Jami l Technical Lead, GrocerApp
3. Why Solid? It will make your project development more productiv e through decomposition and decoupling b y removing code smells an d reducing time spent on refactoring .
4. Is there any order to apply 
 SOLID Principles?
5. Do I have to apply the 5 principles to my project?
6. Each principle addresses a speci fi c proble m and if your code does not have that problem there's no reason to apply the principle.
7. How SOLID is my code ?
8. SOLID principles are not something you can measure. There isn't something like saying   “My code is 100% SOLID"
9. The Single Responsibility Principle (SRP )
10. The idea behind the SRP is that every class, module, or function in a program should have one responsibility/purpose in a program.
11. public class Student { public void registerStudent() { // some logic } public void calculate_Student_Results() { // some logic } public void sendEmail() { // some logic } }
12. The code above will work perfectly but will lead to some challenges. We cannot make this code reusable for other classes or objects. The class has a whole lot of logic interconnected that we would have a hard time fi xing errors. And as the codebase grows, so does the logic, making it even harder to understand what is going on.
13. public class StudentRegister { public void registerStudent() { // some logic } } public class StudentResult { public void calculate_Student_Result() { // some logic } }
14. Now that we have separated the logic, our code is easier to understand as each core functionality has its own class. We can test for errors more ef fi ciently . The code is now reusable. Before, we could only use these functionalities inside one class but now they can be used in any class .
15. Open for Extension, Closed for Modi fi catio n
17. The open-closed principle states that software entities should be open for extension, but closed for modi fi cation. This implies that such entities – classes, functions, and so on – should be created in a way that their core functionalities can be extended to other entities without altering the initial entity's source code .
18. public class Human { public int height; public int weight; } public class CalculateBMI { public int CALCULATE_JOHN_BMI(Human John) { return John.height/John.weight; } }
19. public class CalculateBMI { public int CALCULATE_HAIDER_BMI(Human Haider) { return Haider.height/Haider.weight; } public int CALCULATE_SALEEM_BMI(Human Saleem) { return Saleem.height/Saleem.weight; } }
20. Although the code above may work perfectly, it's not ef fi cient. We modify the code constantly which may lead to bugs. And the code only has provision for humans. What if we have to calculate for an animal or an object?
21. public interface Entity { public int CalculateBMI(); } public class Haider implements Entity { int height; int weight; public double CalculateBMI() { return Haider.height/Haider.weight; } } public class Saleem implements Entity { int height; int weight; public double CalculateBMI() { return Saleem.height/Saleem.weight; } }
22. Now we no longer have to modify existing code when we create a new entity we just extend the functionality we need and apply it to the new entity.
23. Liskov Substitution Principle (LSP )
24. Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. (Source: Wikipedia)
25. The Liskov substitution principle simply implies that when an instance of a class is passed/ extended to another class, the inheriting class should have a use case for all the properties and behavior of the inherited class.
27. public class Amphibian { public void swim(); public void walk(); } public class Frog extends Amphibian { public void swim() { System.out.println("The frog is swimming"); } public void walk() { System.out.println("The frog is walking on land"); } }
28. public class Amphibian { public void swim(); public void walk(); } public class Shark extends Amphibian { public void swim() { System.out.println("The shark is swimming"); } public void walk() { System.out.println("The shark is walking on land"); } }
29. Interface Segregation Principle (ISP)
30. The interface segregation principle states that the interface of a program should be split in a way that the user/client would only have access to the necessary methods related to their needs.
31. public interface Teacher { void English(); void Biology(); void Chemistry(); void Mathematics(); }
32. public class Jane implements Teacher { @Override public void English() { System.out.println("Jane is teaching the students English language."); } @Override public void Biology() { } @Override public void Chemistry() { } @Override public void Mathematics() { } }
33. public interface Teacher { void Teach(); }
34. public interface EnglishTeacher extends Teacher { void English(); } public interface BiologyTeacher extends Teacher { void Bilogy(); }
35. public class Jane implements EnglishTeacher { @Override public void Teach() { System.out.println("Jane has started teaching."); } @Override public void English() { System.out.println("Jane is teaching the students English language."); } }
36. Dependency Inversion Principle (DIP)
37. High-level modules should not import anything from low-level modules. Both should depend on abstractions
38. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
39. public class Bank { public void GIVE_CUSTOMER_MONEY_OTC() { // some logic } } public class Customer { private Bank myBank = new Bank(); public void withdraw() { myBank.GIVE_CUSTOMER_MONEY_OTC(); } }
40. public interface ATM { void ATM_OPERATION(); } public class Bank implements ATM { @Override ATM_OPERATION(){ // code to add money to ATM and increase the ATM balance } } public class Customer implements ATM { @Override ATM_OPERATION(){ // code to withdraw money from ATM and decrease the ATM balance } }
41. Thank You! https://www.linkedin.com/in/abidjamil/