[fpc-devel] class abstract, class sealed implementation. please review.

[Sergei Gorelkin]

Graeme Geldenhuys пишет:
> 2009/10/16 Paul Ishenin <webpirat at 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