hi all,
I have read lots of articles/blogs on the internet that recommends not to use sealed classes. they say Sealed classes terminate your innovation . it stops OOD .. like that..
But i think we have to seal every class in the initial design phase . Open it up when needed. one advantage i like is performance. Ok, I personally prefer perfomance over all other illities except for security.
People ask why class should be closed.
But why a class should be open
With Design principles prefering compostion over inheritance , why should we keep classes open..
With programmers breaking all possible designs practices and good designs later in development , is it safe to keep classes unsealed
Ok reuse thru inheritance is one good thing. but you cant reuse all classes in the system.
Lets say im developing a system , the main places i can think of extending are the unstable/changing points of the system.I think a system should have very less number of extensible points to be stable.Open classes are the classes related to these variation points in a system.
if u open all classes,then every part of the system becomes a variation point . So every part of the system can change.Such a changing system is definitely unstable.
remember, from mechanics , less number of moving parts , more is stability or efficiency.
ofcourse sealed has its problems.
give ur comments on this.
thanks
vinothkumar
Sealed Classes - To use it or not
Batisse
If you don't want your class to be inherited then mark it sealed, people who want to use the features of your class can always use composition/aggregation which is much less restrictive than tying into an inheritance hierarchy.
Luis Esteban Valencia Muñoz
I've always disagreed with the popular point of view that classes should always be unsealed. (And I particularly disagree with those who suggest that all methods should be virtual.)
The fact is that inheritance almost never works by accident. For a class to work successfully in an inheritance scenario it usually needs the base class to have been designed specifically with inheritance in mind.
Or more likely, the first time anyone tries to derive from a class, they discover it is flawed as a base class and modify it so that it can be inherited from successfully.
So I think there's a strong case for making classes sealed by default.
I think if you're not writing for a class library, and classes likely to derive from yours are likely to be in the same project, you should mark classes as sealed by default. This provides a clear sign to anyone considering deriving from the class that you've not considered inheritance yet. They can remove the sealed marker if they want, but will be aware that they're moving into new territory.
For class libraries it's less clear cut. Since users of the class don't have the option to unseal it, I can see there's any argument that you're putting up a barrier if you mark a class as sealed. But the fact remains you've not designed the thing for inheritance, so my feeling is that attempts to derive from it are highly likely to hit problems.
My tendency is to leave classes in libraries unsealed, but I always feel that I'm simply allowing people who really want to shoot themselves in the foot to do so...