## **Open Closed Principle**
## **Introduction** ##
Over the life time of an application, more time is spent adding to the existing codebase rather than constantly adding new features from scratch. As you are probably aware, this can be a tedious and frustrating process. Anytime you modify code, you risk introducing new bugs, or breaking old functionality completely. Ideally, we should be able to modify an existing codebase as quickly and easily as writing brand new code. If we correctly design our application according to the Open Closed principle, we can just do that!
> ### **Open Closed Principle** ###
>
> The Open Closed principle of SOLID design states that code is open for extension but closed for modification.
>
## **In Action** ##
To demonstrate the Open Closed principle, let's continue working with our OrderProcessor from the previous chapter. Consider the following section of the process method:
- Dependency Injection
- The Problem
- Build A Contract
- Take It further
- Too Much Java?
- The IoC Container
- Basic Binding
- Reflective Resolution
- Interface As Contract
- Strong Typing & Water Fowl
- A Contract Example
- Interface & Team Development
- Service Provider
- As Bootstrapper
- As Organizer
- Booting Providers
- Providing The Core
- Application Structure
- MVC Is Killing You
- Bye, Bye Models
- It's All About The Layers
- Where To Put "Stuff"
- Applied Architecture: Decoupling Handles
- Decoupling Handlers
- Other Handlers
- Extending The Framework
- Manager & Factories
- Cache
- Session
- Authentication
- IoC Based Extension
- Request Extension
- Single Responsibility Principle
- Open Closed Principle