我们的春天（或同等）有线服务世界越来越多，我看到的Java代码似乎更多＆amp;更多的程序性，不太重视OO中的问题建模。
例如，有事可做的服务可能会在单例服务类的服务方法中内联 - 可能超过几百行。或者，可以创建本地方法，但由于服务是无状态的，因此总是使用所需args的堆栈（无双关语）调用这些方法。这很吵。
猜测这可能是我在Smalltalk中的原始OO背景，但是在OO中对问题进行建模在我看来总是要走的路。也就是说，使用具有状态和行为的对象进行建模。
另一种方法可能是创建从服务调用的有状态原型委托，该委托是有线的或加载必要的（实体，单例DAO /服务等）。此外，可能会创建一些其他装饰器来包装实体（特别是集合）提供一些模型列表行为（我有一个列表af帐户，我有一些基于列表的行为 - 这必须是一个持有列表的类，它不能只是技术List类及其在服务中内联的使用行为（但通常是））
但是。
创建此类对象会使用内存，而在高吞吐量环境中，这可能会导致创建数千个小型策略/装饰器实例。 那么现实世界的影响是什么？额外的GC会不会影响性能，或者假设一个JVM实例大约几GB，Java可以应对吗？ 有没有人基于这些原则提供Java SOA？有没有关于这个问题的论文？
感谢您阅读此内容。
答案 0 :(得分：1)
现实问题通常是基于对象和程序逻辑的混合，尤其是在交易涉及需要同时操纵多个不同对象的商业世界中。当然，大多数真正的代码可以使用改进和重构，特别是在几年的移动目标要求之后，更好地理解和使用AspectJ可以清理很多程序样板，但强制所有逻辑都没有意义如果它与现实世界的教师将其描述给受训者的方式不匹配，则是一种强大的OOP模式。
你所描述的基本上是命令模式，虽然有些情况下它很有用（它基本上是Runnable的作用），但除非有基于时间的考虑因素，否则它通常不值得使用（序列执行，并行）或事务本身需要持久化（例如银行业务）。