Why shouldn't classes be designed to be "open"?

Question

When reading various Stack Overflow questions and others' code the general consensus of how to design classes is closed. This means that by default in Java and C# everything is private, fields are final, some methods are final, and sometimes classes are even final.

The idea behind this is to hide implementation details, which is a very good reason. However with the existence of protected in most OOP languages and polymorphism, this doesn't work.

Every time I wish to add or change functionality to a class I'm usually hindered by private and final placed everywhere. Here implementation details matter: you're taking the implementation and extending it, knowing full well what the consequences are. However because I can't get access to private and final fields and methods, I have three options:

• Don't extend the class, just work around the problem leading to code that's more complex
• Copy and paste the whole class, killing code reusability
• Fork the project

Those aren't good options. Why isn't protected used in projects written in languages that support it? Why do some projects explicitly prohibit inheriting from their classes?

Answer 1

Designing classes to work properly when extended, especially when the programmer doing the extending doesn't fully understand how the class is supposed to work, takes considerable extra effort. You can't just take everything that's private and make it public (or protected) and call that "open." If you allow someone else to change the value of a variable, you have to consider how all the possible values will affect the class. (What if they set the variable to null? An empty array? A negative number?) The same applies when allowing other people to call a method. It takes careful thought.

So it's not so much that classes shouldn't be open, but that sometimes it's not worth the effort to make them open.

Of course, it's also possible that the library authors were just being lazy. Depends on which library you're talking about. :-)

Answer 2

Making everything private by default sounds harsh, but look at it from the other side: When everything is private by default, making something public (or protected, which is almost the same thing) is supposed to be a conscious choice; it is the class author's contract with you, the consumer, about how to use the class. This is a convenience for both of you: The author is free to modify the inner workings of the class, as long as the interface remains unchanged; and you know exactly which parts of the class you can rely on and which ones are subject to change.

The underlying idea is 'loose coupling' (also referred to as 'narrow interfaces'); its value lies in keeping complexity down. By reducing the number of ways in which components can interact, the amount of cross-dependency between them is also reduced; and cross-dependency is one of the worst kinds of complexity when it comes to maintenance and change management.

In well-designed libraries, classes that are worth extending through inheritance have protected and public members in just the right places, and hide everything else.

Answer 3

Everything that is not private is more-or-less supposed to exist with unchanged behaviour in every future version of the class. In fact, it can be considered part of the API, documented or not. Therefore, exposing too many details is probably causing compatibility problems later.

Regarding "final" resp. "sealed" classes, one typical case are immutable classes. Many parts of the framework depend on strings being immutable. If the String class wasn't final, it would be easy (even tempting) to create a mutable String subclass that cause all kinds of bugs in many other classes when used instead of the immutable String class.

Answer 4

In OO there are two ways to add functionality to existing code.

The first one is by inheritance: you take a class and derive from it. However, inheritance should be used with care. You should use public inheritance mainly when you have a isA relationship between the base and the derived class (e.g. a Rectangle is a Shape). Instead, you should avoid public inheritance for reusing an existing implementation. Basically, public inheritance is used for making sure the derived class has the same interface as the base class (or a larger one), so that you can apply the Liskov's substitution principle.

The other method to add functionality is to use delegation or composition. You write your own class that uses the existing class as an internal object, and delegates part of the implementation work to it.

I am not sure what was the idea behind all those finals in the library you are trying to use. Probably the programmers wanted to make sure you were not going to inherit a new class from their ones, because that's not the best way to extend their code.

Answer 5

Most of the answers have it right: Classes should be sealed (final, NotOverridable, etc) when the object is not designed or intended to be extended.

However, I would not consider simply closing everything proper code design. The "O" in SOLID is for "Open-Closed Principle", stating that a class should be "closed" to modification, but "open" to extension. The idea is, you have code in an object. It works just fine. Adding functionality should not require opening that code up and making surgical changes which may break previously working behavior. Instead, one should be able to use inheritance or dependency injection to "extend" the class to do additional things.

