Software Design Principles

04 Design & SOLID Principles – 1

Dr. Mostafa Elgendy
[email protected]
Agenda
▪ Overview.

▪ Design principles

▪ Should I Care about SOLID

▪ SOLID principles

▪ Single Responsibility Principle

▪ Open-Closed Principle

▪ Liskov substitution Principle

▪ Summary

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 2

 Overview

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 3

Overview
▪ We have bad habits of writing code containing thousands of lines and numerous
methods or functions in a class.

▪ You can use these points to check whether you are writing bad, dirty code or not :
▪ Does the code implement a design pattern?

▪ Is the code tightly coupled?

▪ Is the code testable?

▪ Is the code human readable?

▪ Is the code duplicated?

▪ Is the code too lengthy to understand

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 4

Overview
▪ Does the code implement a design pattern:

▪ Adopting a design pattern in your code or program is not

compulsory. No one can force you to do this.

▪ Patterns provide an extra, coated layer to your program so that you

can write robustly with little chance of falling

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 5

Overview
▪ Is the code tightly coupled:
▪ Coupling is the manner and degree of interdependence between software modules;
a measure of how closely connected two routines or modules are.

▪ Imagine a scenario in which you’re writing a program of math software and you
need to implement all possible math operations.

▪ You’ve introduced two modules as a part of your implementation.

▪ You’ll need to make changes in both modules whenever you are required to
make changes to either module.

▪ This means your application or software is tightly coupled, which means your
code qualifies as dirty code

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 6

Overview
▪ Is code testable(1/2):
▪ It is good practice to always write tests for your code:

▪ It reduces the reworking time needed due to any unrecovered issue.

▪ It allows for easy determination of whether or not recent changes or refactoring

broke the code.

▪ Helps us to improve code quality and draw our focus to the main purpose of
our task.

▪ It makes sure that new changes are tested and will not break any existing
code functionality

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 7

Overview
▪ Is code testable(2/2):

▪ Writing tests may be time-consuming, and you might have a very

limited timeframe in which to complete your application or code, but
tests are important.

▪ Tests and code work together to achieve better code.

▪ Writing testable code is a good habit to get into as a way of

avoiding future complications.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 8

Overview
▪ Is the code human readable:
▪ Because your code will be read by humans, it should be meaningful code.

▪ While writing code, give meaningful names to your classes, methods,

functions, and module names. Your program will be read by people

▪ In order to make your method name meaningful, don’t hesitate to use a

long name such as Is ValidForCharactersOnly.

▪ Note: Visit your code and see if you can read it. If not, that means
you are writing bad code.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 9

Overview
▪ Is the code duplicated:

▪ It’s possible that you are doing the same things in many places

▪ Revisit and check to see if you have such code.

▪ If so, try to move that code to a common place and use it

throughout your application.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 10

Overview
▪ Is the code too lengthy to understand:

▪ Avoid writing lengthy code. A function can be hard to understand if it

contains thousands of lines.

▪ Developers write lots of code that would be better split into pieces like
small functions or properties.

▪ Lengthy code always creates confusion,

▪ Especially for new developers who did not actually write that code.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 11

Overview

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 12

 Encapsulate what varies

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 13

Encapsulate what varies
▪ This principle suggests, Identify the aspects of your applications
that vary and separate them from what stays the same.

▪ If a component or module in your application is bound to change

frequently,
▪ Separate this part of code from the stable ones

▪ Later. It can be altered without affecting the other ones.

▪ Most design patterns like Strategy, Adapter, Facade, Decorator,

Observer, etc follow this principle.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 14

Example 1
▪ We are designing an app for a company that provides online
service of household equipments.

▪ We have this method processServiceRequest() to create

instance of a OnlineService class based on the
serviceType and process the request.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 15

Example 1

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 16

Solution 1
▪ The type of service is a functionality which is bound to change at
anytime.

▪ We might remove some services or add new and every such

change in implementations would require to change this piece of
code.

▪ So, by the guidelines of “Encapsulate what varies” we need to

find the code which is bound to vary and separate it.

