Design Principles
Download as PPTX, PDF1 like652 views
The document discusses design principles and symptoms of bad design. It describes that design is about "how" while analysis is about "what". Bad design can lead to rigidity, fragility, immobility and viscosity in software. The SOLID principles - single responsibility, open/closed, Liskov substitution, interface segregation and dependency inversion - help achieve good design with high cohesion and low coupling between modules. Following these principles can help software designs be more flexible, reusable and maintainable.
Design Principles
- 1. Design Principles By Kartheek Nagasuri & Amit Grewal
- 2. Design • What is the meaning of the Design? Design is about “How” • What is the Difference if compared to Analysis? Analysis is about “What”
- 3. Design Why do we need (good) design? To Deliver Faster To Deal with Complexity To Manage Change
- 4. Design • How do we know a design is bad? “W*F? “ I can’t Fix this code “W*F? “ “W*F? “ I fixed the problem “W*F? “ but it broke at “W*F? “ other places.. “W*F? “ “W*F? “ “W*F? “
- 5. Design • Lets talk about criteria of bad design • Are there any Symptoms of bad design? Immobility Rigidity Fragility Viscosity
- 6. Rigidity • The Impact of the change is Unpredictable – Every change causes a cascade of changes in dependant modules. – A nice 2 days work become endless “Marathon” – Costs become unpredictable.
- 8. Immobility • Its almost impossible to reuse interesting parts of the software – The useful modules have somany depandancies – The cost of rewriting is less compared to the risk faced to separate those parts
- 9. Fragility • The Software tends to break in many places on every change. – The breakage occurs in areas with no conceptual relationship. – On every fix the software breaks in unexpected ways.
- 10. Viscosity • A hack is cheaper to implement than the solution with in the design – preserving design moves are difficult to think and to implement. – Its much easier to do wrong thing than the right one.
- 11. Design • What is the reason why design becomes rigid, fragile, immobile and viscous? Improper dependencies between the modules
- 12. Good Design • What are the characteristics of a good design High Cohesion Low coupling
- 13. How can we achieve good design?
- 14. Let’s Go SOLID… • Single Responsibility Principle • Open Close Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle
- 16. Single Responsibility Principle • A software module should have one and only responsibility • A software module should have one reason only to change • It translates directly in high cohesion
- 17. Single Responsibility Principle • Is SRP violate here? Interface modem { Public Void Dial (string pno); Public void hangup(); Public void send (char c); Public char receive(); }
- 18. Single Responsibility Principle • Is SRP violate here? Interface Employee { Public pay calculate(); Public void report(Writer w); Public void save(); Public void reload(); }
- 19. How to Solve? public abstract class BankAccount { double Balance { get; } void Deposit(double amount) {} void Withdraw(double amount) {} void AddInterest(double amount) {} void Transfer(double amount, IBankAccount toAccount) {} }
- 20. public abstract class BankAccount { double Balance { get; } void Deposit(double amount); void Withdraw(double amount); void Transfer(double amount, IBankAccount toAccount); } public class CheckingAccount : BankAccount { } public class SavingsAccount : BankAccount { public void AddInterest(double amount); }
- 22. Open Closed Principle • Modules should be open for extension but closed for modification. • “You should be able to extend the behavior of a module without changing it”
- 23. public class ProductFilter { public IEnumerable<Product> ByColor(IList<Product> products, ProductColor productColor) { foreach (var product in products) { if (product.Color == productColor) yield return product; } } }
- 24. public class ProductFilter { public IEnumerable<Product> BySize(IList<Product> products, ProductSize productSize) { foreach (var product in products) { if (product.Size== productSize) yield return product; } } }
- 25. public class ProductFilter { public IEnumerable<Product> BySize(IList<Product> products, ProductColor productColor, ProductSize productSize) { foreach (var product in products) { if (product.Size== productSize && product.color==productColor) yield return product; } } }
- 26. Any Problem? • Every time a user asks for new criteria to filter a product, do we have to modify the ProductFilter class? – Yes! This means it is not CLOSED for modification. • Every time a user asks for new criteria to filter a product, can we extend the behavior of the ProductFilter class to support the new criteria, without opening up the class file again and modifying it? – No! This means it is not OPEN for extension.
- 27. Solution • Template public abstract class roductFilterSpecification { public IEnumerable<Product> Filter(IList<Product> products) { return ApplyFilter(products); } protected abstract IEnumerable<Product> ApplyFilter(IList<Product> products); }
- 28. public class ColorFilterSpecification :ProductFilterSpecification { private readonly ProductColor productColor; public ColorFilterSpecification(ProductColor productColor) { this.productColor = productColor; } protected override IEnumerable<Product> ApplyFilter(IList<Product> products) { foreach (var product in products) { if (product.Color == productColor) yield return product; } } }
- 29. public IEnumerable<Product> By(IList<Product> products, ProductFilterSpecification filterSpecification) { return filterSpecification.Filter(products); }
- 30. Are we Fine now?
- 32. Liskov Substitution Principle • Functions that use ... references to base classes must be able to use objects of derived classes without knowing it. • A user of a base class should continue to function properly if a derivative of that base class is passed to it.
- 34. Interface Segregation Principle • ISP States that clients should not know about fat classes. • Instead they should rely on clean cohesive interfaces • Many client specific interfaces are better than one general purpose interface
- 35. Interface Segregation Principle • A class with many clients, and one large interface to serve them all
- 38. Dependency Inversion Principle • High level modules should not depend on low level modules, both should depend • Abstractions should not depend upon details, details should depend upon abstractions • Every dependency in the design should target an interface, or an abstract class. No dependency should target a concrete class.
- 41. Dependency Inversion Principle • Don’t depend on anything concrete, depend only upon abstraction • High level modules should not be forced to change because of a change in low level/technology layers • Drives you towards low coupling
- 42. Conclusion • The main forces driving your design should be “High Cohesion” and “Low coupling” • SOLID principles put you on right path.