Who is the Intended Audience?
This article is intended for those with at least a basic understading of Object
Oriented Programming. They know the difference between a class and an object and
can talk about the fundamentals of Object Oriented Programming i.e.,
Encapsulation, Abstraction, Polymorphism and Inheritance.
Introduction
Objects, Objects and
Objects!!! What else do we have in Object Oriented Programming. Ya we have
classes right?
In Object Oriented Programming we create software systems by treating everything
as an object, like customer object, supplier object etc. These objects interact
with each other.
Object Oriented Design
heaven to hell
Initially when a Team Lead or a Technical Architect begins a software design he uses his entire experience and with full honesty, and he succeeds but as time goes by new changes will be introduced and software quality, especially code quality, degrades.
Hell monster
We can't just make a "Change Request" the culprit of the degradation of our software system.
Just try to remember the day when you went to buy a new mobile for yourself. What was your expectation? You wanted everything, a good high pixel camera and nice sound quality. Your expectation was way beyond the limit right? So how do you expect that the client who pays for a software system won't expect what he wants.
It's our design that was bad, that was not strong enough to face the flood of changes.
Dependencies in the system
One of the biggest reasons for the damage done to software design is the introduction of unplanned dependencies into the system. Every part of the system depends on some other part and so a change in one part will affect another part. If we are able to manage those dependencies then we will easily maintain the software system as well as the software quality.
![BALDAL.png]()
Principles, Design Patterns and Software Architecture
- Software architecture like MVC, 3-Tier, MVP tells us how the overall project will be structured.
- Design pattern lets us reuse the experience, or we can say it provides reusable solutions to commonly occurring problems. Example: the problems of object creation, instance management and many more.
- Principles tell us, do these and you will do this, how you will do it, it's up to you. Everyone define some principles for their life like, I never lie, I never drink alcohol etc. He/she follows these principles to make his/her life easy, but how he/she will comply is up to him/her.
In the same way Object Oriented Design is filled with many principles that let us manage problems with software design.
Mr Robert Martin, commonly known as Uncle Bob, introduced some class design principles of which later Michael Feathers gave the acronym SOLID Principles.
- S - SRP - Single responsibility Principle
SRP says "Every software module should have only one reason to change".
(Note: Software Module â€" Class, Function etc. Reason to change â€" Responsibility) - O - OCP -- Open Close Principle
It says "Software modules should be closed for modifications but open for extensions." - L - LSP - Liskov substitution principle
It says "Subclasses should be substitutable for base classes." - I -" ISP- Interface Segregation principle
It states that "Clients should not be forced to implement interfaces they don't use".
It can also be stated as "Many client specific interfaces are better than one general purpose interface" - D - DIP-Dependency Inversion principle
It says "High level modules should not depend upon low level modules. Rather, both should depend upon abstractions."
There are some principles that play important roles in Object Oriented Design but not categorized like SOLID is. They are.
- Program to Interface Not Implementation.
- Don't Repeat Yourself.
- Encapsulate What Varies.
- Depend on Abstractions, Not Concrete classes.
- Least Knowledge Principle.
- Favor Composition over Inheritance.
- Hollywood Principle.
- Apply Design Pattern wherever possible.
- Strive for Loosely Coupled System.
- Keep it Simple and Sweet / Stupid.
In the future up article we will try to talk about each of these principle in detail.
Conclusion
Changes are unavoidable storms in software development, we can only create software designs in such a way that the changes can be adopted, perhaps not completely but at least somewhat.
Hope all of you enjoyed reading this article. Thank you for the patience.
For technical training related to various topics including ASP.NET, Design Patterns, WCF and MVC contact[email protected] or at http://www.sukesh-marla.com/
For more material like this click here. Subscribe to article updates or follow at twitter @SukeshMarla