如何处理面向服务架构中的 Java 多态性 [英] How to deal with Java Polymorphism in Service Oriented Architecture

问题描述

在面向服务的架构中处理实体类型的多态和继承时，什么是最不邪恶的路径?

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

SOA 的一个原则(据我所知)是将实体类作为纯粹的数据构造，缺乏任何业务逻辑.所有业务逻辑都包含在范围狭窄、松散耦合的服务中.这意味着服务实现尽可能小，从而促进松散耦合，并且意味着实体不必了解系统可能对它们执行的每行为.

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.

由于 Java 令人困惑的决定在决定使用哪个重载方法时使用声明类型，服务实现中的任何多态行为都被替换为一系列条件检查object.getClass() 或使用 instanceof.这在 OOPL 中似乎相当落后.

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.

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

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

更新

我绝对是指重载而不是覆盖.

I definitely mean overloading and not overriding.

我定义 SOA 意味着系统的行为按用例分组到接口中，然后这些逻辑通常在每个接口的一个类中实现.因此，实体类(比如 Product)只不过是一个带有 getter 和 setter 的 POJO.它绝对不应该包含任何与服务相关的业务逻辑，因为那样你会引入一个耦合焦点，实体类需要知道可能曾经对其进行操作的所有业务流程，完全否定了松散耦合 SOA 的目的.

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.

更新 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?

推荐答案

我花了一段时间才读完这篇文章，才弄明白您真正想要什么.

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

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

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.

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

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

这篇关于如何处理面向服务架构中的 Java 多态性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！