Graeme Geldenhuys пишет:
2009/10/16 Paul Ishenin <webpi...@mail.ru>:
Sealed class is a class which can't be derived by another class. This one is
fully supported by delphi.
Would you mind explaining this - I never saw the benefit of a sealed
class. Using myself as an example. Say I develop some kick-ass OOP
framework. There is no way in hell I can forsee every possible use of
the classes I created. So why would I want to limit the usefulness of
a class - it goes totally against the OOP principles.
Sealing does not prevent reusing in form of aggregation (when the sealed
class is a member of your own class). Wishing/forcing users to use
aggregation instead of inheritance may be a valid point sometimes.
Imagine the TList class was a sealed classes. We would never have been
able to create a TObjectList, TInterfaceList, TStringList, etc... and
reusing the basic implementation from TList to save time and code
reuse.
These cases use precisely aggregation, so, in fact, the code of
TObjectList, etc. wouldn't change if TList was sealed.
Not to shoot down your efforts or anything, I just don't understand
the point of a sealed class. It sounds more like something Microsoft
would implement to stop developers from reusing their classes like
"Outlook Bar" and extend it to something much better than the standard
one included in MS Office.
Guess its primary target are classes like Java/.NET String. These are
value classes, they do not contain other pointers, garbage collection is
therefore easier and the whole framework speeds up. If you inherit from
it and add your own member, this mechanism could be disrupted system-wide.
But as soon as a feature appears, it starts to be used (and abused, too)
here and there. Next come 'class helpers', the purpose of which is to
circumvent sealed classes, and so on...
Regards,
Sergei
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
