[fpc-devel] class abstract, class sealed implementation. please review.
Paul Ishenin
ip at kmiac.ru
Mon Oct 19 06:43:13 CEST 2009
Marco van de Voort wrote:
> For delphi compatibility we only need to skip it. I agree mostly with Jonas
> here, I think this is one of those access control things added by popular
> demand (because language xxx has it).
Maybe in open source world sealed classes has small meaning since you
can always change the code. But even then they have a warning function.
But they do their security role very good when you distribute your code
in the binray form.
Except the security role sealed and abstract classes have their
important oop meaning. Look at the next "phones example":
TBasicPhone = class abstract
TCellularPhone = class(TBasicPhone)
TSatelitePhone = class(TBasicPhone)
TDialPhone = class(TBasicPhone)
...
TNokiaPhone = class(TCellularPhone)
TNokia37xxPhone = class(TNokiaPhone)
TNokia3720Phone = class sealed(TNokia37xxPhone)
TBasicPhone is ofcource an abstract class. It can have some basic fields
like color, weight, dimensions, ...
TNokia3720Phone is a final product which can't have any further
derivations. It is logically to mark this class as sealed to prevent
ocasional errors.
After all, nobody ask to use sealed/abstract classes as much as
possible. If you don't like them - just don't use them. Why to limit
other developers?
Best regards,
Paul IShenin.
More information about the fpc-devel
mailing list