Does the Open and Close Principle relate to renaming a class [duplicate]

Question

This question already has answers here:

Why do many software developers violate the open/closed principle? (4 answers)

Closed 1 year ago.

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.