Как бороться с полиморфизмом Java в сервис-ориентированной архитектуре

Каков путь наименьшего зла при работе с полиморфизмом и наследованием типов сущностей в сервис-ориентированной архитектуре?

Принцип SOA (насколько я понимаю) состоит в том, чтобы классы сущностей представляли собой простые конструкции данных, лишенные какой-либо бизнес-логики. Вся бизнес-логика содержится в узких, слабосвязанных сервисах. Это означает, что реализации служб минимальны, что способствует слабой связи, и означает, что объекты избегают необходимости знать о каждом поведении, которое система может выполнять с ними.

Из-за довольно непонятного решения Java использовать объявленный тип при решении, какой перегруженный метод использовать , любое полиморфное поведение в реализациях службы вместо этого заменяется серией условных проверок object.getClass () или с помощью instanceof . Это кажется довольно отсталым в OOPL.

Является ли использование условных операторов принятой нормой в SOA? Следует ли отказаться от наследования в объектах?

UPDATE

Я определенно имею в виду перегрузку, а не переопределение.

Я определяю SOA как то, что поведение системы группируется по вариантам использования в интерфейсы, а затем логика для них, как правило, реализуется в одном классе для каждого интерфейса. Таким образом, класс сущности (скажем, Продукт ) становится не чем иным, как POJO с геттерами и сеттерами. Он абсолютно не должен содержать никакой бизнес-логики, связанной со службой, потому что тогда вы вводите одну точку сопряжения, при которой класс сущности должен знать обо всех бизнес-процессах, которые могут когда-либо работать с ним, полностью отрицая цель слабосвязанной SOA. .

Таким образом, поскольку не следует встраивать поведение, зависящее от бизнес-процесса, в класс сущностей, нельзя использовать полиморфизм с этими классами сущностей - нет поведения, которое можно было бы переопределить.

ОБНОВЛЕНИЕ 2

Вышеупомянутое поведение более просто объясняется, поскольку перегруженный путь выбирается во время компиляции , а замещающий путь в время выполнения .

Было бы плохой практикой иметь подкласс реализации вашей службы для каждого подтипа класса модели предметной области, над которым он действует, так как же люди могут решить проблему перегрузки во время компиляции?