Scribd
Upload
66 views

Design Principles and Patterns

The document discusses design principles and patterns. It outlines principles like single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion. These principles help create software that is less complex, more readable, extensible and maintainable by reducing errors and improving reusability and testability. Specifically, it notes principles like classes should have a single responsibility and be open for extension but closed for modification to allow adding new code without changing existing code.

Uploaded by

John Miguel Macaranas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
66 views

Design Principles and Patterns

The document discusses design principles and patterns. It outlines principles like single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion. These principles help create software that is less complex, more readable, extensible and maintainable by reducing errors and improving reusability and testability. Specifically, it notes principles like classes should have a single responsibility and be open for extension but closed for modification to allow adding new code without changing existing code.

Uploaded by

John Miguel Macaranas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Design Principles and

Patterns
GROUP 1
Overview of Design Principles

 The designing and development of the software are performed


in the design phase of a software development project.
 When developing the software of the project, generally there
are changes in the requirements document that may occur, such
as the client adding additional requirements or changing a
requirement.
 These changes could affect the development of the software
where there is a need to apply changes on the source codes.
Three (3) Important Characteristics of a bad
design architecture that should be avoided

 Rigidity – The software is hard to change because every


applied change will affect many parts of the software.
 Fragility – When applying changes, unexpected parts of the
software breaks.
 Immobility – The modules of the software are hard to reuse
in another software because these cannot be extracted from
the current software.
Design Principles
▪ Are the set of guidelines to be followed that helps
developers arrange methods and data structures into
classes should be interconnected, which can adapt to
the changes in requirements without major code
rewrites.
The SOLID Principles

 S: Single Responsibility Principle (SRP) – This is one of the basic principles most developers apply to build
robust and maintenance software. This suggests that each software module, class, or interface should have
only one (1) reason to change.
 O: Open-Closed Principle (OCP) – This states that for a software to be easy to change, the software classes
must be designed to allow the behavior of those classes to be changed by adding new code rather than
changing existing code.
 L: Liskov Substitution Principle (LSP) – Barbara Liskov introduced this principle which states that derived
clases should be substitutable for their base classes to build a software from interchangeable modules or
classes.
 I: Interface Segregation Principle (ISP) – This principle advises software designers to avoid depending on
things that they don’t use.
 D: Dependency Inversion Principle (DIP) – This principle suggests that flexible software are those with
classes that depend on abstract classes or interfaces.
Following these priciples help
developers to achieve the following:

 Reduce the complexity of source codes


 Increase readability, extensibility, and
maintenance
 Reduce accidental errors and implement
reusability easily
 Achieve easier and better software testing.
SINGLE RESPONSIBILITY
PRINCIPLE (SRP)
 Itistruct the developers to design each
module, interface, or class of a software
system to have only one (1) responsibility.
 The software systems are changed to satisfy
the needs of the users or actors.
Users – are the “reason to change” that the
principle reffering to.
Bad Design Architecture
Good Design Architecture
Open-Closed Principle
- The OPEN-CLOSED PRINCIPLE (OCP) state that
software modules,interfaces, or classes should be
open for extension but closed for modification.
- OCP Suggests not to add functionality on the class
that has been already tested and is working properly,
but rather to extend that class for adding new
functionality.
- To apply this principle, abstract the class using
inheritance or interfaces.
Example class that violates OCP
- For every newly added
method , the unit testing
of the software should be
be done again
- When a new require is
added, the maintenance
and adding function may
take time.
- Adding a new requirement
might affect the other
functionality of software
even if the new
requirements work.
IMPLEMENTING THE OCP
- To implement
the OCP, use an
interface , an
abstract class, or
abstract methods
to extend the
functionality of
the class
Liskov Substitution Principle

 TheLiskov Substitution Principle (LSP) suggests that when


creating a new derived class of an existing class, make sure that
the derived class can be a substitute for its base class. This
means that all the derived classes of a base class should be able
to perform the same behavior of their base class without
negative side effects.
Interface Segration Principle (ISP)

 Clients should not be forced to implement interfaces they


don’t use.
 One (1) big interface, several interface are preffered based
on groups of methods where each interface serves one (1)
submodule.
 Dependency Inversion Principle (DIP)
The DIP states the following parts:

A. High-level classes should not be dependent on low-level classes. Both of them should
depend on abstractions.
- Is a class does something significant in the application, while a low-level class is a class that
does secondary work.

B. Abstractions should not depend upon details. Details should depend upon abstractions.
- This means that developers must design the abstract class by looking at the needed details of
of the class.

EmailNotifier <<use>> UserManager


+ notifyClient(): void + changePassword(): void

Figure 8. High-level class depends on a low-level class


Example solution using DIP

<<interface>> <<use>> UserManager


INotifier
+ UserManager (notifier)
+ notifyClient(): void
+ changePassword(): void

EmailNotifier SMSNotifier PopupNotifier


Figure 9. Design conforming to DIP

You might also like