2. INTRODUCTION
• My name is Ferran Caellas
• Backend developer at eyeOS
• Specialities and interests: Software
Arquitecture, Patterns, Object Oriented
Programing and Project Management.
4. DEFINITION OF A BAD DESIGN
It 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. There should never be more than one reason for a
class to change
SINGLE RESPONSIBILITY PRINCIPLE
6. SINGLE RESPONSIBILITY PRINCIPLE
Two resonsibilities:
1. Provide a mathematical model of the geometry of a rectangle.
2. Render the rectangle on a graphical user interface.
7. SINGLE RESPONSIBILITY PRINCIPLE
We moved the computational parts of a rectangle into a
separated class called GeometricRectangle. Now changes
made to the way rectangles are rendered cannot affect
the ComputationalGeometryApplication.
8. Software entities should be open for extension,
but closed for modification
OPEN CLOSED PRINCIPLE
9. OPEN CLOSED PRINCIPLE
Open for extension Closed to modification
The 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 code
behave in new and different ways as changes to it.
the requirements of the application
changes or to meet the needs of new
applications.
Abstraction is the key.
In fact, polimorphism
10. OPEN CLOSED PRINCIPLE
$employeeToSave = new Employee();
$employeeToSave.setName(‘Ferran’);
$employeeToSave.setSurames(‘Caellas Puig’);
…
$employeeToSave.toXml();
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. Functions that use pointers or references to base classes must be able to
use objects of derived classes without knowing it
LISKOV SUBSTITUTION PRINCIPLE
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
16. DEPENDENCY INVERSION PRINCIPLE
Now the Copy module is not depending in the
submodules anymore, we can now reuse the copy class
with new kinds of readers or writers.
17. Clients should not be forced to depend upon interfaces
that they do not use.
INTERFACE SEGREGATION
PRINCIPLE
18. INTERFACE SEGREGATION PRINCIPLE
The Automatic Teller Machine (ATM) problem. The user interface of an
ATM machine needs to be very flexible. It may need to be presented on a
screen, a braile tablet or spoken out a speech synthesizer.
19. INTERFACE SEGREGATION PRINCIPLE
Each transaction that the ATM can perform is encapsulated as a
derivative of the class Transaction. Each of these objects issues messages
to the UI.
Changes to one of the derivatives of Transaction will force corresponding
change to the UI affecting all the other derivatives of Transaction and
every other class that depends upon the UI interface.
20. INTERFACE SEGREGATION PRINCIPLE
Now, there is a specific UI interface for every of the transactions, a
change in one of the transactions will only affect the UI implementing
this concrete interface.
In example, we can have a separate UI only doing deposits and this will
implement only the IDepositUI and not any of the other UI interfaces.
21. FURTHER READINGS
Robert C. Martin papers about SOLID principles:
http://www.objectmentor.com/resources/articles/srp.pdf
http://www.objectmentor.com/resources/articles/ocp.pdf
http://www.objectmentor.com/resources/articles/lsp.pdf
http://www.objectmentor.com/resources/articles/dip.pdf
http://www.objectmentor.com/resources/articles/isp.pdf
Agile Software Development, Principles, Patterns, and Practices
(Robert C. Martin)
http://www.amazon.com/exec/obidos/ASIN/0135974445/objec
tmentorinc