Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Software Design principles

795 vues

Publié le

1. Symptoms of rotting Design
2. Changing Requirement
3. Dependency Management
4. SOLID Principle
5. Further Readings

https://www.linkedin.com/pulse/liskov-substitution-principlelsp-milan-ashara
https://www.linkedin.com/pulse/open-closed-principle-ocp-milan-ashara
https://www.linkedin.com/pulse/single-responsibility-principle-srp-milan-ashara
https://www.linkedin.com/pulse/symptoms-rotten-software-design-why-engineer-should-know-milan-ashara

Publié dans : Technologie
  • Soyez le premier à commenter

Software Design principles

  1. 1. + Software Design Principle Milan Ashara
  2. 2. + Outline  Symptoms of rotting Design  Changing Requirement  Dependency Management  SOLID Principle  Further Readings 30/12/2015 2
  3. 3. + Why?  Rigidity 30/12/2015 3
  4. 4. + Why?  Fragile 30/12/2015 4
  5. 5. + Why?  Immobility 30/12/2015 5
  6. 6. + Why ?  Viscosity of the design  Viscosity of the environment 30/12/2015 6
  7. 7. + Changing Requirement  Design adaptive to changing requirement 30/12/2015 7
  8. 8. + Dependency Management 30/12/2015 8
  9. 9. + Dependency Management 30/12/2015 9
  10. 10. + SOLID Design Principles
  11. 11. + The Single Responsibility Principle  THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.  Also called Cohesion. 30/12/2015 11
  12. 12. + The Single Responsibility Principle 30/12/2015 12
  13. 13. + The Single Responsibility Principle 30/12/2015 13
  14. 14. + The Single Responsibility Principle 30/12/2015 14
  15. 15. + The Single Responsibility Principle 30/12/2015 15
  16. 16. + Open Closed Principle  Open for Extension and closed for modification  Abstraction is key to the OCP 30/12/2015 16
  17. 17. + Open Closed Principle 30/12/2015 17
  18. 18. + Open Closed Principle 30/12/2015 18
  19. 19. + Open Closed Principle 30/12/2015 19
  20. 20. + Open Closed Principle  Dynamic Polymorphism 30/12/2015 20
  21. 21. + Open Closed Principle  /** * Created by milanashara on 21/12/15. */ public interface Sorting { int[] sort(int[] array); } 30/12/2015 21
  22. 22. + 30/12/2015 22
  23. 23. + Open Closed Principle 30/12/2015 23
  24. 24. + Open Closed Principle  public class Client { public Sorting getSorting() { return sorting; } public void setSorting(Sorting sorting) { this.sorting = sorting; } private Sorting sorting; public int[] sort(int array[]){ array = sorting.sort(array); return array; } } 30/12/2015 24
  25. 25. + Static Polymorphism  Use Templates or Generics 30/12/2015 25
  26. 26. + Liskov Substitution Principle(LSP)  Subclass should be substitutable for their base class  a user of a base class should continue to function properly if a derivative of that base class is passed to it 30/12/2015 26
  27. 27. + Liskov Substitution Principle(LSP)  Circle/ellipse Dilemma: All circles are ellipses with coincident foci 30/12/2015 27
  28. 28. + Liskov Substitution Principle(LSP)  Design by contract 30/12/2015 28
  29. 29. + Liskov Substitution Principle(LSP) 30/12/2015 29
  30. 30. + Liskov Substitution Principle(LSP) Clients Ruin Everything. 30/12/2015 30
  31. 31. + Liskov Substitution Principle(LSP) 30/12/2015 31
  32. 32. + The Interface Segregation Principle (ISP)  CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE  Many client specific interfaces are better than one general purpose interface 30/12/2015 32
  33. 33. + The Interface Segregation Principle (ISP) 30/12/2015 33
  34. 34. + The Interface Segregation Principle (ISP) 30/12/2015 34
  35. 35. + The Interface Segregation Principle (ISP)  What does Client Specific Mean?  Changing Interfaces  Adapter pattern 30/12/2015 35
  36. 36. + The Dependency Inversion Principle (DIP)  Depend upon Abstractions. Do not depend upon concretions.  Object Creation: One of the most common places that designs depend upon concrete classes is when those designs create instances. Solution is use of AbstractFactory  We assume anything concrete is Volatile.  Heavily uses in component Design like EJB 30/12/2015 36
  37. 37. + The Dependency Inversion Principle (DIP) 30/12/2015 37
  38. 38. + The Dependency Inversion Principle (DIP) 30/12/2015 38
  39. 39. + Further Coming Soon  Web application architecture  Test Driven Development  Refactoring  Design Pattern 30/12/2015 39

×