"SOLID" Object Oriented Design Principles

4,635 views

Published on

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
  • Nice one - thank you, but please consider exporting the original file to PowerPoint format.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,635
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
230
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • rigid is antonym to agile.\n
  • \n
  • \n
  • \n
  • \n
  • - Invented by Bertrand Meyer\n- Adding new functionality by adding new code, not editing old one.\n- Abstractions\n
  • \n
  • Design by Contract\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • "SOLID" Object Oriented Design Principles

    1. 1. Object Oriented Design Serhiy Oplakanets @ Lohika, 2010
    2. 2. Agenda• Symptoms of Bad Design• Basic Principles of Object Oriented Design
    3. 3. Symptoms of Bad Design• Rigidity• Fragility• Immobility• Viscosity
    4. 4. Rigidity• Changes are difficult and painful.• Every change requires cascade of changes in dependent modules.• Scope of change is unpredictable.• Your manager has a favorite scope multiplier, usually more than 2.
    5. 5. Fragility• Closely related to Rigidity.• You can never predict the impact of change.• You never know what will break.• The “christmas tree” (Hi, Jilles!)
    6. 6. Basic Principles of OOD• Single Responsibility Principles• Open-Closed Principle• Liskov Substitution Principle• Interface Segregation Principle• Dependency Inversion Principle
    7. 7. Single Responsibility Principle• A class should have one and only one reason to change.
    8. 8. How to Spot SRP Violation?• Member groups or even coalitions :)• Boolean flags• Hard to name classes• Monster classes: *Manager, *Controller, *Util, Context, ...• Long unit tests• Hard to test-double units
    9. 9. Open-Closed Principle• Modules should be open for extension but closed for modification.
    10. 10. Friends of OCP• Design Patterns: • Visitor • Decorator
    11. 11. Liskov Substitution Principle• Let q(x) be a property provable about objects x of type T.Then q(y) should be provable for objects y of type S where S is a subtype of T.• Basically means that children classes should not break parent’s interface
    12. 12. How to Spot LSP Violation?• Derivative that tries to do less than base class• instanceof checks• Hiding or stubbing parent methods • void someMethod() {} • void someMethod(){throw new ShouldNotBeCalledException(“...”);}• Polymorphic if statements :)
    13. 13. Dependency Inversion Principle• High-level modules should not depend on low-level modules. Both should depend on abstractions.• Abstractions should not depend upon details. Details should depend upon abstractions.
    14. 14. DIP Violation Exampleclass UserDao { User find(String login, String password) { Database database = new MySQLDatabase(); // run queries and so on to create user ... return user; }}
    15. 15. DIP Example. Refactoredclass UserDao { DataSource dataSource; UserDao(DataSource dataSource) { this.dataSource = dataSource; } User find(String login, String password) { // use dataSource to create user object ... return user; }}
    16. 16. DIP Example.Continuedinterface DataSource { Map<Key, Value> read(String container); void update(String container, Map<Key, Value> fields); void create(String container, Map<Key, Value> fields);}
    17. 17. Why adhere to DIP?
    18. 18. Friends of DIP• Abstractions(Interfaces/Abstract Classes/...)• Patterns • Factory, Abstract Factory • Adapter • Service Locator • Dependency Injection• Inversion of Control Principle
    19. 19. Questions?• Have I mentioned good OO Design is hard to implement, btw?

    ×