如何处理与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.

<一个href=\"http://stackoverflow.com/questions/1572322/overloaded-method-selection-based-on-the-parameters-real-type/1572499#1572499\">Due 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意味着系统的行为是通过用例分为接口，然后为这些逻辑在每个接口一个类实现，一般。作为这样的实体类（比如产品）变成什么比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.

我的跨pretation是，你有一组在这里传递给你希望服务能够执行根据传递给它的特定的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屋！