1

The question is about typehinting of the role interfaces.

The code example has two DataMappers which typehint the interface they need in the constructor,

FooDataMapper type hints the Preparable interface. Because it dependens on it and no other method from the dependency.

In the other mapper, BarDataMapper i replaced the type hint with ??? as it requires both the Preparable and the Queryable interface.

How do i handle this (what should replace ???), typehinting a single of them would not suffice, should i make a new interface (maybe one that extends the previous mentioned) and hint this new interface?

The code example is a boiled down example in PHP and the type hint (???) is in the last Class declared.

<?php
// TWO ROLE INTERFACES, SMALL SEGREGATED PART OF A DBAL

Interface Preparable {
  public function prepare( .. );
}

Interface Queryable {
  public function query( ... );
}


// ADAPTER IMPLEMENTS SEGREGATION

class DbalAdapter implements Preparable, Queryable {
  private $dbal;

  public function __construct($dbal) 
  {
    private $this->dbal = $dbal;
  }

  public function prepare( .. ) 
  {
    ..
    return $this->dbal->prepare( .. );
  }

  public function query( .. ) 
  {
    ..
    return $this->dbal->query( .. );
  }
}


// DATAMAPPER CTOR HINTS FOR METHODS IT NEEDS TO USE

class FooDataMapper implements DataMapper {
  private $dbal;

  public function __construct(Preparable $dbal)
  {
    $this->dbal = $dbal;
  }

  public function create(Foo $Foo) 
  {
    ..
    $this->dbal->prepare( .. )
  }
}


// DATAMAPPER CTOR HINTS FOR METHODS IT NEEDS TO USE
// BUT THIS TIME NONE OF THE ROLE INTERFACES MATCH, BUILD A NEW INTERFACE?

class BarDataMapper implements DataMapper {
  private $dbal;
  public function __construct(??? $dbal) 
  {
    $this->dbal = $dbal;
  }

  public function SomeMethodThatNeedsBothPrepareNQuery(Bar $Bar) 
  {
    ..
    $this->dbal->query( .. )
    $this->dbal->prepare( .. )
  }
}

The initial solution i come to is making a new interface extending the ones needed.

Beware the naming of classes in the code are only for shown, might as well have been Fooable, BarAble...

2

The consumer of dependencies is the one responsible for defining them (by means of their interfaces). In your example, BarDataMapper rules. I see two possible scenarios:

  1. If BarDataMapper depends on a single object implementing both prepare() and query() methods, then yes, a proper PreparableAndQueryable interface should be defined including the two of them, and passed to the constructor. But then, perhaps you want to find another meaningful, non-composed name not hinting at bad separation of concerns.

  2. If it makes sense for BarDataMapper to consume independent Preparable and Queryable dependencies, then its constructor takes them as separate parameters, even if in the end there's really one single object implementing both interfaces. Who's really implementing interfaces should not bother the one consuming them.

  • Thanks for the answer. 2 was just the option I had not considered. – Ronni Skansing Jan 30 '14 at 0:30
1

I think you are standing on one edge case, which can either mean that you have pushed software engineering in some place where PHP can't help you much or that you have some kind of conception problem.

According to the interface segregation principle the DataMapper interface should be strict enough for you to set one interface and one only that all your DataMappers implementations should match. Those implementation shouldn't expect any more specialized object.

One possible solution for your problem of using two interfaces at the same time, you could use traits with abstract methods (if >= PHP 5.4) instead of interface. But I wouldn't do that since it's trying to mimic "interface inheritance" by using traits composing capability.

If what you want is suggestion in your IDE you are not constrained to use type hinting (which is what you are doing). You can use the PHPDoc and your IDE may recognize what you are doing (I keep recommending PhpStorm):

/**
  * @param MySuperClass $a
  * @return void 
  */
public function myFunction($a) {
    // Here your IDE will know what kind of object is $a
}

Last point: don't try to do Java with PHP. At some point if you want to ensure what is the provided object you can use quick introspection to check the right usage of the right classes, subclasses, traits and interface.

  • Thanks for the well written feedback. I think what I am trying to do is a normal case of interface segregation and inversion of control. I feel in no way i am forcing Java. – Ronni Skansing Jan 29 '14 at 22:41
  • You're welcome, the side note on Java, was really a side note. I would tend to not make it with interfaces and stuff if the only solution available is what is suggested by @rucamzu : namely an interface that needs to be rewritten to combine two. Don't-Repeat-Yourself is my first rule in programming. Moreover interface segregation doesn't mean that you have interface, it means that you do respect object's interface and don't rely on their internal behavior. – AsTeR Jan 29 '14 at 22:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.