Question

What is the path of least evil when dealing with polymorphism and inheritance of entity types in a service-oriented architecture?

A principle of SOA (as I understand it) is to have entity classes as mere data constructs, lacking in any business logic. All business logic is contained in narrow-scoped, loosely-coupled services. This means service implementations are as small as possible furthering the loose coupling, and means the entities avoid having to know about every behaviour the system may perform on them.

Due to Java’s quite baffling decision to use the declared type when deciding which overloaded method to use, any polymorphic behaviour in the service implementations is instead replaced with a series of conditionals checking object.getClass() or using instanceof. This seems rather backward in an OOPL.

Is the use of conditionals the accepted norm in SOA? Should inheritance in entities be abandoned?

UPDATE

I definitely mean overloading and not overriding.

I define SOA to mean that behaviour of the system is grouped by use case into interfaces, and then the logic for these is implemented in one class per interface, generally. As such an entity class (say Product) becomes nothing more than a POJO with getters and setters. It absolutely should not contain any business logic related to a service, because then you introduce one focal point of coupling whereby the entity class needs to know about all business processes that may ever operate on it, completely negating the purpose of a loosely-coupled SOA.

So, being that one should not embed business process-specific behaviour in an entity class, one cannot use polymorphism with these entity classes – there is no behaviour to override.

UPDATE 2

The above behaviour is more simply explained as an overloaded path is chosen at compile-time, and an overridden path at run-time.

It’d be bad practice to have a subclass of your service implementation for each subtype of the domain model class it’s acting on, so how do people get around the overloading-at-compile-time issue?

Answer 1

It took me a while from reading this to work out what you were really asking for.

My interpretation is that you have a set of POJO classes where when passed to a service you want the service to be able to perform different operations depending on the the particular POJO class passed to it.

Usually I’d try and avoid a wide or deep type hierarchy and deal with instanceof etc. where the one or two cases are needed.

When for whatever reason there has to be a wide type hierarchy I’d probably use a handler pattern kind of like below.

class Animal {

}
class Cat extends Animal {

}

interface AnimalHandler {
    void handleAnimal(Animal animal);
}

class CatHandler implements AnimalHandler {

    @Override
    public void handleAnimal(Animal animal) {
        Cat cat = (Cat)animal;
        // do something with a cat
    }

}

class AnimalServiceImpl implements AnimalHandler {
    Map<Class,AnimalHandler> animalHandlers = new HashMap<Class, AnimalHandler>();

    AnimalServiceImpl() { 
        animalHandlers.put(Cat.class, new CatHandler());
    }
    public void handleAnimal(Animal animal) {
        animalHandlers.get(animal.getClass()).handleAnimal(animal);
    }
}