3

This question already has an answer here:

My coworker and I have having an argument. The Open and closed principle is defined as:

A module will be said to be open if it is still available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs. A module will be said to be closed if [it] is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding)

My coworker states that renaming a class (Private/Or Public) without increasing the MAJOR version violates the Open and Closed Principle.

My view is

  1. You should only increase the major version if it fully breaks functionality.
  2. Refactoring and class renaming do not fall under the open and close principle in general.

Does Renaming a class fall under the open and closed principle

marked as duplicate by Doc Brown design Mar 15 at 6:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

7

This is a common misconception - changes like a renaming of a public class violate backwards compatibility, but not the OCP. But if such a renaming becomes necessary, the OCP was already broken before, when the initial name was chosen.

The OCP is a principle about designing classes in a way they don't require changes, not a principle about forbidding to apply changes. Quite the opposite: renaming a class to give it a name which expresses its responsibility clearer, so further renaming will not be necessary any more, can be an act of following the OCP.

Note further that it is perfectly sensible to assign new major version numbers to a library when backwards compatibility is broken - so your coworker is probably right when he/she suggests to increase the number, not because of an OCP violation, but for a different rationale.

See this former answer of mine from 2017 to get a more detailed explanation about the OCP.

  • Hey thanks, I wasn't aware this was already asked, I've accepted your answer, but could you help me close this question as duplicate, I'd rather the traffic be redirected there because the full answers are there – johnny 5 Mar 14 at 23:24
  • 3
    @JacquesB: repeating a false statement again and again does not make it more true. The need for changing a class name is a symptom of an OCP violation which was done during the former design. However, the change of a class name itself, with the intention to prevent the need for further changes may be indeed an act of following the OCP. – Doc Brown Mar 15 at 9:00
  • 1
    ... and Bob Martin's description's of the OCP are well-known to be mediocre, they are probably the cause for several misunderstanding about the principle. – Doc Brown Mar 15 at 9:06
  • 1
    @DocBrown: Isn't that more an inconsistency in the SOLID umbrella term? As far as I know, the open/closed principle existed long before the SOLID term was invented. I personally find SOLID a rather random selection, but that's neither here nor there. – JacquesB Mar 15 at 12:57
  • 1
    This is answer is on point. That’s exactly like extracting a class and injecting it to follow the OCP. It doesn’t violate the OCP, the class design violated it before that change. – Steve Chamaillard Mar 15 at 14:10
9

I'd say that if it is a public class there's no question that it is a major change, since it will break functionality. But I don't think that it has anything to do with open/closed principle, since it's not modifying the behavior of the module.

  • The open/closed principle is about any modification which could cause clients to behave differently. And clearly a name change will affect clients since they will stop working. – JacquesB Mar 14 at 21:44
2

It does violate the open/closed principle because it forces clients to change rather adapt through extension. Renaming is essentially deleting one thing and creating a new thing. Rather than rename just deprecate the old class and create a new one with the new name. Then new clients can use the new class.

Then it's only a major breaking change when you choose to end support for the old class.

Of course none of this would be an issue if your clients had depended on a stable abstraction rather than this particular class. But that's not an OCP issue. That's a DIP issue.

Now if your code isn't published in any way at this point you're free to simply do a rename refactoring that nothing else ever needs to know about.

-1

Renaming a class violates the Open/Closed principle because it is a modification. It is a pretty significant modification since all code using the renamed class will stop working.

The Open/Closed does not say anything about version numbers. Renaming is a violation of the principle regardless of any versioning numbers involved. But a pragmatic approach to versioning could be to follow the open/closed principle for minor releases, but accept violations of the principle for major releases.

Not the answer you're looking for? Browse other questions tagged or ask your own question.