▪ We are going to follow the Factory design pattern.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 17

Solution 1

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 18

 Favor Composition over Inheritance

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 19

Favor Composition over Inheritance
▪ Object oriented programming provides 2 types of
relationships between classes:

▪ has-a (composition)

▪ Is-a (inheritance).

▪ This design principle essentially suggests us that “has-a

relationship should be preferred over is-a relationship

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 20

Favor Composition over Inheritance
▪ Most developers think to use inheritance as their first resort
in most cases to avoid code duplication and maintain
reusability.

▪ Though a good practice, sometimes Inheritance when

overused makes our code more rigid and not extensible

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 21

Example 1
▪ In the previous case,
▪ we have used is-a relationship to manage the OnlineService class with inherited
implementation classes like ACService, WMService, RFService, etc.

▪ If we decide to expand their business massively by adding more

services:
▪ BikeService, CarService, TVService, LaptopService and many other household
services.

▪ The implementation would still hold good with inheritance model.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 22

Example 1
▪ But if we plan to include multiple service models together

▪ multiple kitchen appliances serviced along with AC.

▪ This would lead to creating new classes for separate combination

like ACAndFridgeService, ACAndTVServices. Which is not feasible
and is literally a bad design.

▪ More the combination more vulnerable this design would be to

break.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 23

Example 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 24

Example 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 25

Example 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 26

Solution 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 27

Solution 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 28

Solution 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 29

 Loose Coupling

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 30

Loose Coupling
▪ Components interacting with each others should be
independent of each others, relying on the knowledge of
other component as little as possible.

▪ It is used in a microservice architecture.

▪ The services interacting with each others are independent of each
others.

▪ The interaction is strictly based on the data contracts.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 31

Example 1
▪ We have a form for sign up which would get
the user input, perform client-side validations,
sends request to the server via rest apis, get
the response and based on the response it
decides to show success or failure messages
to the user.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 32

Solution 1
▪ Here, we can split the
functionality into two based
on its ownership.

▪ Ideally, anything specific to

the client side should be
decoupled from the server-
side operations.
19-Feb-24 SOFTWARE DESIGN PRINCIPLES 33
Solution 1
▪ The chunk of code to display,
client-side validations and
display messages to the user
should be separated from the
part of code which makes api
requests, processes the
response and return status.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 34

 Program to interfaces, Not
Implementations
19-Feb-24 SOFTWARE DESIGN PRINCIPLES 35
Program to interfaces, Not Implementations
▪ This design principle guides us to make use of abstract
types not concrete ones.

▪ “Program to interfaces” actually mean program to a super

type like an interface or abstract class.

▪ We are implementing polymorphism by programming to a

super type so that the actual runtime object isn’t locked into
your code.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 36

Example 1
▪ Assume a database accessor layer in your application which is used to
perform CRUD operations on your DB.

▪ Let’s consider that we implement a Service class which calls the

DatabaseClient class (However practically we should have a DataAccessor
class between Service and DatabaseClient).

▪ The DatabaseClient is concrete class programmed to access postgres DB.

▪ The DatabaseClient is a heavy duty class with all helper methods required to
access the DB.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 37

Example 1
▪ Assume that the client decides to switch to a NoSQL
database like MongoDB or add it as a secondary database
for some specific purposes.

▪ This would lead to rewriting the DatabaseClient which would

complicate things.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 38

Solution 1
▪ As this principle states, any such modules should have an
abstract super type like an interface.

▪ The basic methods should be made available in the

interface.

▪ Specific implementations should be implementing the

interface.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 39

Solution 1

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 40

 KISS

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 41

KISS principle
▪ keep it simple, stupid principle

▪ Also used as an acronym for

▪ keep it short and simple,

▪ keep it short and sweet

▪ keep it simple and straightforward.

▪ However, all these variations refer to the same approach.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 42

KISS principle
▪ Is a key to building a successful product is simplicity.

▪ The KISS method applies to the design and development of

digital products, but it’s also widely used in other fields, such
as management or engineering.

▪ keep things simple rather than complex.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 43

Advantages of KISS principle
▪ Users don’t want to waste time.

