1

Was reading up on the Open/Closed principle of SOLID design and was curious about it's maintainability.

Lets say I have child class B and C which inherit from parent class A. B has methods unique to B, C has methods unique to C. Parent class A has two common methods that are utilized by the child classes.

In a future code release, let's say we have a new feature that introduces a common method between classes B and C. We now cannot push that method up to class A because it'd violate the "Closed for modification" portion of the principle. This seems to introduce code redundancy. Not only that, but technically wouldn't adding this new feature to classes B and C be also violate the modification tenet of the principle?

It seems with the Open/Closed approach you end up building an unnecessary, cascading hierarchy of child classes simply because one is not allowed to make alterations to the original code. Is this a correct assumption/understanding?

user3794478
  • 11
  • 1
  • 1
    It sounds a bit contrived, but you could consider making B and C derive from a common base that itself derives from A. A lot depends on whether this new method should form part of the public interface to A and also whether that interface is abstract. Refactoring of this sort is quite common before making an interface public. – Roger Rowland Jul 07 '14 at 15:21
  • SOLID perhaps needs another letter in the acronym: P for "Pick your battles" to stress the fact that designs are compromises. Read more: http://www.martinfowler.com/ieeeSoftware/protectedVariation.pdf – Fuhrmanator Aug 06 '14 at 14:11
  • tho this is quiet old, i think you should consider adding a new feature won't change the old feature, so it is fine with open close principle, you are not modifiing the old code, you are adding new one to extend the existing class – Arthur Kielbasa Dec 16 '21 at 11:44

2 Answers2

1

You don't have a crystal ball, you can't see the future and predict that a change request will happen.

However once a change request has been made, it is much more likely another change in that area will come later.

Lets take your cars example from the comment: The moment that the change request for all cars to now honk is received you should be considering if another such change will come in later. Assuming you decide it's a good chance that it will, there's only one thing for it, that's to refactor to make this whole situation Open for extension and Closed for modification. So that it's not only easy to add honking now, but you can add the next such feature with ease.

You are correct that to do apply this prematurely can bloat code and it will also receive plenty of YAGNI comments during code reviews.

weston
  • 54,145
  • 21
  • 145
  • 203
  • 1
    "Be careful when choosing the areas of code that need to be extended; applying the Open-Closed Principle EVERYWHERE is wasteful, unnecessary, and can lead to complex, hard to understand code." Freeman, Eric; Robson, Elisabeth; Bates, Bert; Sierra, Kathy (2004-10-25). Head First Design Patterns (Kindle Locations 1588-1589). O'Reilly Media. Kindle Edition. – Fuhrmanator Aug 06 '14 at 14:07
0

It seems with the Open/Closed approach you end up building an unnecessary, cascading hierarchy of child classes simply because one is not allowed to make alterations to the original code. Is this a correct assumption/understanding?

No I don't think following the open/closed principle results in cascading hierarchies of child classes.

Firstly, it's just a principle or goal. There might be times when adding a method to a base class is clearly the "right" approach even for SOLID devotees.

Secondly, a lot of methods in a base class (clearly resulting in changes) is a bit of a code smell to start with. Have you looked into the phrase "favour composition over inheritance"?

Joe Ratzer
  • 18,176
  • 3
  • 37
  • 51
  • I don't think Composition Over Inheritance applies in this case... Let’s say: Class Car Drive() Brake() Class Corvette : Car CruiseControl() Class Honda : Car DeployAirbag() New business request comes in for all cars to be able to honk horn. That applies to both cars. This isn't an object or composite, it’s just adding a shared method behavior to a hierarchy. Car needs to be edited to account for Honk() to avoid code duplication. @roger suggestion is to add an intermediate class to avoid modification which seems to create the cascading/code bloat effect I was indicating. – user3794478 Jul 07 '14 at 18:10