On Sat, Nov 28, 2015 at 9:11 AM, Juha Manninen <juha.mannine...@gmail.com> wrote: > On Sat, Nov 28, 2015 at 1:48 AM, Marcos Douglas <m...@delfire.net> wrote: >> Another tip: Factories resolve some problems but there is a cost. The >> factory will creates your instance (object) but it know only one >> constructor, ie, the base class constructor. > > No, the constructor must then be virtual.
Even using virtual constructors, the factory will know only one signature to instantiate objects. AFAIK you only will know constructor or methods arguments, in runtime, using RTTI, if you put the constructor/method as published. But, even if you put it as published, you do not know the right context to call the right constructor -- considering you have many constructors with different arguments, of course. > Inheritance is OK if all public virtual methods can be defined in an > abstract base class. If works as an interface then (without > "interface" keyword). Inheritance breaks encapsulation. This was written even in GoF Patterns. There are many post, on the web, explaining why inheritance is evil. I searched on Google right now: http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/ http://www.javaworld.com/article/2073649/core-java/why-extends-is-evil.html > It does not work when you need TDog.Bark but it would work with > abstract function TAnimal.Says: String, which is implemented as " > Return 'wuff' " for TDoc and " Return 'miou' " for TCat. 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. Best regards, Marcos Douglas PS: Perhaps this video could be interesting http://www.infoq.com/presentations/Simple-Made-Easy _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
