Question

First of all, my ubiquitous language is PHP, and I’m thinking about learning Java.

So let me split my question on two closely related parts.

Here goes the first part.

Say I have a domain-model class. It has some getters, setters, some query methods etc. And one day I want to have a possibility to compare them. So it looks like:

class MyEntity extends AbstractEntity
{
    public function getId()
    {
        // get id property
    }

    public function setId($id)
    {
        // set id property
    }

    // plenty of other methods that set or retrieve data

    public function compareTo(MyEntity $anotherEntity)
    {
        // some compare logic
    }
}

If it would have been Java, I should have implemented a Comparable interface. But why? Polymorphism? Readbility? Or something else? And if it was PHP — should I create Comparable interface for myself?

So here goes the second part.

My colleague told me that it is a rule of thumb in Java to create an interface for every behavioral aspect of the class. For example, if I wanted to present this object as a string, I should state this behaviour by something like implements Stringable, where in case of PHP Stringable would look like:

interface Stringable
{
    public function __toString();
}

Is that really a rule of thumb? What benefits are gained with this approach? And does it worth it in PHP? And in Java?

Answer 1

If it would have been Java, I should have implemented a Comparable interface. But why?

Well, you’re already providing a way of comparing “this” with another instance… if you implement Comparable, you’re telling the rest of the system that you support that ability, so that the comparison can be using for sorting, finding the “maximum” or “minimum” value etc… all in routines which know nothing about your type.

My colleague told me that it is a rule of thumb in Java to create an interface for every behavioral aspect of the class.

That sounds somewhat overboard to me. (Your example isn’t a good one as there’s already toString() on Object.) Don’t randomly create interfaces for no purpose – but create them if you want that behaviour to be used by code which doesn’t need know about your concrete type, only about what it supports. A good example of this is testability – if you write an “authenticator” class, then you can imagine either swapping different authenticators in your production code or mocking/faking the authenticator when you’re testing other components which use authentication.