SOLID principle and how it helps in satisfying design goals low coupling and high cohesiveness, during this paper we have discussed how SOLID principles can help designers towards better cohesive design, and lower coupling with examples.

1. Faculty of Engineeeing and Technology
Master in Software Engineering Program
SOLID principle and how it helps in satisfying design goals
low coupling and high cohesiveness
Prepared by
Mohammad Shawahneh
1155294
Instructor
Dr. Yousef Hassouneh

2. Contents
Introduction ................................................................................................................................................ 2
Coupling...................................................................................................................................................... 3
Cohesion..................................................................................................................................................... 3
Single Responsibility Principle..................................................................................................................... 3
.................................................................................................................................................................... 4
Open Close Principle................................................................................................................................... 4
Liskov Substitution Principle....................................................................................................................... 5
Interface Segregation principle................................................................................................................... 7
Dependency Inversion Principle ................................................................................................................. 9
Conclusion ................................................................................................................................................ 10
References ................................................................................................................................................ 10
Introduction
Software products evolve, it usually live longtime, even it may start with small defined list of
requirements which may appear simple that managers, designer and developers may think it can be
delivered without exerting much effort and consuming valuable times in considering future aspects
which are not even requested or known at the moment. But in reality software products usually start as
a short term products and ends up in years of development and maintenance, moreover, the nature of
software products which is unlike classical manufactured products, and can be easily maintained,
changed, updated, or extended by adding more features and functionalities at any point of time in its
life cycle, motivated software product owners and customers to continuously ask for functional and
quality evolutions.
To address such a nature of software products a need for keeping an eye on where the software product
will be next, rather than where it is now appeared, and on complexities which will be added later on
software structure, design and implantation. That’s attracted the attention to introduce early solutions
which are if software designers followed at early stages will help providing high quality and easily
evolved software product, different design principles was introduced to help organizing and arranging
structural components in a managed way that help providing high quality and easily extensible software
products[1].
Among these principles, S.O.L.I.D principles which stand for Single responsibility principle (SRP), Open-
closed principle (OCP), Liskov substitution principle (LSP), Interface segregation principle (ISP) and

3. Dependency inversion principle (DIP), is a robust well-known solution which will provide a well-
structured, easily change and maintain software when applied in a software design. Given that a good
software product is modular, SOLID help discarding code smells, like, rigidity, fragility, high coupling and
low cohesion.
In this discussion we will elaborate in SOLID principles and how they help in solving high coupling and
low cohesion problems.
Coupling
Coupling refers to the extent to which modules, classes or constructs are dependent upon each other,
and can be affected by changing of each other, such that developer might be affect other coupled
modules when changing on a tightly coupled module[2], among characteristics of good design are
loosely coupled modules or classes, as zero coupling means no system at all, and tightly coupled system
leads to a complex system and to difficulties in maintenance and extensibility, low coupling can be
achieved by controlling connections among modules in a systematic way to the a least reliable extent.
Coupling is classified into numerous taxonomies and dimensions according to literature[3,4] , from
which we will concentrate on interaction and inheritance coupling and how it was handled by SOLID
principles, as there is no room to elaborate more in this limited discussion.
Cohesion
Cohesion refers to the extent to which a desirable connection among the elements of a single module or
class and how that module parts are connected together so as to do its correlated work in a desirable
interaction and dependencies, high cohesion helps find system and code parts easily, that is once we
find one parts all will be there, also it helps define scope of interacted related code. A good design is
intended to have high level of cohesion[3].
We will elaborate in class and inheritance cohesion types and how they were solved by SOLID principles.
Single Responsibility Principle
This principles states that a class or a software entity should have only one reason to be changed, that
does not mean one reason for exist, because that will lead to a situation where a class may have only
one method and still exists, but change is better describing requirements that if done will be referred
later in a well-known reason.
If a class breaks this responsibility and thus it has more reasons to be changed, that means it will be
tightly coupled with more classes and modules as other classes will use it directly for accessing that
functionalities, and any change on one responsibility of the class may affect other coupled classes that
do not mind about the changed functionality causing a fragility in the software all.

