On Tue, Jul 22, 2014 at 2:06 AM, Richard Quadling <rquadling@xxxxxxxxx>
wrote:
> If I have a method that requires a piece of fruit. And I have a base fruit
> object that has all the properties and methods I need to operate upon it at
> the general level, why can't I extend that into a apples and oranges and
> extend the controller (appleController, orangeController) both of which are
> based upon fruitController (that layer wants fruit - be it apples, oranges
> or pears or anything that extends fruit).
Some code would really help, but I'll take a stab at what I think you're
doing.
class FruitJuicer {
public function juice(Fruit $fruit) { ... }
}
class AppleJuicer {
public function juice(Apple $apple) { ... chop apple before calling
superclass ... }
}
I think you're saying that you want to be able to have the typehint for
AppleJuicer::juice to be Apple (as above) instead of Fruit. This already
violates the Liskov Substitution principle because you couldn't swap in an
AppleJuicer anywhere a FruitJuicer is required because it may receive an
Orange or Cactus. You could create a JuicingStrategy interface and register
instances with the FruitJuicer. But I'm having a hard time applying the
above structure to a versioned API, so I suspect I'm not getting the
metaphor right.
When a request comes into a V2 endpoint, will all code handling that
request be from V2 and common? If so, it may be possible to have the front
controller set up the autoloader with those two source trees and use
replacement instead of subclassing to override common components. That may
not be ideal, but if each version requires only minor changes it may be
manageable. This would allow all versions of a single class to use the same
name which will make the type-hinting happy.
If you can post a small example, that will make discussion easier.
Peace,
David
