EE服務設計和OO建模

Question

在我們的春季（或同等）有線服務世界中，越來越多的我看到的Java代碼似乎更具程序性，並沒有太多重點對OO中的問題進行建模。

例如，需要做的事情的服務可能很好地將內聯服務類中的服務方法 - 可能超過幾百行。或者，可能會創建本地方法，但由於服務是無狀態的，因此這些方法總是以所需參數的堆棧（無雙關語）來調用。太吵了。

猜測這可能是我在Smalltalk中的原始OO背景在這裏，但在OO中對這個問題進行建模似乎一直是我要走的路。也就是說，使用具有狀態和行爲的對象進行建模。

另一種方法可能是創建一個從服務調用的有狀態原型委託，委託可以是有線的或加載必要的（實體，單例DAO /服務等）另外還可以創建一些其他裝飾器來包裝實體esp集合）提供一些模型列表行爲（我有一個帳戶列表，我有一些基於列表的行爲 - 這必須是一個擁有列表的類，它不能只是技術列表類和它在服務中內聯的使用行爲（但通常是））

但是。

創建這種類型的對象會使用內存，並且在高吞吐量環境中，這可能會導致創建數千個小型策略/裝飾器實例。 那真正的世界影響是什麼？額外的GC是否會影響性能，或者假設Java虛擬機實例的性能達到幾GB，Java可以應對嗎？ 有沒有人根據這些原則提供了Java SOA？有關於這個問題的文件嗎？

感謝您閱讀這篇文章。

Answer 1

現實世界中的問題通常是是是基於對象和過程邏輯的組合，特別是在涉及需要同時操縱多個不同對象的業務領域。當然，大多數真實的代碼可以使用改進和重構，特別是在幾年的移動目標需求之後，更好的理解和使用AspectJ可以清理大量的程序化樣板，但是強制所有邏輯進入是沒有意義的如果它與現實世界的教練將其描述給受訓人員的方式不匹配，則會形成強大的面向對象模式。你所描述的基本上是命令模式，雖然有些情況下它很有用（它本質上是Runnable的作用），但除非有基於時間的考慮（串行執行，並行性），否則通常不值得使用）或交易本身需要持久（例如銀行業務）。