Scribd
Upload
5 views4 pages

Role of Design Principles Including Single Responsibility Principle and Open Closed Principles

The document discusses two key design principles in software development: the Single Responsibility Principle (SRP) and the Open-Closed Principle (OCP). SRP emphasizes that a class or method should have only one responsibility to simplify code management and reduce complexity, while OCP states that software entities should be open for extension but closed for modification, allowing new functionalities to be added without altering existing code. Adhering to these principles enhances code maintainability, reduces bugs, and improves overall software quality.

Uploaded by

arpiarpi1663
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
5 views4 pages

Role of Design Principles Including Single Responsibility Principle and Open Closed Principles

The document discusses two key design principles in software development: the Single Responsibility Principle (SRP) and the Open-Closed Principle (OCP). SRP emphasizes that a class or method should have only one responsibility to simplify code management and reduce complexity, while OCP states that software entities should be open for extension but closed for modification, allowing new functionalities to be added without altering existing code. Adhering to these principles enhances code maintainability, reduces bugs, and improves overall software quality.

Uploaded by

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

role of design principles including single responsibility principle

The Single Responsibility Principle (SRP)


The idea behind the SRP is that every class, module, or function in a program
should have one responsibility/purpose in a program. As a commonly used
definition, "every class should have only one reason to change".

1. Your class or method should have only one reason to change.


2. Your class or method should have only one responsibility to take care of.
So what does that mean actually? While you design your logic in either class or
method, you should not be writing all kinds of responsibilities in one place. This
will make your code quite complex and unmanageable. It will also be difficult to
adjust new changes later as there are high chances it will affect the other
functionality and you will end up testing all the functionalities even though it is a
smaller change. Let’s take the example below.

The class Invoice consists of 4 different methods – AddInvoice(),


DeleteInvoice(), GenerateReport(), EmailReport(). As the single responsibility
principle says, your class or method should have only one responsibility and only
one reason to change, now let’s find out whether the above example satisfies the
conditions. If we take a look at the methods, each has a single responsibility. For
e.g. The AddInvoice() method is only responsible for adding an invoice to the
system, DeleteInvoice() method is only responsible for deleting invoices,s and
likewise for GenerateReport() and EmailReport() methods. We can say that
methods do satisfy the single responsibility principle. But if you take a look at
Invoice class, it is now taking care of multiple responsibilities which are not
satisfying the single responsibility principle. So in order to satisfy the single
responsibility principle for class Invoice, we will divide the methods into
different classes where one class will take care of only one responsibility.

We are going to club methods AddInvoice() and DeleteInvoice() into single class
Invoice as they do a similar kind of functionality. Whereas we will be creating
separate classes Report and Email for methods GenerateReport() and
EmailReport() respectively as they are completely independent and have different
functionality.
role of design principles including open closed principle

In object-oriented programming, the open–closed principle (OCP) states


"software entities (classes, modules, functions, etc.) should be open for extension,
but closed for modification that is, such an entity can allow its behaviour to be
extended without modifying its source code.

The name open–closed principle has been used in two ways. Both ways use
generalizations (for instance, inheritance or delegate functions) to resolve the
apparent dilemma, but the goals, techniques, and results are different.

Well, in the land of software development, it’s possible for an item to be opened
for extension and be closed for modification. It means you or your team members
should be able to add new functionalities to an existing software system without
changing the existing code.

The open-closed principle encourages software engineers to focus on what’s


necessary when it’s time to add new functionalities.

If you want to add new functionality to your existing code and you have to modify
it before you add the new functionality, then you are not following the open-closed
principle.
Why Should You Use the Open-Closed Principle?
Here are some reasons why you should be using the open-closed principle:

 You don’t need to re-invent the wheel: as the principle states, the code you and
your team are working on is closed for extension. This means if you’re following
the open-closed principle, you don’t need to reinvent the wheel (and rebuild
everything) when you want to add new features.
 You focus on what is necessary: as the OCP states, your code is closed for
modification. It means you can add new features without performing too much
editing on the existing code, or none at all. This can help you and your team
members focus on what is necessary when it’s time to implement new
functionalities.
 You can avoid bugs: since you don’t have to edit the existing code before adding
new features, you can avoid introducting unnecessary bugs.
-Your code is more maintainable, testable, and flexible: following the OCP will
make your codebase loosely coupled. With this the code is more flexible and
maintainable. And if you want, you can unit test each class successfully.

You might also like