On Thu, May 27, 2010 at 1:14 PM, larry@xxxxxxxxxxxxxxxx < larry@xxxxxxxxxxxxxxxx> wrote: > On 5/27/10 12:10 PM, Adam Richardson wrote: > > Larry, >> >> I've thought about this very issue before (java developers sometimes >> lament >> this issue, too), and I error on the side of duplication if I'm using >> inheritance. >> >> However, I'd say I rarely use inheritance for anything in my development, >> and I'm much more likely to use composition. >> >> When a project evolves that's built almost entirely using design patterns >> focused on composition, I find that I very rarely have to duplicate any >> documentation, or rework documentation later on because a completely new >> component is being used. >> >> Outside of PHP (Scala, Objective C, F#, etc.), it seems like inheritance >> is >> advocated much less frequently, due to the power and simplicity of >> composition (e.g., change behavior at runtime, requires less knowledge of >> the parent classes.) >> >> Quoting the Head First book on design patterns: >> "Favor composition over inheritance" >> > > I agree entirely there. :-) However, the same question applies when using > interfaces (which are common if you're doing composition). See the language > example I had earlier. Where should the documentation of the hello() method > go? the Talk interface, the TalkInKlingon class, the TalkInSpanish class, > all three...? > > > --Larry Garfield > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > I probably would take a different approach. I'd make a Talk Object, which would serve as the primary front end for most developers using the API, and use a translator object to handle the implementation. class Talk{ private $translator; /** * Creates Talk object and sets default translator to English. */ function __construct() { $this->translator = new EnglishTranslator(); } /** * Sets translator to new object implementing ITranslator interface. */ public function setTranslator(ITranslator $translator) { $this->translator = $translator; } /** * Prints a message in the language translated by the current translator object. * * @param $message * A key indicating the message to pull from the DB * and print. * @return boolean * TRUE if it worked, FALSE otherwise. */ public function say($message) { echo $this->translator->say($message); return true; } } $talker = new Talk(); $talker->say($message = "Hello"); $talker->setTranslator(new SpanishTranslator()); $talker->say($message = "Hello"); $talker->setTranslator(new KlingonTranslator()); $talker->say($message = "Hello"); // Hopefully outputs "Hello", "Hola", and "nuqneH" Now, you still would have to document all of the classes that implement the say() method, but these would all differ in ways that make this much less redundant than the other scheme (at least I think of them semantically in this way.) The Talk object is essentially the proxy we use to many possible translators. So, the code completion would work, along with the docblock info. This scheme could be extended to utilize Inversion of Control (IoC), making changes to translators in the future (maybe there's a new dialect of Klingon that should be utilized for visitors from the urban regions of Kronos) a breeze. Just some quick thoughts (sorry if there are PHP errors, I just quick typed into my email and I've got to get back to work.) And, to stress this point, this is just how I would do this (at least after a cursory look at your example.) This isn't THE RIGHT way (and some might say it isn't even A right way.) I wish you well as you try to resolve this going forward on your project :) Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
