[development] Proposed Apocrypha

Darrel O'Pry darrel.opry at gmail.com
Thu May 7 19:48:56 UTC 2009

On Thu, May 7, 2009 at 2:54 PM, Earl Miles <merlin at logrus.com> wrote:

> Earnie Boyd wrote:
>> Quoting James Gilliland <neclimdul at gmail.com>:
>>> 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

Now if you had....

drupal_print_string("Hello World");

function drupal_print_string($string) {
    $function = variable_get('drupal_print_implementation', 'default')
    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) {

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',
$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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090507/fed69f68/attachment.htm>

More information about the development mailing list