The document outlines key software design principles that are essential for creating scalable and maintainable applications, including KISS (Keep It Simple, Stupid), DRY (Don't Repeat Yourself), and SOLID principles. Each principle is elaborated with explanations and examples, emphasizing the importance of simplicity, modularity, and reducing dependencies among components. Additionally, it discusses concepts like the Pareto Principle and the Robustness Principle to guide effective design practices.

1. Articles from Jinal Desai
Software Design Principles
2012-05-03 19:05:33 Jinal Desai
There are many design principles that have become best practices over the years. Using these principles
we can develop scalable and maintainable enterprise application with time tested approaches.
1. Keep It Simple Stupid (KISS)
The main goal here is keep things simple. Avoiding unnecessary complexity will help to keep it clear
and easy to understand. Also this principle will help in maintenance; if it is simple then also easy to
modify. Usually the simplest solution is the best solution.
2. Don’t Repeat Yourself (DRY)
This principle states to not repeat things. We can abstract out repeated things and keep it at some
common place where everybody can access it. We can also make common (repeating) things as
general, so that it is available to all.
3. Separation of Concerns (SoC)
Separating things into discrete responsibilities increases reusability, maintenance and also
testability. Here concerns refer to specific features or behavior of the system.
For example, Object Oriented programming languages such as C++, C# and Java (to name a few)
can separate concerns into objects. A Design Pattern like MVC (Model-View-Controller) can
separate content from presentation and data processing (model) from content. Service Oriented
design can separate concerns into services. Procedural programming languages such as C can
separate concerns into procedures. Aspect Oriented programming languages can separate
concerns into aspects and objects.
4. The Pareto Principle
The famous pareto principle states that 80% of effects comes from 20% of causes, i.e. 80% of
sales comes from 20% of customers. The principle is named after Italian economist Vilfredo
Pareto, who observed in 1906 that 80% of land in Italy is owned by 20% of the population. It can help
to resist efforts to correct and optimize designs beyond critical 20%. So 80% focus is on 20% part
of the stuff.
In software engineering Pareto principle can be applied to optimization efforts. For example,
Microsoft noted that by fixing the top 20% of the most reported bugs, 80% of the errors and crashes
would be eliminated.
5. The Robustness Principle
The Robustness Principle states that, “Be liberal in what you accept, and be conservative in what
you send”. In other words, code that sends commands or data to other parts of the system should
conform completely to the specifications, but code that receives input should accept non-
conformant input as long as the meaning is clear.
For example, TCP implementation follows the principle.
6. You Ain’t Gonna Need It (YAGNI)
It is the principle in extreme programming, states that programmers should not add functionality
until it is necessary. It tells programmers that always implement things when you actually need
them, never when you just foresee that you need them. Even if you are sure that you will need it
later on, do not implement it now. The principle is actually emerged from “Extreme Programming”
methodologies.

2. 7. Loose Coupling and High Cohesion
Coupling means links between separate units of a program. In OOPs, if two classes depend closely
on many details of each other, we say they are tightly coupled.
Coupling is a measure of the interdependence between types/entities. If every object has a
reference to every other object, then there is tight coupling, which is undesirable. Because there’s
potentially too much information flow between objects. Loose coupling is desirable. It means that
objects work more independently of each other. Loose coupling minimizes the “ripple effect” where
changes in one class cause necessity for changes in other classes
Cohesion refers to the number and diversity of tasks that a class is designed for. If a class is
responsible for a few related logical tasks, we say it has high cohesion.
Cohesion is a measurement of strengths of the association of variables and methods within a
class. High cohesion is desirable because it means the class does one job well. Low cohesion is
undesirable because it indicates that there are elements in the class which have little to do with
each other. Modules whose elements are strongly and genuinely related to each other are desired.
Each method should also be highly cohesive. Most methods have only one function to perform.
Don’t add extra instructions into methods that cause it to perform more than one function
Loose Coupling has following advantages:
We can understand concerned class without reading other classes
We can change one class without affecting other classes
Loose Coupling improves maintainability
High Cohesion has following advantages:
We can easily understand what is the purpose of class or method
High Cohesion makes it easier to use descriptive names
We can easily reuse classes or methods
8. SOLID Principles
Single Responsibility Principle (SRP)
The Principle states that every object should have single responsibility, and the responsibility
(reason to change) should be entirely encapsulated by the class. So a class or module
should have one and only one reason to change.
For example, we have a print report module. There are utmost two reasons to change the
module. First is content of report is changed. Second is format of report is changed.
Open Closed Principle (OCP)
Software entities (i.e. classes, functions or modules) should be open for extension but closed
for modification. Normally we close entities modification for providing backward compatibility
(regression testing) and open entities extension for extending existing entities with new
functionalities.
For example, we can implement this principle by using Abstract classes, and thus enforcing
concrete classes extend abstract classes rather than changing it. Some of the design
patterns that supports this principle is template pattern and strategy pattern.
In .NET Framework Microsoft has further supported this principle by providing partial
classes/methods and extension methods. You can extend existing code by using these two
new features in .NET.
Liskov’s Substitution Principle (LSP)
The principle states that derived types must be completely substitutable for their base types.
It is just an extension of Open Closed Principle in terms of behavior. Meaning that the derived
types must extend without changing behavior of base types, so that derived types is

3. replaceable with base types (No need to change code).
For example, we have method called StoreAddress(Address address) which accepts type
“Address” as input parameter and stores it into the data store. Now if we make derived type
from the “Address” type named “HomeAddress” then I should be able to call the same
method by passing type “HomeAddress” and it stores correctly into the data store.
Interface Segregation Principle (ISP)
In nutshell, the principle states that “Clients should not be forced to depend upon interfaces
that they don’t use”. When we simplify it states that when interface is too heavy, just break it
down to the smaller and more specific interfaces which is client oriented so that clients
should only worry about their concerned part.
For example if we have <> interface which has “fly()” method and is implemented by Duck
class. Now if we have wooden duck?
Dependency Inversion Principle (DIP) [also known as Inversion of Control or
Hollywood Principle: Don’t call us, we’ll call you or Dependency Injection]
The Dependency Inversion principle refers to specific form of decoupling where conventional
dependency relationship established from high level. The principle states two things.
1. High-level modules should not depend on low-level modules. Both should depend on
abstractions.
2. Abstractions should not depend upon details. Details should depend upon abstractions.
The main goal of dependency inversion principle is to decouple high-level components from
low-level components in such a manner that reuse of low-level component implementations
become possible.
For example Adapter Pattern does the same thing. The high-level class defines its own
adapter interface which is the abstraction that the high-level class depends on. The adaptee
implementation also depends on the adapter interface abstraction. The high-level has no
dependency to the low-level module since it only uses low-level indirectly through the adapter
interface by working polymorphic methods to the interface which are implemented by the
adaptee and its low-level module.
References
http://www.objectmentor.com/resources/articles/dip.pdf
http://www.oodesign.com/dependency-inversion-principle.html
http://www.oodesign.com/design-principles.html
https://www-01.ibm.com/software/ucd/designconcepts/designbasics.html
http://en.wikipedia.org
Blog this!
Bookmark on Delicious
Digg this post
Recommend on Facebook
Share on FriendFeed
Share on Linkedin
Share on Orkut
share via Reddit

4. Share with Stumblers
Share on technorati
Tweet about it
Subscribe to the comments on this post