Open-closed principle
The open-closed principle is a software design principle that software entities should be open to extension but closed to modification.
Software Design for Python Programmers
The Open-Closed Principle states that a class should be closed to modification but open to extension.
- How it is used
- Uses stable superclasses and focused extensions to add behavior without propagating modifications through dependent classes.
- How deep it goes
- Explains superclass design, private state, inherited calls, abstract methods, and runtime strategies, while warning against unnecessary subclass complexity.
- Examples
- Demonstrates book attributes, mammals, and sports whose specialized subclasses or strategies extend stable common implementations.
- What you can do after
- Build it from scratch by isolating common behavior, hiding implementation details, and adding specialized subclasses or interchangeable strategies.
Read how Software Design for Python Programmers explains open-closed principle →
Object-Oriented Software Design in C++
A design principle stating that software entities should be closed for modification but open for extension.
- How it is used
- Uses stable superclasses and specialized subclasses to add book or animal functionality without changing common code.
- How deep it goes
- Explains stability, encapsulation, subclass extension, and warning signs but stops short of prescribing inheritance for every design.
- Examples
- Demonstrates book attributes, Shape subclasses, and Mammal subclasses including Human and Cat.
- What you can do after
- Evaluate designs for stable common abstractions, useful extensions, hidden implementation, and harmful subclass or type-checking growth.
Read how Object-Oriented Software Design in C++ explains open-closed principle →
AI-Powered Developer: Build software with ChatGPT and Copilot
A software-design principle stating that software entities should be open for extension but closed for modification.
- How it is used
- Guides an extensible IT asset-management model as new asset types and depreciation behaviors are introduced.
- How deep it goes
- Defines OCP briefly and illustrates it through inheritance and strategy-interface changes, without developing a fuller implementation procedure.
- Examples
- Uses an Asset–Hardware hierarchy, possible Software and Pitchfork subclasses, and multiple depreciation strategies.
- What you can do after
- Evaluate/understand whether a class model can accept new asset types or calculation strategies without modifying established entities.
Related concepts
- superclassconfigures · A superclass is a class from which another class inherits members, structure, state, or behavior.
- SOLID principleskind of · The SOLID principles are five object-oriented software-design principles concerning single responsibility, openness to extension, substitutability, interface segregation, and dependency inversion.
- separation of concernsaddresses · Separation of concerns is a design principle that organizes a system so distinct responsibilities are handled by separate, independently manageable parts.
- handlercontrasts with · A handler is a callable or software component that processes an event, request, message, or other input and performs associated processing.
- encapsulationuses · Encapsulation is a software design principle that contains state and implementation details behind a controlled interface, limiting direct access from outside.
- couplingproduces · Coupling is the degree of dependency between software components, including how their behavior, availability, or changes affect one another.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.