3

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

johnny 5
  • 335
  • 3
  • 11

4 Answers4

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.

Zalomon
  • 1,200
  • 3
  • 8
  • 18
  • 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 '19 at 21:44
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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 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 '19 at 23:24
  • @johnny5: as you wish. See also my edit about the version number assignment, that was actually not part of the other question. – Doc Brown Mar 15 '19 at 06:49
  • Changing a class name (indeed *any* source code change) *is* a violation of the the Open/Closed principle, alt least in Robert C Martins interpretation. The flip side is to design the classes so they can be adapted to new requirements through extensions. So the principle is both about "future-proof" design *and* about forbidding certain changes. Renaming a class is clearly a violation of the "closed" part. If you want a new name for a class, you could create a subclass with that name and use that instead. Breaking backwards compatibility could be a *consequence* of violating OC. – JacquesB Mar 15 '19 at 07:34
  • 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 '19 at 09: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 '19 at 09:06
  • @DocBrown: Quoting Martin "*The source code of such a module [Modules that conform to the open-closed principle] is inviolate. No one is allowed to make source code changes to it.* I think that is pretty clear cut. Renaming an an existing class is clearly in violation of this, even if the new name is better and more future-proof. – JacquesB Mar 15 '19 at 09:20
  • @JacquesB: thanks for proving my point about the mediocre quality of Bob Martin's description. That's exactly the kind of misleading definition which seems to be the reason why many people start to mistake this design priciple for a policy how to manage changes. – Doc Brown Mar 15 '19 at 09:27
  • @DocBrown: I consider it *both* a design principle and a policy for managing change. This seem to be in accordance with how Bertrand Meyer and Robert Martin and others describe the principle. Found e.g. this quote by Meyer "*A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as parent, adding new features.*" If I am mistaken or misinterpreting them here, can you point to some citation or source which can clarify my understanding? – JacquesB Mar 15 '19 at 10:25
  • @JacquesB: I don't think I need a cite to point out an obvious contradiction: all of the SOLID principles are principles which describe properties of the software itself, how component should be designed, not of the process how to develop or manage them. Why should the OCP be completely differ from the other principles in this? This makes no sense to me. But if you really need a second opinion about this, read [Jon Skeet's critics of Bob Martin's OCP description](https://codeblog.jonskeet.uk/2013/03/15/the-open-closed-principle-in-review/). Seems he has seen the almost the same issues. – Doc Brown Mar 15 '19 at 12:07
  • 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 '19 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 '19 at 14:10
  • @JacquesB: I read Meyer's quote as "a class is closed when you *can* compile it, store it in a lib [...] and use it as it is" - which means IMHO very clearly: to make a class closed, you have to give it a good name first. – Doc Brown Mar 15 '19 at 20:54
  • .. and regarding Bob Martin: though I do this kind of stuff almost as long as him (almost 4 decades), I have still learned a lot of interesting things from him. However, I did not take all what he wrote too literally and tried to reflect those things on my own. Martin has been often critized for his "ten-commandment" style of explaining things like "Though shalt not make changes to a source code." - that's IMHO the problem here. – Doc Brown Mar 15 '19 at 20:59
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.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
-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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176