On Sat, Nov 28, 2015 at 2:07 PM, Marcos Douglas <m...@delfire.net> wrote: > Even using virtual constructors, the factory will know only one > signature to instantiate objects.
Yes and often that is enough. A constructor is then part of the API. (Lets call it API now to avoid confusion with the "interface" keyword.) > Completing things is the source of complexity, ie, completing > (abstract or virtual) methods. To complete methods in a sub class, you > need to know how super class works and this violate the (first tier > of) encapsulation. Yes, if the super class does something useful by itself, then often your class design is wrong. My example was about an abstact base class that only provides an API, the derived classes implement it. The concept is similar to an interface definition, but often the implementation is more compact and easier to read. Interface can define only methods. An abstract base class can have also variables and protected helper methods needed by the implementation code. We are partly talking about different things here. You and the articly you linked advocate the "composition over inheritance" principle. Yes, it is a good principle. I also advocate it, but I also say that using abstract base classes for APIs is often a cleaner and easier way compared to interface types. Look at the Lazarus API defined in IDEIntf package. It uses abstract base classes and works well. Abstract base classes do not work in a multiple inheritance case. Then an interface type must be used. However it is very rarely needed when the "composition over inheritance" principle is followed. Juha _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
