8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
Sunday, August 3, 2025
Home About Privacy Policy Terms & Conditions Disclaimer Contact Us
Guest Post
JavaTechOnline
Making Java Easy To Learn
You are here
Home > Design Principles >
SOLID Principles-The Open Closed Principle
Design Principles Core Java java by devs5003 - May 18, 2023 0
Last Updated on July 31st, 2025
Almost
everywhere
when we talk
about delivery of
a product, the
first step comes
in mind is it’s
design. The
more focus we
put into the
design, the
better the
product will
look. Every
design has
some design principles that need to be followed while designing a product. Hence,
design principles have a crucial role in any product delivery. Design Principles also help
https://javatechonline.com/solid-principles-the-open-closed-principle/ 1/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
teams with decision making. In this article, We will discuss about ‘SOLID Principles-The
Open Closed Principle’.
A few simple principles or valuable questions can guide our team towards taking relevant
decisions. SOLID Principles are the set of five principles used to design a software. In
fact, the word ‘SOLID’ is the acronym for the set of five principles that contains the first
letter of each principle. Let’s discuss SOLID Principles-The Open Closed Principle in
detail and related concepts.
Table of Contents
1. What is SOLID Principles-The Open Closed Principle?
1.1. What are the ways of extending a class ?
1.2. Example: Code that violates OCP
1.3. Example: Code that follows OCP
2. What is the benefits of Open Closed Principle?
2.1. Easier Extensibility
2.2. Easier to Maintain
2.3. Flexibility
3. What is the limitations of Open Closed Principle?
4. What are the Design Patterns that follow Open Closed Principle?
5. FAQs
6. Links to Other Design Principles
6.1. Single Responsibility Principle
6.2. Liskov’s Substitution Principle(LSP)
6.3. Interface Segregation Principle(ISP)
6.4. Dependency Inversion Principle(DIP)
ADVERTISEMENT
What is SOLID Principles-The Open Closed
Principle?
The principle says, “Software components should be open for extension, but closed
for modification”. Simply put, Software components like classes, modules, and
functions should be open for extension but closed for modifications.
If we consider our software component as a class, then Classes should be open for
extension, but closed for modification. In doing so, we stop ourselves from modifying
https://javatechonline.com/solid-principles-the-open-closed-principle/ 2/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
existing code. Therefore, we also stop causing potential new bugs in an otherwise happy
application.
Of course, the one exception to the rule is when fixing bugs in existing code. So, we
should modify our class only at the time of bug fixing.
“Open to extension” means that you should design your classes so that new functionality
can be added as new requirements are generated. “Closed for modification” means that
once you developed a class you should never modify it, except to correct bugs.
These two parts of the principle appear to be contradictory. However, if you correctly
structure your classes and their dependencies, you can add functionality without editing
existing source code.
Design and code should be done in a way that new functionality should be added with
minimum or no changes in the existing code. When needs to extend functionality – avoid
tight coupling, don’t use if-else/switch-case logic, do code refactoring as required.
What are the ways of extending a class ?
The ways of extending a class include:
Inheriting from the class
Overwriting the required behaviors from the class
Extending certain behaviors of the class
Generally, you achieve this by referring to abstractions for dependencies, such as
interfaces or abstract classes, rather than using concrete classes. We can add the
functionality by creating new classes that implement the interfaces. This reduces the risk
of introducing new bugs to existing code, leading to more robust software.
Example: Code that violates OCP
Let’s assume that we have to write a program that calculates area of various shapes. We
start with creating a class for our first shape, let’s say Rectangle which has 2 attributes
length & width.
public class Rectangle {
public Double length;
https://javatechonline.com/solid-principles-the-open-closed-principle/ 3/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
public Double width;
}
Further, we create a class to calculate the area of this Rectangle which has a method
calculateRectangleArea() which takes the Rectangle as an input parameter and
calculates its area.
public class AreaCalculator {
public Double calculateRectangleArea(Rectangle rectangle) {
return rectangle.length * rectangle.width;
}
}
So far so good. Now let’s assume we have to write a program for our second shape
circle. So, we promptly create a new class Circle with a single attribute radius.
public class Circle {
public Double radius;
}
Then we modify AreaCalculator class to add circle calculations through a new method
calculateCircleArea().
public class AreaCalculator{
public Double calculateRectangleArea(Rectangle rectangle){
return rectangle.length * rectangle.width;
}
public Double calculateCircleArea(Circle circle){
return (22 / 7) * circle.radius * circle.radius;
https://javatechonline.com/solid-principles-the-open-closed-principle/ 4/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
}
}
However, please note that there are flaws in the way of designing our solution above.
Let’s say we have a new shape pentagon. In that case, we will again end up modifying
the AreaCalculator class. As the types of shapes grows this becomes messier as
AreaCalculator keeps on changing and any consumers of this class will have to keep on
updating their libraries which contain AreaCalculator. As a result, AreaCalculator class
will not be baselined(finalized) with surety as every time a new shape comes, it will be
modified. So, this design is not closed for modification.
AreaCalculator will need to keep on adding their computation logic in newer methods.
We are not really expanding the scope of shapes; rather we are simply doing piece-
meal(bit-by-bit) solution for every shape that is added.
Example: Code that follows OCP
Let’s now see a more elegant design which solves the flaws in the above design by
adhering to the Open/Closed Principle. First of all, we will make the design extensible.
For this we need to first define a base type Shape and have Circle & Rectangle
implement Shape interface. For example, below code demonstrates the concept.
public interface Shape {
public Double calculateArea();
public class Rectangle implements Shape {
Double length;
Double width;
public double calculateArea() {
return length * width;
}
}
public class Circle implements Shape {
https://javatechonline.com/solid-principles-the-open-closed-principle/ 5/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
public Double radius;
public Double calculateArea() {
return (22 / 7) * radius * radius;
}
}
As aforementioned, there is a base interface Shape. All shapes now implement the base
interface Shape. Shape interface has an abstract method calculateArea(). Both circle &
rectangle provide their own overridden implementation of calculateArea() method using
their own attributes. If in future we want to calculate area of other shapes like triangle,
square etc., we can implement the Shape interface without changing any class.
We have brought in a degree of extensibility as shapes are now an instance of Shape
interfaces. This allows us to use Shape instead of individual classes.
The last point is the consumer of these shapes. The consumer will be the AreaCalculator
class which would now look like this.
public class AreaCalculator {
public Double calculateShapeArea(Shape shape) {
return shape.calculateArea();
}
}
This AreaCalculator class now fully removes our design flaws noted above and provides
a clean solution which adheres to the Open-Closed Principle.
What is the benefits of Open Closed Principle?
Below are some of the benefits of applying open closed principle in your code :
Easier Extensibility
https://javatechonline.com/solid-principles-the-open-closed-principle/ 6/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
Needless to say, Open-closed Principle offers a better extensibility to your code. When
you write your code in such a way that it has no modification and allows extension, you
will get better extensibility on it’s own.
Easier to Maintain
The Principle suggests using interfaces. Interfaces in code offers an additional level of
abstraction which in turn enables loose coupling. The implementations of an interface are
independent of each other and don’t need to share any code. Hence, you can easily
maintain your code with client’s keep changing requirements.
Flexibility
When you follow the open closed principle in writing your code, you will have better
flexibility to extend it. Further, if any change request arises in future, your code will be
more flexible to extend.
What is the limitations of Open Closed Principle?
Whenever we incorporate any change to the code as an extension, we need to do unit
testing before and after implementing the same.
What are the Design Patterns that follow Open
Closed Principle?
There are multiple of design patterns that help us to extend code without changing it. For
example, the Decorator pattern offers us to follow the Open Close principle. Furthermore,
we may use the Factory Method, Strategy pattern and the Observer pattern to design an
application with minimum changes in the existing code.
FAQs
How does OCP help in agile software development practices?
OCP helps in agile practices by promoting code that is more adaptable to frequently
changing requirements. It facilitates incremental development and makes it easier to
accommodate new user stories or features during sprints.
Does OCP apply only to classes, or does it also relate to methods and modules?
https://javatechonline.com/solid-principles-the-open-closed-principle/ 7/11
8/3/25, 9:54 PM SOLID Principles-The Open Closed Principle - JavaTechOnline
OCP applies to all software entities, including classes, methods, and modules. Any unit
of code that can be extended without modification while maintaining existing
functionality follows OCP.
How does OCP relate to the use of design patterns in software development?
Many design patterns, such as the Strategy Pattern and Decorator Pattern, adapt OCP
by allowing us to extend functionality without modifying existing classes. Design patterns
generally provide practical ways to implement OCP.
What is the main goal of the Open-Closed Principle (OCP)?
The primary goal of OCP is to encourage code extensibility and maintainability. It allows
us to add new features or behaviors to a system without having to modify existing,
working code, reducing the risk of introducing bugs.
Does applying OCP mean that no code modification is allowed once a class is
defined?
No, OCP does not mean that code should never be modified. Alternatively, it suggests
that modifications should be limited to fixing bugs or making essential improvements, not
for adding new features or behaviors.
That’s all about ‘SOLID Principles-The Open Closed Principle’. Moreover, Wikipedia
defines this Principle like this. In order to learn the most commonly used design
principles, kindly visit article on ‘OOPs Design Principles‘. Apart from ‘SOLID Principles-
The Open Closed Principle’, other principles are discussed as separate articles
respectively.
Links to Other Design Principles
Single Responsibility Principle
Liskov’s Substitution Principle(LSP)
Interface Segregation Principle(ISP)
Dependency Inversion Principle(DIP)
Like
https://javatechonline.com/solid-principles-the-open-closed-principle/ 8/11
