Graeme Geldenhuys schrieb: > 2009/10/19 Paul Ishenin <i...@kmiac.ru>: >> ... >> 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. > > Bad example! :-) I have the Nokia 5800XM. You get that "final model" > in two flavours. Red and Blue (phone color and software theme color). > Then you also get revisions of that phone. Revision 1 had problems > with the speaker. Revision 1.x (or 2.x - I don't know how they > numbered them) have those hardware problems fixed. So it's the same > model phone N5800XM, but it has various differences.
Without discussing details, I think a singleton is a good example where sealed is useful. > > This is exactly my point about sealed classes. When you design the > product or class, you have NO way of know what will come in the > future. So you need to stay flexible to change! Yet another OOP > principal that "sealed" tries to prevent! This might be true, but what's the difference with private etc.? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
