In object-oriented design, one of the principle aims is to produce code that is flexible, maintainable, and reusable. One of the ways to do this is to use abstractions in your code rather than concretions. The more your objects know about how one another are implemented, the more dependencies there are in your system. As the number of dependencies grows, the potential for cascading breakage grows as well. But what happens when you have a system that requires certain objects to come from the same family?

• design
• patterns
• software

In some situations, it may be preferable not to mutate a given object. Or more likely, you won’t even have the option of mutating an object because it may come from a codebase over which you have no control (such as an external library). Such cases are relatively common; however, it’s still possible to enhance an immutable object’s behavior. One effective means to do so is with the decorator pattern.

• design
• patterns
• software

In the final part of the SOLID series, we discuss dependency organization and how to avoid changes that cascade throughout a program with the Dependency Inversion Principle.

• principles
• software
• solid

One of the benefits of object-oriented design is the ability for objects to share some behaviors while simultaneously differing in others. Typically, this is achieved through inheritance--when many subclasses inherit properties from a parent class but can optionally override certain behaviors as needed. This is a very useful and common design pattern; however, there are situations when polymorphism through inheritance is inappropriate.

• design
• patterns
• software

In part 4 of the SOLID series, we continue the discussion of decoupling and how to avoid so-called 'interface pollution', wherein classes are unnecessarily forced to implement behaviors that they don’t need. It is here that our next SOLID principle appears: the Interface Segregation Principle.

• principles
• software
• solid

Decreasing coupling with the principle of least knowledge.

• design
• principles
• reference
• software

Guidelines for the effective partitioning of a software product's codebase.

• principles
• reference
• software

The relationship between 'injecting' and 'inverting' dependencies in object-oriented design.

• design
• principles
• reference
• software

In part 3 of the SOLID series, we discuss the Liskov Substitution Principle (LSP) and how you can use it to ensure that a given object and all of its subtypes can be used interchangeably.

• principles
• software
• solid

In part 2 of the SOLID series, we discuss what happens when an object needs to change. As with responsibility changes, this poses a challenge for the maintenance of downstream objects that could inadvertently be affected by the change. One way to reduce the impact of this challenge is to adhere to the second of the SOLID principles: the Open-Closed Principle (OCP).

• principles
• software
• solid