> Mark classes as sealed by default
Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
If a class is unsealed you are basically not able to change it ever again, since someone might have subclassed it and depend on all kinds of internal behavior. So it should only be done very deliberately.
Is it? A more typical approach, IMO, is for internal classes to be marked as `internal`, and for `public` classes to be considered part of the public API.
The overarching principle is to keep the API as tight as possible, because as soon as an API is public, you have committed to it and even subtle changes in observable behavior may break some client.
Then you only need to design your interfaces in such a way that they can easily be implemented by composition.
This is the approach taken in ASP.Net and in WCF; although the latter does a really bad job at making their interfaces user friendly (for even tiny changes you have to re-implement a lot of functionality - which could have been avoided by better interface design).
It does not say “everything should be closed by default unless explicitly marked otherwise”...
Classes should be designed for extension on purpose, not as oversight, one of the SOLID pillars.
Taking advantage of an oversight is an open door for fragile base class problems and hard to track down bugs.
If the author has spent time optimising to that level, overriding probably isn't necessary or warranted in that area.
On the plus side, when I encounter this, I generally ask the author on GitHub if it can be 'unsealed', and they generally do so.
Designing for extensibility is not easy in the context of virtual methods. Every virtual method can be overridden, which means that you effectively need to define contracts for all your methods that can be overridden, and only call them in ways that respect those contracts. In a language where everything is virtual by default, like Java, this means all non-private methods. Which is not good, because most of the time, the reason why you're making a method public is to allow calling it, not to allow overriding. That's why C# made "virtual" explicit opt-in.
But for inheritance, there's no such issue. If someone inherits from your class, they can't break your invariants - they still have to invoke your constructor, and they don't have access to any private state. In C#, they also can't override public and protected members, unless those are declared virtual. Thus, there's no safety or correctness reason to prohibit derivation.
It should also be noted that there's no perf gain from declaring a class "sealed", unless it has virtual methods (normally, inherited from a base class, because it doesn't make any sense to have virtual methods declared in a sealed class). Thus, the only time to do so is when you have a class hierarchy, for leaf nodes in that hierarchy.
You're talking about the programming model, where I'm talking about the implementation.
In Java's case, since methods are virtual by default so with open classes a large majority of the code has a possible indirection, hence such optimizations.
Makes me wonder: Can you add extension methods to sealed classes?
http://developer-interview.com/p/oop-ood/what-are-advantages...
Without inheritance (if the class is sealed) I often end up having to re-write the entire component or simply accept my fate. So that is a lose-lose situation.
Create a new class
Create a private variable:
private Foo _foo
Click on _foo
Resharper menu -> Generate Code -> create Delegating members.
Secondly this code generation solution is just re-implementing inheritance again poorly and with the above mentioned limitation. I fail to see how code generating a proxy is any way better than (or significantly different from) inheritance.
> There is principle, which sounds like "favor object composition over class inheritance".
This is begging the question, isn't it? Why favor object composition over inheritance? The qualification here that's missing is "for code re-use". If your goal is simply to re-use code then you should favor composition. But if you're actually modeling an is-a relationship or trying to modify the behavior of a base class then that's not just for code re-use.
This subtly seems to have been lost. It's much easier to religiously ban all inheritance than to simply use it appropriately.
> In most cases "HAS-A" relationship is more semantically correct than "IS-A" relationship between classes.
In most, but not all cases. You will find that in most cases of inheritance in frameworks, for example, follow the is-a relationship perfectly. And you'll find most of time composition is used for has-a relationships. It's an error to mix this up but that's not the fault of inheritance.
For example, in my own software I inherit from the database context class to provide a host of features beyond what the framework provides. My context is a database context.
> Composition is more flexible than inheritance.
If you need that flexibility, great. But I don't see why having more flexibility is automatically good for the correctness of the program. If X is always implemented by Y, that's much easier to reason about.
> Inheritance breaks encapsulation.
I don't see how that's true. Your base class exposes what it wants to potential child classes so encapsulation is preserved. There are some languages that provide no limits (no protected/private/virtual/etc) but then those don't provide any encapsulation in any other situation either.
> A design based on object composition usually will have less classes.
Says who? What's the research behind this? I assume most projects have a mix of inheritance and composition as needed.
> It is possible to implement "multiple inheritance" in languages which do not support it by composing multiple objects into one.
That's not multiple inheritance -- it's just composing multiple objects using some kind of proxy. There is a difference.
> There is no conflict between methods/properties names, which might occur with inheritance.
Ok, that's a fair point.
The problem is, some libs are not well maintained, and not that well designed, and you (the generic "you" ) are happy to deal with breaking changes if and when they come along on version upgrades. It can be frustrating if they essentially locked it all down without much thought. But in general, I think the sealed by default is the better advice. You can do cunning ( evil ) things to get around it.
Or, reflection if you're breaking the rules anyway.