For instance, a class "ConsoleWriter" may get text and output it to the console. It does this well. However, in a certain case you ALSO need the same output written to a file. Opening up the code of ConsoleWriter, changing its external interface to add a parameter "WriteToFile" to the main functions, and placing the additional file-writing code next to the console-writing code would be generally considered a bad thing.

Instead, you could do one of two things: you could derive from ConsoleWriter to form ConsoleAndFileWriter, and extend the Write() method to first call the base implementation, and then also write to a file. Or, you could extract an interface IWriter from ConsoleWriter, and reimplement that interface to create two new classes; a FileWriter, and a "MultiWriter" which can be given other IWriters and will "broadcast" any call made to its methods to all the given writers. Which one you choose depends on what you're going to need; simple derivation is, well, simpler, but if you have a dim foresight of eventually needing to send the message to a network client, three files, two named pipes and the console, go ahead and take the trouble to extract the interface and create the "Y-adapter"; it'll save you time on the back end.

Now, if the Write() function had never been declared virtual (or it was sealed), now you're in trouble if you don't control the source code. Sometimes even if you do. This is generally a bad position to be in, and it frustrates users of closed-source or limited-source APIs to no end when it happens. But, there are legitimate reason why Write(), or the entire class ConsoleWriter, are sealed; there may be sensitive information in a protected field (overridden in turn from a base class to provide said information). There may be insufficient validation; when you write an api, you have to assume the programmers who consume your code are no smarter or benevolent than the average "end user" of the final system; that way you're never disappointed. You either take the time to validate the hell out of anything your consumer can do to extend your API, or you lock the API down like Fort Knox, so they can only do exactly what you expect.

Answer 6

I'd think it's probably from all the people using an oo language for c programming. I'm looking at you, java. If your hammer is shaped like an object, but you want a procedural system, and/or don't really understand classes, then your project will need to be locked down.

Basically, if your going to write in an oo language, your project needs to follow the oo paradigm, which includes extension. Of course, if someone wrote a library in a different paradigm, maybe your not supposed to extend it anyway.

Answer 7

I do what I get paid for. Making a class open is extra work. I’m not doing it unless you pay me for it. Or convince my boss to pay me for it.

If you decide to want the class to be open, and we work at the same place, you take the source code and change it. Now it is your responsibility. You better make sure it’s something your boss wants you to spend time on. And it’s not open until you actually used it that way. Created subclasses that you couldn’t create while it was closed. If you open it and don’t use it, then you just wasted time and money and probably reduced the quality of the existing code.

Answer 8

EDIT: I believe classes should be designed to be open. With some restrictions, but shouldn't be closed for inheritance.

Why: "Final classes" or "sealed classes" seems to me weird. I never have to mark one of my own classes as "final" ("sealed"), because I may have to inheret that classes, later.

I have buy / download third party libraries with classes, (most visual controls), and really grateful none of those libraries used "final", even if supported by the programming language, in which they where coded, because I ended extending those classes, even if I have compiled libraries without the source code.

Sometimes, I have to deal with some ocassional "sealed" classes, and ended making a new class "wrapper" containg the given class, that has similar members.

class MyBaseWrapper {
  protected FinalClass _FinalObject;

  public virtual DoSomething()
  {
    // these method cannot be overriden,
    // its from a "final" class
    // the wrapper method can  be open and virtual:
    FinalObject.DoSomething();
  }
} // class MyBaseWrapper


class MyBaseWrapper: MyBaseWrapper {

  public override DoSomething()
  {
    // the wrapper method allows "overriding",
    // a method from a "final" class:
    DoSomethingNewBefore();
    FinalObject.DoSomething();
    DoSomethingNewAfter();
  }
} // class MyBaseWrapper

Scope clasifiers allow to "seal" some features without restricting inheritance.

