2

What I would like to achieve is to use classes (now two, later more) with different interface the same way, so I would like avoid using decisions based on the interface on upper levels for instance, I don't want to see things like this:

if ($class instanceof 'ThisInterface') {
    $thisInterfaceImplementation->doStuff();
}

Instead, I would like to call the method like $class->doStuff() and put the decisions into a wrapper like class. I would like to avoid empty methods also.

I'm thinking about to use Wrapper or Adapter (and maybe Observer), but I'm curious, maybe there is a better way to do this.

To be more clear here is a small explanation what I try to solve. We are building an application that has to communicate with printing houses. This means we have to add an additional page(s) to the print sheets (or not, or maybe different way), maybe we have to rename the pdf files on ftp this or that way, or not at all.

We have a couple decisions to made based on the printers (on our interfaces), but at different steps or processes, therefore I think Strategy pattern wouldn't be a good fit (and I would have to create empty methods or use those ifs)

The Observer pattern seems to solve all my "problems", but it might be an overkill in this case. With this, I could simply dispatch events at the points I have to make a decision and only the observers subscribed to this event would do the necessary things. No empty methods, not much problem with different interfaces. On the other hand, we would dispatch every event only one place in the code, so this seems to be a "miss usage" of this pattern.

Any advice would be appreciated!

10
  • 5
    Then I'd go with wrappers which will all conform to whatever interface you need. This seems the simplest approach given what you've got there. Aug 28, 2013 at 9:23
  • 2
    I think I agree with Pinetree on this. Wrapper seems to be the simplest approach while ensuring that you can do everything you require. Use a Factory pattern if you wind up having to use a lot of different Wrapper classes for your interfaces.
    – Neil
    Aug 28, 2013 at 9:26
  • 2
    I agree, too. "Wrapper pattern" has exactly the purpose to make an incompatible interface compatible - so why do you hesitate?
    – Doc Brown
    Aug 28, 2013 at 11:17
  • 1
    Bridge pattern. But be careful that you extract commonality from each different low level interface into the higher level interfaces. Otherwise you are going to be repeating the same code for each implementation. Aug 28, 2013 at 15:17
  • 1
    I think a simple Template demands tight adherence to a common interface. But Bridge, as it sounds, is much richer. My thought is, if it lets you vary the interface independently of the abtraction it should help to express your design. Aug 29, 2013 at 11:52

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.