Object Oriented Software Design Process

Design Principles Of the Object Oriented Software Design Process

This article is by one of Leapset’s Tech Leads Sivakumaran Kathamutthu. Check out more of his work at:

Design Principle Of Software
The software  design principle is set of protocol  which is used to come up for a good design of software which is stable , easy to maintain and reduce the complexity . In a nutshell to get the good design.
What is being resolved in design principle in designing software ?
According to Robert Martin , There are three common issue will be solved and some other issues also  will be solve by adhering to design principle.
Those are:
1) Rigidity
2) Fragility
3) Immobility
4) Viscosity
5) Needless Complexity
6) Needless Repetition
7) Opacity

Each parts of module , classes are integrated together tightly and higher dependency and coupling and low cohesion.So its so hard to change one module or part of it , because it may causes to change too many other parts of the software.
Single change causes will makes to change the dependent module.

When you make change for one part of the software can break the other part of the software.The part of the software which is breaking due to change of the another part , never have conceptual relationship with the area that was changed.

Its very hard to use in another application .i.e No reuse. Because,its very cost and so risk to seperate from the its original system and put in to common place.

Is very hard to use the method which preserving by the design.

Needless Complexity

Basically this happen when the requirement couldn be identified properly. Due to that there can be method and object which aren’t usefull. So it will be messy and very hard to understand due to unnecessary complexity.

Needless Repetition
The design contains repeating data & structures that could be placed in one common location as a single abstraction. And this will be make hard to understand the application with duplication code.So has to make “Dont Repeat Yourself (DRY)

Is the probability of the module to read and understand.Due to code does not express its intents. The code is written in very poor manner.
So when we design a software we always be very keen to avoid above mentioned issue which will be a headache in the future of maintaining of software. So lets skim in to the design principle which can eliminate of above mentioned issue in enterprise software.Since these protocols are SOLID (we can remember this as SOLID if its hard to remeber) we have to understand this solidly.

S – Single Responsibility Principle
A class should have one reason to change.
Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.
In this context a responsibility is considered to be one reason to change. This principle states that if we have two reasons to change for a class, we have to split the functionality in two classes . if not it will get coupled to gethere. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

O – Open-Closed principle

The software entities (Classes, Modules, functions, etc..) should be open for extention, but clossed for modification.
If you have a library containing a set of classes there are many reasons for which you ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing,  ). This is why we have to make sure our modules follow Open Closed Principle.

 Open For Extension,
The behavior of the module can be extended( basically you can overriding method or   subclassing       from a parent class).
You can consider it when writing your classes to make sure that when you need to extend their behavior you don t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you ll prefer to extend it without changing the code that was already written.This is why we have to make sure our modules follow Open Closed Principle.
When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them.
Eg: Struts 1 Action class.

Closed For Modification
Extending behaviour of module does not resulting changes to the source code or     binary code of the module.
Eg: You can’t modify a Collection (List, Map etc.. in java ) while its being iterated.You  will end up with Concurrent modification Exception.


L – Liskov Substitution Principle

Is subtype must be substitutable for their base types. This principle define the OOP inheritance principle. If a client uses a base class, then it should not differentiate the base class from derived class, which mean the derived class can substitute the base class.

Liskov’s Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy.

I – The Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they don’t use.
When we write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. Interfaces containing methods that are not specific to it (unnecessary methods) are called polluted or fat interfaces. This will lead to make your classe very cohesive.

D – Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.  Abstractions should not depend on details. Details should depend on abstractions.
Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.
Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module need some other module, it initializes and holds a direct reference to it. This will make the two modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter,  ) and an external module controlling the dependencies will inject the reference to the second one.
So all object creation and resolving the dependecy are done by framework. The framework always behave in such way that “Dont call us , we will call you”.

So depend on Abstractions will give some good benifit to make your module to cohesive in a way ,
1) No varible should hold a reference to a concrete class.
2) No class should derive from a concrete class.
3) No method should override an implemented method of any of its base classes.
Eg : DIP is core of the Spring framework.

Some term thats we should adhere when we design a software and we need to keep this in mind always to write good code.

LOD – Law Of Demater

which is ,
1) Principle of least knowledge – one of GRASP pattern.(
2) Only talk to you immedate friend.
3) Dont talk to a stranger.
4) Write “shy ” codes.
5) Minimizing coupling.

DRY – Don’t Repeat Yourself

Dont write same function with different data structer all the placeses in code base. Make thos in one single abstract class.

DBC -Design By Contract

DBC concept is developed by Betrand Meyer for language Eiffel. DBC gives us a good concept to write a robust software , even java does not support it .
In DBC basically considerings are ,

1) A contract defines rights and responsiblities between method caller and  a routing.
2) Preconditions – the routine’s requirements , its the caller’s responsibility to pass good data.
3) Postconditions – what the routine is guaranteed to do.
4) Class invariants – A class ensures that this condition is always true from perspective of caller.
The contract between  a routine and any potential caller can thus be read as ,
If the routine’s precondtions are met by the caller, the routine shall guarntee that all postcondtions and invariants will be true when it completes.


Leave a Comment