0

I was recently thinking about the following. According to the open / close principle, once a piece of code X has been implemented and tested, it should not be modified any more.

X can still be replaced by another piece of code implementing the same interface (maybe with a better implementation), or new functions and methods can be added to it. But the part that is already implemented and (thoroughly) tested should now work as a black box that can be invoked from the outside but should not be modified any more.

So, if the open / close principle is implemented correctly, shared code ownership should not be so important anymore because no one will need to modify a finished, self-contained piece of code. This seems quite natural to me but I haven't heard of this idea before. Is there any literature or school proposing this thesis: open / close principle makes shared code ownership less important?

  • The Open/Closed Principle is a nice ideal. But it's just that; an ideal. – Robert Harvey Oct 3 '14 at 18:54
  • 1
    Which is why programmers always complain when an open-source project hasn't had any commits in the last three months, so it must not be up-to-date, eh? – Robert Harvey Oct 3 '14 at 18:55
  • 2
    To be clear, the Open/Closed principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. – Robert Harvey Oct 3 '14 at 18:57
  • 1
    "software entities (classes, modules, functions, etc.)...": you mean a method is not a function? – Giorgio Oct 3 '14 at 19:01
  • 2
    Well, look. The Wikipedia article is pretty clear about the matter. You can change modules/classes/whatever to fix bugs. That's implementation. If you change what the class does, i.e. its purpose, you should create a new class, or inherit and override. That's interface. Kinda makes sense since, if you change what the class fundamentally does, it's not really the same class anymore. – Robert Harvey Oct 3 '14 at 19:04
1

I think you have taken this concept a little too literally. The open/closed principle refers to the entity within the design of the software. Of course once something is done and tested you won't want to modify it anymore. You shouldn't modify it. It should be considered closed. However, in the course of unit tests, external dependencies may vary that you have no control over. Data structures may change, a new test case may arise that was not considered during its initial production.

As @RobertHarvey mentions in comments, the implementation is always open for modification. Bugs need to be fixed and they can't be fixed through extension. However, what remains closed is the intended behavior of the class. Once the behavior is established, that is what is closed. If a test begins to fail, the entity may need to be modified to correct for the introduction of that bug (through whatever vector it came in on). However, in all cases, the intended behavior of the entity should remain static and predictable.

That being said, it ownership remains a requirement doesn't it? Even if the expectation is that you'll never have to touch that code again because it's tested and it works, you have to be prepared for the abnormal condition. It may not be as high a priority, but shared ownership will always be necessary. You're right in that it isn't "as important", but it is still necessary to have covered. Will the "owner" care most of the time? Of course not. However, if things do start blowing up and hitting the fan, then the lack of shared ownership can be catastrophic.

  • "However, what remains closed is the intended behavior of the class.": I am a bit confused, the wikipedia says exactly the opposite: "... such an entity can allow its behaviour to be modified without altering its source code." – Giorgio Oct 3 '14 at 22:00
  • @Giorgio: That's through extension. You can modify behavior through extension. However, the original entity should not be changed directly for the purpose of modifying behavior. It should only be modified to correct bugs that are introduced from outside factors. If the original intended behavior is not the desired behavior, but it still functions without error, then extension is required to illicit new behavior. – Joel Etherton Oct 4 '14 at 2:16
  • "Will the "owner" care most of the time?": Of course yes, the "owner" is by definition the person who is responsible for a piece of code. When / if that person leaves, she can hand ownership over to another person. – Giorgio Oct 4 '14 at 6:52
1

The devil is in the details. If you read through the chapter on OCP in Patterns, Practices, and Principles, Martin explains that the "closed" nature of OCP is closed to a specific type of change. Once you've discovered a need for a change you close off the artifact for changes that are similar to that one.

For instance, lets say you have to implement the order fulfillment system for an e-commerce company. At the first pass, you interface directly with your company's chosen shipping provider. As the company grows, you need to support different shipping companies. Having to change your component, you decide to protect your component from future modifications to how shipping is handled.

This is how OCP is intended to be interpreted. You can't predict every change your code will need. But whenever you do change it, close the door for that category of changes.

0

The open/closed principal really has nothing to do with code ownership.

Over the course of time, authors and contributors to a code base come and go. Authors might get promoted into management and not have time to assist with code maintenance and support. The author might get hit by a bus. Or the author is simply too busy to work on that piece of the software and somebody else will be assigned to work on it. All of these reasons are part of why shared code ownership is important. Open/closed doesn't mean other programmers won't look into classes to see what they are doing, especially if trying to debug system behavior.

As for modification, I think one needs to be careful there. Ideally you shouldn't modify the internals of tested classes. However, your external requirements can change, or may have been incomplete at the time of writing. I would rather change the internals of classes to be correct, then have incorrect behavior in classes that I correct through extensions to that class. In an ideal world, what is in the class internals is correct, you just need to provide more though extension. But reality sometimes plays out differently.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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