SOLID

2,768 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,768
On SlideShare
0
From Embeds
0
Number of Embeds
1,340
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOLID

  1. 1. SOLIDWhat is good design?
  2. 2. INTRODUCTION• My name is Ferran Caellas• Backend developer at eyeOS• Specialities and interests: Software Arquitecture, Patterns, Object Oriented Programing and Project Management.
  3. 3. TNTWIWHDIThat’s Not The Way I Would Have Done It
  4. 4. DEFINITION OF A BAD DESIGNIt is hard to change because every change affects too many other parts of the system. RIGIDITY When you make a change, unexpected parts of the system break. FRAGILITY It is hard to reuse in another application because it cannot be disentangled from the current application. IMMOBILITY
  5. 5. There should never be more than one reason for a class to changeSINGLE RESPONSIBILITY PRINCIPLE
  6. 6. SINGLE RESPONSIBILITY PRINCIPLETwo resonsibilities:1. Provide a mathematical model of the geometry of a rectangle.2. Render the rectangle on a graphical user interface.
  7. 7. SINGLE RESPONSIBILITY PRINCIPLEWe moved the computational parts of a rectangle into aseparated class called GeometricRectangle. Now changesmade to the way rectangles are rendered cannot affectthe ComputationalGeometryApplication.
  8. 8. Software entities should be open for extension, but closed for modification OPEN CLOSED PRINCIPLE
  9. 9. OPEN CLOSED PRINCIPLEOpen for extension Closed to modificationThe behavior of the module can be The source code of a module is inviolate.extended. We can make the module No one is allowed to make source codebehave in new and different ways as changes to it.the requirements of the applicationchanges or to meet the needs of newapplications. Abstraction is the key. In fact, polimorphism
  10. 10. OPEN CLOSED PRINCIPLE$employeeToSave = new Employee();$employeeToSave.setName(‘Ferran’);$employeeToSave.setSurames(‘Caellas Puig’);…$employeeToSave.toXml();
  11. 11. OPEN CLOSED PRINCIPLE // Initializing the employee to save $employeeToSave = new Employee(); $employeeToSave.setName(‘Ferran’); $employeeToSave.setSurames(‘Caellas Puig’); … // Creating type of writer we want to use $xmlDataWriter = new XmlDataWriter(); // Creating the employe writer $employeeWriter = new EmployeeWriter(); $employeeWriter.setEmployee($employeeToSave); $employeeWritter.setWriter($xmlDataWriter); $employeeWriter.write();
  12. 12. Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it LISKOV SUBSTITUTION PRINCIPLE
  13. 13. LISKOV SUBSTITUTION PRINCIPLEFunction setDimensions (rectangle) { rectangle.setWidth(5); rectangle.setHeight(2);}r = new Square();setDimensions(r);
  14. 14. High level modules should not depend upon low level modules. Both sould depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. DEPENDENCY INVERSION PRINCIPLE
  15. 15. DEPENDENCY INVERSION PRINCIPLEThe high level module Copy is depending in the low levelmodules ReadKeyboard and WritePrinter.
  16. 16. DEPENDENCY INVERSION PRINCIPLENow the Copy module is not depending in thesubmodules anymore, we can now reuse the copy classwith new kinds of readers or writers.
  17. 17. Clients should not be forced to depend upon interfaces that they do not use. INTERFACE SEGREGATION PRINCIPLE
  18. 18. INTERFACE SEGREGATION PRINCIPLEThe Automatic Teller Machine (ATM) problem. The user interface of anATM machine needs to be very flexible. It may need to be presented on ascreen, a braile tablet or spoken out a speech synthesizer.
  19. 19. INTERFACE SEGREGATION PRINCIPLEEach transaction that the ATM can perform is encapsulated as aderivative of the class Transaction. Each of these objects issues messagesto the UI.Changes to one of the derivatives of Transaction will force correspondingchange to the UI affecting all the other derivatives of Transaction andevery other class that depends upon the UI interface.
  20. 20. INTERFACE SEGREGATION PRINCIPLENow, there is a specific UI interface for every of the transactions, achange in one of the transactions will only affect the UI implementingthis concrete interface.In example, we can have a separate UI only doing deposits and this willimplement only the IDepositUI and not any of the other UI interfaces.
  21. 21. FURTHER READINGSRobert C. Martin papers about SOLID principles:http://www.objectmentor.com/resources/articles/srp.pdfhttp://www.objectmentor.com/resources/articles/ocp.pdfhttp://www.objectmentor.com/resources/articles/lsp.pdfhttp://www.objectmentor.com/resources/articles/dip.pdfhttp://www.objectmentor.com/resources/articles/isp.pdfAgile Software Development, Principles, Patterns, and Practices(Robert C. Martin)http://www.amazon.com/exec/obidos/ASIN/0135974445/objectmentorinc
  22. 22. SOLIDWhat is good design?

×