▪ A simpler software structure makes testing, including also

automated testing, easier and more effective.

▪ Reduced codebase complexity makes maintenance and

onboarding of new team members mid-project easier and
faster

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 44

 YAGNI

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 45

YAGNI principle
▪ You aren’t gonna need it

▪ It requires software developers to work on functionalities when

they’re actually needed

▪ Not when they assume that something might be useful in the future.

▪ The YAGNI principle is also important when implementing Agile

▪ The development team should focus only on the current iteration to deliver
the agreed scope in time.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 46

Advantages of YAGNI principle
▪ The main goal of the YAGNI principle is to avoid spending
time and money on overengineering things that you think
you will need later on.

▪ Because in the end, it usually turns out that you don’t need it, or that
what you need is different from what you expected.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 47

Advantages of YAGNI principle
▪ The primary benefit of using YAGNI is a more cost-optimized
product development process due to:
▪ Better developer performance:

▪ The team focuses on delivering the current requirements effectively.

▪ They don’t spend time and effort on guesses.

▪ More flexible codebase:

▪ You don’t have to find ways to use suboptimal solutions that you had
already developed before you had the full picture.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 48

 DRY

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 49

DRY principle
▪ Don’t repeat yourself.

▪ Recommends reducing the repetition of software patterns.

▪ DRY should be applied across the whole system, including

not only in the codebase but also in testing and
documentation.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 50

Advantages of DRY principle
▪ Ensures that any modification of a single element of a
system does not require a change in other, logically
unrelated elements.

▪ It’s an effective way of streamlining the development

process.

▪ In addition, elements that are logically related change

predictably and uniformly, which keeps them in sync.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 51

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 52
SOLID principles
▪ An object-oriented approach that are applied to software
design.

▪ Conceptualized by Robert C. Martin (also known as Uncle Bob).

▪ Ensures that the software is modular, easy to understand, debug,

and refactor.

▪ It does not teach people how to program. Instead, SOLID principles

help programmers write better code.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 53

SOLID principles
▪ Have five principles:

▪ Single Responsibility Principle.

▪ Open-Closed Principle.

▪ Liskov substitution Principle.

▪ Interface Segregation Principle

▪ Dependency Inversion Principle

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 54

 Should I Care about SOLID

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 55

Should I Care about SOLID
▪ Before we examine the many reasons why we should care
about SOLID, let’s address the reasons people give for not
using it:

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 56

Reasons people give for not using it
▪ I implement OOP:
▪ People who use OOP often say they do not want to use SOLID.

▪ OOP provides a paradigm to write programming, paradigms are not

principles that instruct you about the kind of responsibilities a class should
have.

▪ Writing OOP doesn’t guarantee that you follow design principles.

▪ You should care about SOLID even if you’re writing object-oriented

programming.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 57

Reasons people give for not using it
▪ I can implement design patterns:

▪ Design patterns only tell us how to design programs and software.

But SOLID principles guide us in making our code better and
cleaner.

▪ Design patterns never guides us on making our code cleaner and

better placed.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 58

Reasons people give for not using it
▪ I use Java, or .NET/C#:

▪ SOLID principles are not related to any programming language,

▪ They are not built for any specific programming languages

▪ SOLID principles are simply guidelines for making our code and
programming robust.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 59

 (S) Single Responsibility Principle

19-Feb-24 60
Single Responsibility Principle
▪ A class should have only one reason to change.

▪ Every class should have a single responsibility or single job or single

purpose.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 61

Single Responsibility Principle
▪ Software systems are changed to satisfy users and
stakeholders;

▪ Stakeholders are the “reason to change” that the principle is talking

about.

▪ We can rephrase the principle to say this:

▪ A module should be responsible to one, and only one, user or

stakeholder(Actor).

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 62

Single Responsibility Principle
▪ Writing a class responsible for doing several tasks
▪ Modifying data, retrieving data, and saving data.

▪ Writing function that perform several operations at the same time.

▪ Writing a function that connect to database, retrieve data and display these data.

▪ If there this any modification or the logic changed

