• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SOLID
 

SOLID

on

  • 1,677 views

 

Statistics

Views

Total Views
1,677
Views on SlideShare
1,183
Embed Views
494

Actions

Likes
0
Downloads
36
Comments
0

8 Embeds 494

http://fercaiscoding.com 403
http://91.121.136.24 37
http://fercaiscoding.wordpress.com 35
http://ks202063.kimsufi.com 13
http://wonder-tonic.com 3
http://ks202063.kimsufi.com.fercaiscoding.com. 1
http://ks202063.kimsufi.com.fercaiscoding.com 1
http://www.365dailyjournal.com 1
More...

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    SOLID SOLID Presentation Transcript

    • SOLIDWhat is good design?
    • INTRODUCTION• My name is Ferran Caellas• Backend developer at eyeOS• Specialities and interests: Software Arquitecture, Patterns, Object Oriented Programing and Project Management.
    • TNTWIWHDIThat’s Not The Way I Would Have Done It
    • 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
    • There should never be more than one reason for a class to changeSINGLE RESPONSIBILITY PRINCIPLE
    • SINGLE RESPONSIBILITY PRINCIPLETwo resonsibilities:1. Provide a mathematical model of the geometry of a rectangle.2. Render the rectangle on a graphical user interface.
    • 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.
    • Software entities should be open for extension, but closed for modification OPEN CLOSED PRINCIPLE
    • 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
    • OPEN CLOSED PRINCIPLE$employeeToSave = new Employee();$employeeToSave.setName(‘Ferran’);$employeeToSave.setSurames(‘Caellas Puig’);…$employeeToSave.toXml();
    • 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();
    • Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it LISKOV SUBSTITUTION PRINCIPLE
    • LISKOV SUBSTITUTION PRINCIPLEFunction setDimensions (rectangle) { rectangle.setWidth(5); rectangle.setHeight(2);}r = new Square();setDimensions(r);
    • 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
    • DEPENDENCY INVERSION PRINCIPLEThe high level module Copy is depending in the low levelmodules ReadKeyboard and WritePrinter.
    • 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.
    • Clients should not be forced to depend upon interfaces that they do not use. INTERFACE SEGREGATION PRINCIPLE
    • 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.
    • 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.
    • 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.
    • 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
    • SOLIDWhat is good design?