如何編寫一個控制器而不將其作爲上帝對象？

在我的應用程序中，我有一個由主方法啓動的Controller。控制器初始化鉤子，數據庫連接，UI，另一個連接以及其他事物。它擁有程序的大部分狀態（不，它不是Singleton）。在另一個例子中，有一個處理解釋和發送命令的機器人控制器。兩者都是相當大的文件。如何編寫一個控制器而不將其作爲上帝對象？

我已經閱讀了上帝的對象，但我真的不知道一種方法來分裂它。如果我在機器人中拆分解釋器和調度器，它將會形成一個可怕的調用鏈（類似getBot().getParser().getOutput().sendMessage(recipient, message)）。同樣，在第一個控制器中，如果我分解了一些東西，那麼您只需擁有包含字段和一些別名實用程序方法的Data對象。分裂它們會讓事情變得更糟。在你認爲它不可維護之前，它實際上不是。我甚至沒有寫Bot控制器，但我仍然知道發生了什麼。

但問題是Bot類的長度是2000行（如果我拿出Javadoc註釋，可能會更短），Bot大概有1000行長。很多線條=上帝的對象。但是一個項目的一個或兩個核心類可以嗎？

來源

2010-10-25 TheLQ

相關：[設計一個類，使其不會成爲「上帝對象」]（http://stackoverflow.com/questions/2589703/designing-a-class-in-such-a-它不會成爲上帝對象） – 2010-10-25 02:14:29

@jleedev我已經看過，但這是一個不同的問題。可以做的子對象的OP可以很好地完成這項工作，因爲它全部是內部的。然而，我的情況是面向公衆的API控制器，在我無法讓其他任何對象執行工作的情況下，需要保持簡單。 – TheLQ 2010-10-25 02:18:03

「很多線條」並不意味着這個類是一個神對象，這是一個可怕的基準，用於確定您是否應該重構某些東西。有些事情非常複雜，並且需要一個複雜且內在的大對象。神對象的概念是類確實。

例如，如果我提出的對象可能

DoMyTaxes() 
GiveMeHugs() 
LogThisError() 
StartGameLoop()

目的將有資格作爲神對象，即使它可能僅僅是100行代碼。基本的想法是，以上所有內容都完全不相關（在商業邏輯的最後），所以爲什麼在世界上它們都會成爲同一個對象的一部分。如果我決定讓擁抱持續更久，我最終可能會搞砸我的稅。輸入IRS。

但是，如果你在一個物理仿真工作，讓說，和Classical()類需要有方法/對象，如：

Space() 
Time() 
Velocity() 
Speed() 
Mass() 
Acceleration() 
Gravity() 
Force() 
Impulse() 
Torque() 
Momentum() 
AngularMomentum() 
Inertia() 
MomentOfInertia() 
ReferenceFrame() 
Energy() 
KineticEnergy() 
PotentialEnergy() 
MechanicalWork() 
VirtualWork() 
DAlembertsPrinciple()

（維基百科提供）

這個對象將不成爲神的對象。這是一個複雜的對象。處理牛頓物理的一切都經歷過它，但它不是上帝的對象。它只是一個真正的大對象。上面可能會有成千上萬行代碼。

Quantum()對象會更加複雜，不用說。

要重申的是，這個想法是關於程序的行爲，不數據流：

你不在乎單個對象是否持有大量應用程序的數據，或者是否大部分流量都必須經過單個對象。對維護更有影響的是什麼時候，一個單一的上帝類（tm）擁有太多的行爲（業務代碼）。

如果你認爲有問題，你可以嘗試實行不同形式的mediation，或醜陋的圖案如dependency injection。

來源

2010-10-25 02:53:37

很好的答案。遵循這個原則，我猜我的對象是複雜的，因爲它處理解析，輸出和鉤子（儘管鉤子正在移出）。謝謝你的回答， – TheLQ 2010-10-26 14:07:44

真的很好回答，+1 – 2016-03-15 15:17:51

如果您對課程的大小和複雜程度感到不舒服，那麼這通常是一個很好的指標，可以做出更好的設計。但不要僅僅根據尺寸來衡量。如果一個類很容易理解並遵循，但包含很多代碼，這並不一定意味着它是重構因子的候選者。我看到人們對此感到厭倦，他們在追求使事物變小的過程中造成的混亂與原始代碼相比更加糟糕。另一方面，我已經幾次從頭到尾閱讀過課程，但仍然不知道他們做了什麼。

我會問的問題是 - 如果我把這個給了另一個開發者，他們是否能夠容易地理解和維護它？

如果答案是肯定的，那麼可能性是你不需要做任何事情。如果不是，那麼重新分解是有序的。

參考上帝的對象，閱讀你的文章，它聽起來像這個班做得太多了。我想知道是否可以首先將狀態重新分解爲一組模型對象作爲起點。然後你的課堂開始看起來更像是某種配置工廠。

來源

2010-10-25 02:33:25 drekka

我會建議物理/運動引擎應該與語言解釋器分開;儘管語言翻譯需要訪問物理引擎的一些公共方法和屬性，但機器人的兩個方面應該屬於同一個類別是沒有道理的。語言翻譯本身可以細分爲幾類，運動引擎也應該如此。可能有一個主控對象，但它應該有相對少量的代碼。它是主要的運動引擎和主要的語言引擎，都應該把他們的大部分工作委託給組成它們的對象。

來源

2010-10-26 01:46:13 supercat

我認爲這裏的關鍵原則是「凝聚力」。

DoMyTaxes() 
GiveMeHugs() 
LogThisError() 
StartGameLoop()

..沒有凝聚力。

喜歡的東西：

GiveMeHug() 
GiveMeKisses() 
GiveMeHugs(int noOfTimes) 
GiveMeHugs(int noOfTimes, Person person) 
GiveMeHugsAndKisses()

，因爲所有的方法都非常相似..是凝聚力。你可以在課堂上有1000個凝聚力的方法，但它仍然不是上帝的對象，因爲課堂的責任仍然有限。

來源

2013-02-15 09:57:07

如何編寫一個控制器而不將其作爲上帝對象？

回答

相關問題