Adding an interface for custom routes

[geekishmatt]

At the moment routes must be an instance of \bitExpert\Pathfinder\Route. I would like to suggest an interface for custom routes which might be defined in this way:

interface Route
{
    public function __construct($methods = [], $path = null, $target = null, $matchers = []);

    public function getPath();
    public function getTarget();
    public function getMethods();
    public function getMatchers();
    public function getName();

    public function accepting($methods);
    public function refusing($methods);
    public function ifMatches($param, $matchers);
    public function whateverMatches($param);
    public function from($path);
    public function to($target);
    public function named($name);
    public function noName();
}

[dropdevcoding]

I was thinking about this earlier when I implemented Route, but I don't know if this makes sense because Route is just a dumb configuration storage object. If we used an interface it should only care about the methods the router is using in order to leave the way the configuration is done open to the new implementation. This is the only use case which makes sense to me - Or can you provide another example in which the interface as a whole makes sense?

[geekishmatt]

\bitExpert\Pathfinder\Router and \bitExpert\Pathfinder\Route are strongly connected:

//...
public function addRoute(Route $route);
//...

An abstract class route or interface would decouple this. In my personal opinion, an abstract class contains barely as much logic... an interface would provide us the opportunity to become interoperable with other frameworks / libraries / components.

I think the interface should care about the methods and the matchers:

interface Route
{
    public function getPath(); // since we are calling it in PSR7 Router
    public function getTarget(); // since we are calling it in PSR7 Router
    public function getMethods();
    public function getMatchers();
    public function getName(); // since we are calling it in PSR7 Router

    public function accepting($methods);
    public function refusing($methods);

    public function ifMatches($param, $matchers);
    public function whateverMatches($param);
 }

[dropdevcoding]

Yes, that's exactly what makes sense to me: The interface should ensure the getters used by the router for decoupling. How those values are set is irrelevant for the router, so we shouldn't dictate a foreign implementation how to do it:

interface Route
{
    public function getPath(); // since we are calling it in PSR7 Router
    public function getTarget(); // since we are calling it in PSR7 Router
    public function getMethods();
// since we are calling it in PSR7 Router
    public function getMatchers();
// since we are calling it in PSR7 Router
    public function getName(); // since we are calling it in PSR7 Router
 }

That's enough for decoupling.

@shochdoerfer: If you agree, how shall we call our default implementation of Route then since we don't use Interface suffixes for interfaces? Any suggestions?

[shochdoerfer]

I do not see the need to decouple things right now. There is no PSR standard (or anything comparable) on he horizon, as far as I know. So there`s no need to decouple anything. Just because we can, does not mean we have to.

[dropdevcoding]

Ok, I agree, so we possibly should postpone this discussion until there's any real need for decoupling. Do you agree, too @geekishmatt?

[shochdoerfer]

And to be fair when we talk about replacing components the goal should be to be able to replace pathfinder in adroit and not to plug in any other kind of route objects into pathfinder itself. It`s all about finding the right level of abstraction ;)

Btw. interesting to see that the Zend team extracted their routing component from zend-expressive into an own independent component as well.

[dropdevcoding]

Well, you're right. That totally hits the spot of interop and that should be the goal to achieve to create a better web and more flexibility / creativity in development.

[geekishmatt]

@peterhildenbrand yeah i totally agree. Since there is no PSR standard / or comparable, it doesn't make sense to decouple.