Programming for a better world, It tells how can we categorize a code as stinking and if yes how to develop a clean system using SOLID principles.

1. Programming – for a better world!
Courtesy
http://www.objectmentor.com/

2. AGENDA
 Check to see if we are producing right
code.
 How to say our code is stinking?
 How to develop a system which is more
maintainable and extendible ?

3. Are we programming with Passion?
 (Mostly it would not be, reason for the
bad code)

4. Are we producing right code
?
 YES (Assumption ;-) )

5. What is your peer saying ?
“I could have done it in a different way!!!”

6. Is System going wrong ?
 Most of the systems will be Good in the
initial development phase(At least up to
first phase)
 After then, it starts to stink.

7. System stinking?
 Rigidity
 Fragility
 Lack of reusability

8. RIGIDITY
 Change at one place leading to
changing many parts of the system.
 Very tough to change something.

9. FRAGILITY
 Change at one place breaks some other
part of the system which is irrelevant of this
module.
 Very tough to change something.

10. Lack of reusability
 Not being able to plug out a module of
the system and reusing in an another
application.

11. Are we producing right code
?

12. What is a Good System?
 Extendable
 Maintainable

13. SOLID Principles
 Principles for developing a system which is
extendable and maintainable.
 Its an Acronym, each letter stands for a
principle.
 S O L I D stands for five principles.

14. S -> ?
Check the number of possibilities for
changing Rectangle class

15. Single Responsibility
“A class should never be responsible for
more than one job”

16. Affects of violating SRP
 Very high chances of code change.
 Leading to Test many things.

17. 0-> ?
 Change the server
 Achieve independency from the server

18. Open closed principle
“Software entities should be open for
extension, but closed for modification”

19. Abstraction is the key
 Client is closed for modification
 It depends on a fixed abstraction
 Extension done through new derivatives
of abstract class

20.  Open for extension : Behavior of the
module should be extendible (new
requirements)
 Closed for modification : Source code of
such modules should not be allowed to
be changed.

23. L -> ?

24. PROBLEM
void DrawShape(const Shape& s)
{
DrawSquare(static_cast<Square&>(s));
}
void DrawShape(const Shape& s)
{
if (typeid(s) == typeid(Square))
DrawSquare(static_cast<Square&>(s));
else if (typeid(s) == typeid(Circle))
DrawCircle(static_cast<Circle&>(s));
}

25. Liscov substitution principle
“Functions that use references of the base
class must be able to use that with objects
of derived classes”

26. Solution
 DrawShape now doesn’t need to know
any new shape coming in further future
 Works with any subclass of shape.
void DrawShape(const Shape& s)
{
s.draw();
}

27. I -> ?
Security Door
class Door
{
public:
virtual void Lock() = 0;
virtual void Unlock() = 0;
virtual bool IsDoorOpen()
= 0;
};
Timer
{
public:
void Regsiter(int timeout,
TimerClient* client);
};
class TimerClient
{
public:
virtual void TimeOut() = 0;
};

28. Correct Solution?
All the derivatives of Door
should implement timerclient

29. Interface seggregation Principle
“Clients should not be forced upon the
interfaces that they don’t use”

30. Correct Solution?
All the derivatives of Door
should implement timerclient
Door derivatives don’t need to
implement timerclient

31. D -> ?
 What is kind of dependency is here with
copy()
 How to decouple and reuse the copy ?

32. Dependency Inversion principle
“High level modules should not depend
upon low level modules. Both should
depend upon Abstractions.”
“Abstractions should not depend upon
details, details should depend upon
Abstractions.”

33. Solution
 High level details is not dependent on the
low level details.
 To support a new reader and write
nothing in copy has to be changed

34. I would love to
change the world
But they wont give
me the source code