On Thu, May 7, 2009 at 2:54 PM, Earl Miles <[email protected]> wrote:
> Earnie Boyd wrote: > >> Quoting James Gilliland <[email protected]>: >> >> >>> Drupal Law 0: If you need to do something, make an API for it first. >>> >>> >> print t('Hello World'); >> >> Oh wait I should create an API to do it first. >> >> function print_hello_world() { >> print t('Hello World'); >> } >> > > That's not an API, that's abstraction. Kind of. It doesn't follow any of > the rules, which has to do with flexibility and reusability. So it's bad > abstraction. :P > I personally like designing at the interface level. It's so much neater... then you can start thinking about the hairy details of abstract and concrete classes and their guts. Admittedly the normal Drupal model is implement an API that provides and abstration to select the properly implementation of an API's beckend interface... Now if you had.... drupal_print_string("Hello World"); function drupal_print_string($string) { $function = variable_get('drupal_print_implementation', 'default') .'_print_string'; return $function($string); } function default_print_string($string) { print $string; } These day I prefer stuff more along the lines of .... intrerface iPrinter { bool print(string str); } class defaultPrinter implements iPrinter { function print($str) { print($str); } } class printerFactory { function load($implementation) { if (in_array('iPrinter', class_implements($implementation))) { return new $implementation(); } // maybe throw an exception.... } } $pf = new printerFactory(); $printer = $pf->load(variable_get('default_printer_implementation', 'defaultPrinter')); $printer->print('Hello World'); I feel its a little more work to set up the interface and factory, but it's so much easier to expand the implementations, especially when you only need to overload one or two methods...
