• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Programming for a better world
 

Programming for a better world

on

  • 209 views

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.

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.

Statistics

Views

Total Views
209
Views on SlideShare
209
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

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
  • ----- 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 Programming for a better world Presentation Transcript

  • Programming – for a better world! Courtesy http://www.objectmentor.com/
  • 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 ?
  • Are we programming with Passion?  (Mostly it would not be, reason for the bad code)
  • Are we producing right code ?  YES (Assumption ;-) )
  • What is your peer saying ? “I could have done it in a different way!!!”
  • 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.
  • System stinking?  Rigidity  Fragility  Lack of reusability
  • RIGIDITY  Change at one place leading to changing many parts of the system.  Very tough to change something.
  • FRAGILITY  Change at one place breaks some other part of the system which is irrelevant of this module.  Very tough to change something.
  • Lack of reusability  Not being able to plug out a module of the system and reusing in an another application.
  • Are we producing right code ?
  • What is a Good System?  Extendable  Maintainable
  • 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.
  • S -> ? Check the number of possibilities for changing Rectangle class
  • Single Responsibility “A class should never be responsible for more than one job”
  • Affects of violating SRP  Very high chances of code change.  Leading to Test many things.
  • 0-> ?  Change the server  Achieve independency from the server
  • Open closed principle “Software entities should be open for extension, but closed for modification”
  • Abstraction is the key  Client is closed for modification  It depends on a fixed abstraction  Extension done through new derivatives of abstract class
  •  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.
  • L -> ?
  • 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)); }
  • Liscov substitution principle “Functions that use references of the base class must be able to use that with objects of derived classes”
  • 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(); }
  • 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; };
  • Correct Solution? All the derivatives of Door should implement timerclient
  • Interface seggregation Principle “Clients should not be forced upon the interfaces that they don’t use”
  • Correct Solution? All the derivatives of Door should implement timerclient Door derivatives don’t need to implement timerclient
  • D -> ?  What is kind of dependency is here with copy()  How to decouple and reuse the copy ?
  • 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.”
  • 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
  • I would love to change the world But they wont give me the source code