When I switched from Structured Progr. to O.O.P., I started using private class members, but, after many projects, I ended using protected, and, eventually, promote those properties or methods to public, if necessarily.

P.S. I don't like "final" as keyword in C#, I rather use "sealed" like Java, or "sterile", following the inheritance metaphor. Besides, "final" is an ambiguos word used in several contexts.

Answer 9

Because they don't know any better.

The original authors are probably clinging to a misunderstanding of SOLID principles which originated in a confused and complicated C++ world.

I hope you will notice that the ruby, python, and perl worlds don't have the problems that the answers here claim to be the reason for sealing. Note that its orthogonal to dynamic typing. Access modifiers are easy to work in most (all?) languages. C++ fields can be mucked with by casting to some other type (C++ is more weak). Java and C# can use reflection. Access modifiers make things just difficult enough to prevent you from doing it unless you REALLY want to.

Sealing classes and marking any members private explicitly violates the principle that simple things should be simple and hard things should be possible. Suddenly things that should be simple, aren't.

I'd encourage you to try to understand the viewpoint of the original authors. Much of it is from an academic idea of encapsulation that has never demonstrated absolute success in the real world. I've never seen a framework or library where some developer somewhere didn't wish it worked slightly differently and didn't have good reason to change it. There are two possibilities that may have plagued the original software developers which sealed and made members private.

1. Arrogance - they really did believe they were open for extension and closed for modification
2. Complacence - they knew there might be other use cases but decided not to write for those use cases

I think in the corporate framework wold, #2 is probably the case. Those C++, Java and .NET frameworks have to be "done" and they have to follow certain guidelines. Those guidelines usually mean sealed types unless the type was explicitly designed as part of a type hierarchy and private members for many things which might be useful for others use.. but since they don't directly relate to that class, they aren't exposed. Extracting a new type would be too expensive to support, document, etc...

The entire idea behind access modifiers is that programmers should be protected from themselves. "C programming is bad because it lets you shoot yourself in the foot." It is not a philosophy that I agree with as a programmer.

I much prefer python's name mangling approach. You can easily (much easier than reflection) replace privates if you need. A great writeup on it is available here: http://bytebaker.com/2009/03/31/python-properties-vs-java-access-modifiers/

Ruby's private modifier is actually more like protected in C# and doesn't have a private as C# modifier. Protected is a little different. There is great explaination here: http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/

Remember, your static language doesn't have to conform to the antiquated styles of the code writte in that language past.

Answer 10

It's fairly easy to design a class in such a manner that some other programmer Bobby will be able to modify it to add features in such a way that Bobby's code will be able to work with the original and modified versions interchangeably, exploiting the additional features hwen they exist.

Such a class design would also likely have the useful trait that some other programmer Jo would be able to do likewise.

Allowing Bobby and Jo to extend the functionality of the existing class, however, rather than forking a copy and extending that, would imply that code which works with the original should work will all extended versions interchangeably, and thus Bobby's client code should be expected to work with Jo's enhanced version of the class, and Jo's client code should work with Bobby's. While it's possible to design a class in such a way that such interoperability could be expected, such a design would make things somewhat more difficult not just for the class designer, but also probably for Bobby and Jo, even if such interoperability was never used.

I would also suggest as a design principle that classes should generally be designed to either be instantiated or extended, but not both, and that programs should generally avoid using references of instantiable types except as private members within those types themselves or other non-inheritable types within the source code module defining them. Languages could facilitate this distinction by allowing inheritable types to designate instantiable types which should be constructed when client code needs an object of some general-purpose type that's compatible with the inheritable one. For example, an List<T> interface could designate that code which wants an instance of something that implements List<T> should construct an ArrayList<T>. Most code that uses a List<T>--even the code that needs to create an instance of a "general-purpose" implementation--shouldn't need to care about whether it's given a reference to an ArrayList<T> or something else.