Programming for a better world

332 views

Published on

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.

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

  • Be the first to like this

No Downloads
Views
Total views
332
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • ----- Meeting Notes (05/09/13 16:24) -----cyclomatic complexity
  • ----- Meeting Notes (05/09/13 16:24) -----inheritance vs association composition
  • Programming for a better world

    1. 1. Programming – for a better world! Courtesy http://www.objectmentor.com/
    2. 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. 3. Are we programming with Passion?  (Mostly it would not be, reason for the bad code)
    4. 4. Are we producing right code ?  YES (Assumption ;-) )
    5. 5. What is your peer saying ? “I could have done it in a different way!!!”
    6. 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. 7. System stinking?  Rigidity  Fragility  Lack of reusability
    8. 8. RIGIDITY  Change at one place leading to changing many parts of the system.  Very tough to change something.
    9. 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. 10. Lack of reusability  Not being able to plug out a module of the system and reusing in an another application.
    11. 11. Are we producing right code ?
    12. 12. What is a Good System?  Extendable  Maintainable
    13. 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. 14. S -> ? Check the number of possibilities for changing Rectangle class
    15. 15. Single Responsibility “A class should never be responsible for more than one job”
    16. 16. Affects of violating SRP  Very high chances of code change.  Leading to Test many things.
    17. 17. 0-> ?  Change the server  Achieve independency from the server
    18. 18. Open closed principle “Software entities should be open for extension, but closed for modification”
    19. 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. 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.
    21. 21. L -> ?
    22. 22. 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)); }
    23. 23. Liscov substitution principle “Functions that use references of the base class must be able to use that with objects of derived classes”
    24. 24. 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(); }
    25. 25. 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; };
    26. 26. Correct Solution? All the derivatives of Door should implement timerclient
    27. 27. Interface seggregation Principle “Clients should not be forced upon the interfaces that they don’t use”
    28. 28. Correct Solution? All the derivatives of Door should implement timerclient Door derivatives don’t need to implement timerclient
    29. 29. D -> ?  What is kind of dependency is here with copy()  How to decouple and reuse the copy ?
    30. 30. 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.”
    31. 31. 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
    32. 32. I would love to change the world But they wont give me the source code

    ×