How to deal with Java Polymorphism in Service Oriented Architecture

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?

*Java's quite baffling decision to use the declared type when deciding which overloaded method to use* This is nonsense. Java would be unusable if it were like that! — Sean Patrick Floyd, Sep 23 '11 at 10:20
It don't get how your question relates to SOA? SOA is about defining reuseable interfaces (services) with corresponding in- and outputs. It's more likely functional than object-oriented. And yes, I do not see an advantage of inheritence in interface specifications. — home, Sep 23 '11 at 10:37
@home Whilst I agree with your definition of SOA, I'd add that it also encapsulates narrow stripes of functionality within implementations of those interfaces, rather than having one class that models the structure of some data (say a Product) and all functionality that could be performed on that class. — DeejUK, Sep 27 '11 at 11:29
@Deejay: I agree as well. In reality you may have different views on a certain entity (functionality and data), which I'd not try to couple, e.g. looking at a Product from a marketing and/or manufacturing point of view. — home, Sep 27 '11 at 11:47

score 6 · Answer 1 · answered Oct 22 '11 at 04:26

You can avoid this problem by designing the business logic in different classes based on the entity type, based on single responsibility principle it would be the best way to go when you place business logic in a service layer and use a factory to create logic implementation, for example

enum ProductType
{
    Physical,
    Service
}


interface IProduct
{
    double getRate();
    ProductType getProductType();    
}

class PhysicalProduct implements IProduct
{
    private double rate;

    public double getRate()
    {
        return rate;
    }

    public double getProductType()
    {
        return ProductType.Physical;
    }
}

class ServiceProduct implements IProduct 
{
    private double rate;
    private double overTimeRate;
    private double maxHoursPerDayInNormalRate;

    public double getRate()
    {
        return rate;
    }

    public double getOverTimeRate()
    {
        return overTimeRate;
    }

    public double getMaxHoursPerDayInNormalRate;()
    {
        return maxHoursPerDayInNormalRate;
    }

    public double getProductType()
    {
        return ProductType.Service;
    }
}

interface IProductCalculator
{
    double calculate(double units);
}

class PhysicalProductCalculator implements IProductCalculator
{
    private PhysicalProduct product;

    public PhysicalProductCalculator(IProduct product)
    {
        this.product = (PhysicalProduct) product;
    }

    double calculate(double units)
    {
        //calculation logic goes here
    }
}

class ServiceProductCalculator implements IProductCalculator
{
    private ServiceProduct product;

    public ServiceProductCalculator(IProduct product)
    {
        this.product = (ServiceProduct) product;
    }

    double calculate(double units)
    {
        //calculation logic goes here
    }
}

class ProductCalculatorFactory
{
    public static IProductCalculator createCalculator(IProduct product)
    {
        switch (product.getProductType)
        {
            case Physical:
                return new PhysicalProductCalculator ();
            case Service:
                return new ServiceProductCalculator ();
        }
    }
}

//this can be used to execute the business logic
ProductCalculatorFactory.createCalculator(product).calculate(value);

score 4 · Accepted Answer · answered Oct 25 '11 at 06:57

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);
    }
}

I think this is the best alternative to conditional logic so far, much more appropriate that having a strategy factory creating new instances on each invcation, as suggested elsewhere. — DeejUK, Oct 26 '11 at 12:42
Having thought that this was a bit tedious and convoluted I've added another take on solving the problem (as a separate answer). — Tom, Oct 27 '11 at 04:35
Would I be correct in saying that this would be the adapter pattern? — Jordan Mackie, Nov 09 '19 at 21:12

Sean Patrick Floyd · Answer 3 · 2011-09-23T10:29:28.373

3

Due to Java's quite baffling decision to use the declared type when deciding which overloaded method to use

Whoever gave you that idea? Java would be a worthless language if it were like that!

Read this: Java Tutorial > Inheritance

Here's a simple test program:

public class Tester{
    static class Foo {
        void foo() {
            System.out.println("foo");
        }
    }
    static class Bar extends Foo {
        @Override
        void foo() {
            System.out.println("bar");
        }
    }
    public static void main(final String[] args) {
        final Foo foo = new Bar();
        foo.foo();
    }
}

The Output is of course "bar", not "foo"!!

edited Sep 23 '11 at 10:29

answered Sep 23 '11 at 10:22

Sean Patrick Floyd

292,901
67
465
588

1

The OP talks about *overloading*, not *overriding* (although judging from the context, I am not sure whether (s)he knows the difference :-) – Péter Török Sep 23 '11 at 10:30
@PéterTörök true, but that makes even less sense so I assumed he meant overriding – Sean Patrick Floyd Sep 23 '11 at 10:32
I absolutely mean over-loading and not over-riding. See this for an explanation: http://stackoverflow.com/questions/1572322/overloaded-method-selection-based-on-the-parameters-real-type/1572499#1572499 – DeejUK Sep 27 '11 at 11:27
1

@Deejay: Can you provide a brief example of a situation where the "polymorphic behaviour in the service implementations is instead replaced with a series of conditionals checking object.getClass() or using instanceof" ? I think many of us are struggling to understand the context of your question – millhouse Oct 19 '11 at 01:55

score 2 · Answer 4 · answered Oct 24 '11 at 10:28

I think there is a confusion of concerns here. SOA is an architectural way to solve interaction between components. Each component within a SOA solution will handle a context within a larger domain. Each context is a domain of it self. In other words, SOA is something that allows for lose coupling in between domain contexts, or applications.

Object Orientation in Java, when working in this kind of an environment, will apply to each domain. So hierarchies and rich domain objects modelled using something like domain driven design will live on a level below the services in a SOA solution. There is a tier between the service exposed to other contexts and the detailed domain model which will create rich objects for the domain to work with.

To solve each context/applications architecture with SOA will not provide a very good application. Just as solving the interaction between them using OO.

So to try to answer the bounty question more specifically: It's not a matter of engineering around the issue. It's a matter of applying the correct pattern to each level of design.

For a large enterprise ecosystem SOA is the way I would solve interaction in between systems, for example HR system and payroll. But when working with HR (or probably each context within HR) and payroll I would use the patterns from DDD.

I hope that clears the waters a bit.

score 1 · Answer 5 · answered Oct 27 '11 at 03:36

Having thought about this a bit more I've thought on an alternative approach that makes for a simpler design.

abstract class Animal {
}

class Cat extends Animal {
    public String meow() {
        return "Meow";
    }
}

class Dog extends Animal {
    public String  bark() {
        return "Bark";
    }
}

class AnimalService { 
    public String getSound(Animal animal) {
        try {
            Method method = this.getClass().getMethod("getSound", animal.getClass());
            return (String) method.invoke(this, animal);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
    public String getSound(Cat cat) {
        return cat.meow();
    }
    public String getSound(Dog dog) {
        return dog.bark();
    }
}

public static void main(String[] args) {
    AnimalService animalService = new AnimalService();
    List<Animal> animals = new ArrayList<Animal>();
    animals.add(new Cat());
    animals.add(new Dog());

    for (Animal animal : animals) {
        String sound = animalService.getSound(animal);
        System.out.println(sound);
    }
}

Thanks for going to the effort of two answers Tom! Have you tried this one out? — DeejUK, Oct 27 '11 at 07:43

How to deal with Java Polymorphism in Service Oriented Architecture

5 Answers5

Linked