如何在面向服务的体系结构中处理Java多态性

小编典典

如何在面向服务的体系结构中处理Java多态性

java

在面向服务的体系结构中处理实体类型的多态性和继承时，最不邪恶的道路是什么？

SOA的原理（据我所知）是将实体类作为纯数据构造，而没有任何业务逻辑。所有业务逻辑都包含在范围狭窄，松耦合的服务中。这意味着服务实现应尽可能小，以进一步促进松散耦合，并且意味着实体避免必须了解系统可能对其执行的
每种行为。

，因此服务实现中的任何多态行为都将替换为一系列条件检查object.getClass()或using
instanceof。在OOPL中，这似乎相当落后。

使用条件句是SOA中公认的规范吗？是否应该放弃实体中的继承？

更新

我绝对是指过载而不是覆盖。

我将SOA定义为表示将系统的行为按用例分组为接口，然后通常在每个接口的一个类中实现这些逻辑。因此，这样的实体类（例如Product）只不过是带有getter和setter的POJO。它绝对不应包含与服务相关的任何业务逻辑，因为随后您引入了一个耦合点，实体类需要了解所有可能在其上运行的业务流程，从而完全否定了松耦合SOA的目的。
。

因此，由于不应在实体类中嵌入特定于业务流程的行为，因此不能将多态与这些实体类一起使用-没有要覆盖的行为。

更新2

上述行为被更简单地解释为过载路径被选择在 编译时 ，和重写在路径 运行时 。

对于要作用的域模型类的每个子类型，都有一个服务实现的子类是不好的做法，那么人们如何解决编译时超载问题？

阅读 223

2020-11-13

共1个答案

小编典典

我花了一段时间才从阅读本文中得出您真正要的东西。

我的解释是，您有一组POJO类，在将这些类传递给服务时，您希望该服务能够根据传递给它的特定POJO类执行不同的操作。

通常，我会尽量避免使用宽泛或较深的类型层次结构，并处理需要一种或两种情况的instanceof等。

无论出于什么原因，当必须有一个宽泛的类型层次结构时，我可能会使用下面的处理程序模式。

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

2020-11-13