EE服务设计和OO建模

Question

在我们这个春天（或相当于春天）的服务无处不在的世界中，我看到的Java代码似乎越来越过程化，没有太多强调面向对象建模的重点。

例如，一个有任务要完成的服务可能会在单例服务类的服务方法中内联这些任务 - 可能是几百行。另外，也可以创建本地方法，但由于服务是无状态的，因此这些方法通常会被调用并传入一堆参数（不是指栈）。这很混乱。

我猜这可能是我原来在Smalltalk中的面向对象背景在这里发挥作用，但对我来说，面向对象建模似乎一直是正确的方式。也就是说，使用具有状态和行为的对象进行建模。

另一种方法可能是创建一个有状态的原型委托，从服务中调用该委托，并将其连接或加载所需的实体、单例DAO/服务等。此外，还可以创建其他装饰器来包装实体（特别是集合），以提供一些模型列表行为（我有一份帐户清单，我有一些基于列表的行为 - 这必须是一个持有列表的类，它不能只是在服务中内联技术List类及其使用行为（但通常是））。

但是。

创建这种对象会使用内存，在高吞吐量环境中，这可能会导致创建数千个小策略/装饰器实例。那么这有什么真实的影响呢？额外的垃圾回收是否会影响性能，或者假设JVM实例大约为2GB，Java是否可以应对？

有人基于这些原则提供了基于Java的SOA吗？有关该主题的论文吗？

感谢您阅读到这里。

- StripLight

---

我读了 Uncle Bob 的书，学到输出参数几乎等同于副作用，本质上相当丑陋。现在我不得不在无状态的 bean 中经常使用它们。我尽力将逻辑委托给本地对象实例，但归根结底，这种方法有其局限性，只能做到多少“教科书式”的程度。 - Erik Madsen

Answer 1

现实世界中的问题通常是面向对象和过程逻辑的混合体，特别是在商业世界中，交易需要同时操作多个不同的对象。当然，大部分真实代码都可以进行改进和重构，尤其是在几年后的移动目标要求中，更好地理解和使用AspectJ可以清理掉很多过程式样板代码，但如果它不符合真实世界讲师向学员描述的方式，将所有逻辑强制转化为强OOP模式就没有意义了。

您所描述的基本上是命令模式，虽然有些情况下它很有用（它本质上是Runnable的角色），但通常情况下，除非存在时间考虑因素（串行执行、并行性）或事务本身需要持久化（如银行业务），否则不值得使用。

- chrylis -cautiouslyoptimistic-

---

但我指的是商业模型行为，几乎不应该放在AOP下面 - 除非你想隐藏它。使用AOP进行反腐败代码，但不要用于核心行为。在这种情况下，委托是有状态的命令，当然是在当前线程中。在我看来，如果这简化了代码，那么这总是值得做的。除非（我的实际问题）这会不可接受地影响性能。顺便说一句，我经常对断言样板“必须”被删除感到困惑（就像它会导致脑损伤或其他什么）。BP通常很简单... - StripLight

@StripLight 这可能很简单，但它是冗余的，并且通常在许多不同的地方复制。如果可以将其抽象为建议，则可以使代码更易读且更易维护。Spring的@Transactional就是一个很好的例子；没有必要在代码中散布事务处理，因为可能会出现拼写错误或未更新而导致的错误风险增加，当您可以在一个地方编写它并在需要时应用它。 - chrylis -cautiouslyoptimistic-