▪ Need to change our classes many times and in many places

▪ This would introduce more bugs and more code changes

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 63

Example 1
▪ Imagine there is a class called BankService which performs
following operations.
▪ Withdraw.

▪ Deposit

▪ Print Pass Book

▪ Get Loan Info

▪ Send OTP

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 64

Example 1
▪ The class has multiple reasons to change.
▪ getLoanInterestInfo() method

▪ Now bank provide info for Personal Loan, Home Loan and car loan.

▪ People may want to provide some other loan feature like study loan then again
you need to modify this class.

▪ sendOTP() method

▪ BankService support sendOTP medium as an email

▪ People may want to introduced send OTP as Phone then again you need to
change its implementation.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 65

Solution 1
▪ We should implement a separate class that performs a
single functionality only.

▪ Print related code snippet to Printer Service:

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 66

Solution 1
▪ Loan related job.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 67

Solution 1
▪ OTP related Job

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 68

Example 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 69

Solution 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 70

Example 3

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 71

Solution 3

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 72

Solution 3

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 73

Symptoms of violating SRP
▪ Accidental Duplication

▪ Merges: It's not hard to imagine that merges will be common

in source files that contain many different methods

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 74

 (O) Open-Closed Principle

19-Feb-24 75
Open-Closed Principle(OCP)
▪ A software artifact should be open for extension but closed for
modification.

▪ The behavior of a software artifact ought to be extendible,

without having to modify that artifact.

▪ This principle states that “ software entities (classes, modules,

functions, etc.) should be open for extension, but closed for
modification ” which means you should be able to extend a class
behavior, without modifying it.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 76

How to implement OCP
▪ I can be achieved by using

▪ abstract classes and add the new functionality to derived class.

▪ Interface which can be implemented.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 77

Example 1
▪ We have Employee class

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 78

Example 1
▪ We have to modify

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 79

Solution 1
▪ Abstract class

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 80

Solution 1
▪ Abstract class

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 81

Solution 1
▪ Interface

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 82

Solution 1
▪ Interface

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 83

Solution 1
▪ Interface

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 84

Example 2
▪ Consider the same NotificationService which we just created.

▪ If you want to introduced send OTP via mobile Phone or

WhatsApp number, then you need to modify source code in
Notification Service

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 85

Solution 2

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 86

Solution 2
▪ Email Notification implementation

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 87

Solution 2
▪ Mobile Notification implementation

▪ Similarly you can add implementation for WhatsApp

notification service

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 88

 (L) Liskov substitution Principle

19-Feb-24 89
Liskov substitution Principle(LSP)
▪ Derived or child classes must be substitutable for their base or
parent classes.

▪ In other words, if class A is a subtype of class B, then we should

be able to replace B with A without interrupting the behavior of
the program.

▪ This principle is bit tricky and interesting all it designed based on

Inheritance concepts ,so let’s better understand this with an
example

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 90

Liskov substitution Principle(LSP)

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 91

Example 1
▪ Consider I have an abstract class called SocialMedia , who
supported all Socialmedia activity for user to entertain them
like below.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 92

Example 1
▪ Social media can have multiple implantation or can have
multiple child like Facebook, WhatsApp, instagram and
Twitter.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 93

Example 1
▪ WhatsApp class.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 94

Example 1
▪ due to publishPost() method whatsapp child is not substitute
of parents SocialMedia because whatsapp doesn’t support
upload photos and videos for friend it’s just achatting
application so it doesn’t follow LSP.

▪ Similarly instagram doesn’t support groupVideoCall() feature

so we say instagram childis not substitute of parents
SocialMedia.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 95

Solution 1
▪ Social media interface.

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 96

Solution 1

19-Feb-24 SOFTWARE DESIGN PRINCIPLES 97

Summary
▪ Overview.

▪ Design principles

▪ Should I Care about SOLID

▪ SOLID principles

▪ Single Responsibility Principle

▪ Open-Closed Principle

▪ Liskov substitution Principle

19-Feb-24 MOBILE PROGRAMMING 98

 Questions

19-Feb-24 MOBILE PROGRAMMING 99