<分区>
在我们的 spring(或等效)有线服务世界中，我看到的 Java 代码似乎越来越程序化，不太强调在 OO 中对问题建模。
例如，一个有事情要做的服务可能会在单例服务类的服务方法中很好地内联——可能超过几百行。或者，可以创建本地方法，但由于服务是无状态的，因此总是使用所需参数的堆栈(无双关语)调用这些方法。很吵。
我猜这可能是我在 Smalltalk 中的原始 OO 背景在这里脱颖而出，但在 OO 中建模问题一直对我来说是可行的方法。也就是说，使用具有状态和行为的对象进行建模。
另一种方法可能是创建一个从服务中调用的有状态原型(prototype)委托(delegate)，它可以连接或加载必要的(实体、单例 DAO/服务等)此外，还可以创建一些其他装饰器来包装实体(尤其是集合)来提供一些模型列表行为(我有一个帐户列表，我有一些基于列表的行为——这必须是一个保存列表的类，它不能只是服务中内联的技术列表类及其使用行为(但通常是))
但是。
创建一些此类对象会占用内存，在高吞吐量环境中，这可能会导致创建数以千计的小型策略/装饰器实例。 那么这对现实世界的影响是什么？额外的 GC 是否会影响性能，或者假设一个 JVM 实例大约几 GB，Java 可以应付吗？ 有没有人交付过基于这些原则的 Java SOA？有没有关于这个主题的论文？
感谢您阅读到这里。