4. A class that satisfies a one responsibility will have all its parts highly cohesive together to achieve that
goal, and there will be no logic in adding elements that class does not need to have, but for example
given a class with three responsibilities, it will have three punch of elements that are not cohesive at all,
or if having some kind of cohesion, that type will be a bad cohesion and hence it is a coupling that makes
the class fragile and rigid.
A one reason to change responsibility will empower the high cohesion, and provide a tightly coupled
class in its module, and decrease the effect of any change and keeping it under control[5].
See figures 1,2 that shows before SRP and after.
Figure1
Figure 2
Open Close Principle
This principle states that a class or a software entity should be open for extension but closed for
modification. That means the class should be open for behavioral extension on requirement change or
newly requested while it is keeping its original behavior and responsibility and characteristics, that can
be achieved by building a design that enables extending the existing code, using a level of abstraction
that can be untouched along software lifecycle, and still providing possibility to extend using design
patterns like strategy, observer, decorator and template design patterns[5].
This principle contributes much to cohesion by gathering correlated functionalities in the abstraction
level and in the extended behavior, it also provides a level of desirable inheritance coupling[2], as the
class will have a limited connections to it during its life cycle, and will be referred to by inheritance of it
directly or of a class it is using. See fig 3, 4

5. Figure 3
Figure 4
Liskov Substitution Principle
This principle states that a subclass must be semantically possible to substitute it parent class without
breaking the functionality of that parent class. This can be achieved by defining a well-structured level of
abstraction and use inheritance in a manageable manner where the relation is totally applied rather
than for code reuse or even is-a relationship which can violate principle in some cases[5].

6. Such a structure provides a strongly cohesive inheritance where parts are working together in a
systematic manner that doesn’t contradict each other, and also inside a class the cohesion will be high
due to similarities in the functionalities class are doing for not going beyond the original defined
responsibility in the base class.
The principle also empowers the low coupling in a considerable contribution, as it is logically possible for
modules to refer to the base class in a loosely coupled connection, and get benefit of polymorphism
injecting the desired implementations as needed and still use the base class for communicating with
module. See figures 5,6
Figure 5

7. Figure 6
Interface Segregation principle
This principles state that a client or module should not be forced to depend on interfaces or interface
parts that it does not need. So the key is that as a class to use only what the interfaces that you need.
This principles can be broken by fat interfaces and forces the client to throw exceptions or provide
empty implementations on unneeded methods, one solution is to provide related thin interfaces which
do one related thing and use them where needed, another is by delegation of functionalities[5].
Having only related parts inside a class will empower the cohesion among its elements, as there will be
no unrelated methods or implementation that astonish the user and decrease the cohesion.
Also fat interfaces will be referenced by many modules each of which needs a specific functionality but
obliged to implement all, this makes those interfaces tightly coupled in the modules, but when applying
this principle the coupling will be to its lowest extent as connections go only where needed, and the
change will not cause any cascade fragility. See figures 7,8

8. Figure 7
Figure 8

9. Dependency Inversion Principle
This principle states that high level modules should not depend on low level modules, but both should
depend on abstractions, and also abstractions should not depend on details, details should depend on
abstractions.
This principle empowers the cohesion by means of strengthening the abstractions, so that parts inside
the abstraction layer are cohesive together to provide desirable functionalities, same in the detailed
layers below.
It also decouple the system by providing a flow of responsibilities using abstractions, empowering the
system layering in a controlled loosely coupled manner, it also removes the coupling of the system with
its details, so that no error can cascade to the above abstractions or layers. See figures 9. 10
Fig 9

10. Fig 10
Conclusion
SOLID principles provide a reliable solution for design smells and for software extensibility and change, it
solved the problem of high coupling and low cohesion in a systematic robust manner if applied together
in the right way.
References
[1] Haoyu, Wang, and Zhou Haili. "Basic Design Principles in Software Engineering." Computational and
Information Sciences (ICCIS), 2012 Fourth International Conference on. IEEE, 2012.
[2] http://www.codemag.com/article/1001061
[3] Eder, Johann, Gerti Kappel, and Michael Schrefl. "Coupling and cohesion in object-oriented
systems." Technical Reprot, University of Klagenfurt, Austria(1994).
[4] https://en.wikipedia.org/wiki/Coupling
[5] Martin, Robert C., and Micah Martin. Agile principles, patterns, and practices in C#. Pearson
Education, 2006.