1/9/2011 3:54:08 PM #

I agree completely regarding interfaces. Expose the interface publicly, along with a factory function, but keep the implementation private. In the class hierarchy I'm currently working on, only the interfaces are in the "interface" section of the unit, along with the signatures for their associated factory methods. The implementation is all hidden in the implementation section. This include the actual class declarations and definitions, even every type that doesn't need to be known outside the hierarchy. I find CodeExplorer from ModelMakerTools to be very valuable in this. I can create a working class, then abstract out the interface, make the class itself "private" (meaning inside the implementation section of the unit), all very quickly. In fact, by making the classes themselves descend from TInterfacedObject, I don't even have to worry about lifetime management, as long as I never use a class or class reference outside the unit. I think this is an excellent way to pursue true OO principles.

John Jacobson |

1/10/2011 1:01:42 AM #

You don't need to break the instantiation syntax, just change the implementation detail of the syntax, i.e instead of stand-alone functions, why not class functions, invoking hidden (private/protected) constructors:

  class function THTMLWriter.Create(): IHTMLWriter;

as opposed to:

  constructor THTMLWriter.Create();


For sure this "exposes" an implementation detail of the specific implementation of IHTMLWriter, but this really is no different in the case of stand-alone functions... for practical purposes, there is nothing to say that the THTMLWriter class whose class function is yielding the interface is in fact that class that implements that interface.

The only other "exposure" involved is in having to locate the class in the interface section of the unit, but that's not actually relevant to the question of whether the implementation detail is "exposed" in terms of visibility in the language itself, just a semantic difference in the formatting of the file contents - people can physically view and read the implementation section just as easily as they can the interface section.

Jolyon Smith |

1/10/2011 3:35:09 AM #

@Jolyon

class functions would be one way to go, but I prefer another approach. When possible I hide the whole class implementation (interface derived classes that is) to the implemetation section and only leave interfaces in the interface section. This way I do not event allow the user to use the class by mistake. Most of the time only a function is needed to create the main (root) class of the whole framework. From then on everything is automanaged memory wise. This simplifies things a lot and leaves no room for user errors.

This is obviously not possible when you have multiple units that reference each other. Such as in cases, when you need to derieve classes from a base class and that base class is in its own unit. You cannot hide it in implementation section in such cases.

Iztok Kacin |

1/10/2011 4:16:29 AM #

I normally don't hide the implementing class (someone might want to derive from it in the future), but I do separate the interface factory in a separate unit.

So then you end up with at least 3 units (in this example for MyTool):

- MyToolInterfaceUnit
  Declares the IMyTool interface
- MyToolClassUnit
  Implements IMyToolInterface with the TMyCool class
- MyToolFactoryUnit
  Has functions that return a IMyTool interface reference implemented by a TMyTool class instance

--jeroen

Jeroen Pluimers |

1/10/2011 9:14:51 AM #

Pingback from topsy.com

Twitter Trackbacks for
        
        Nick Hodges | Even More Changes to HTMLWriter
        [nickhodges.com]
        on Topsy.com

topsy.com |