公共靜態方法 - 一個壞跡象？

Question

我剛讀這篇文章在這裏：http://hamletdarcy.blogspot.com/2008/04/10-best-idea-inspections-youre-not.html，特別是最後一點讓我想起了我的代碼，具體的建議：

在世界上什麼是公共方法，你的對象有做不依賴於對象內的任何字段？這當然是一種代碼味道。問題在於檢查的「自動修復」是應用靜態關鍵字。真是沒有。這不是你想要做的。不依賴於對象狀態的公共方法不可能是具有明確表述的對象的一部分。它只是沒有凝聚力，應該放在別的地方。所以：如果該方法是私人的，接受自動修復，但如果該方法是公開的，則不要。

有問題的代碼本質上是一個對象變換器。它需要一個類型爲A的對象並將其轉換爲不同的類型。

我的層次結構是這樣的：

接口ObjectTransformer - > GenericObjectTransformer

，然後在下面這個，GenericObjectTransformer由ObjectTransformerA和ObjectTransformerB擴展現在

，由兩個ObjectTransformerA和ObjectTransformerB需要的一些功能，但實際上並不依賴GenericObjectTransformer的任何實例變量，因此它是GenericObjectTransformer中的受保護靜態方法。

這是否違反了上述規則？顯然這是受到保護而不是公開的，但它仍然是一種與班級本身無關的班級以外的方法？

有什麼想法？

Answer 1

我不同意你拉的節選。

不依賴對象狀態的公共方法不可能是具有明確表示的一個對象的對象的一部分。它只是沒有凝聚力，應該放在別的地方。所以：如果該方法是私人的，接受自動修復，但如果該方法是公開的，則不要。

只是因爲一種方法是靜態的，與狀態無關，並不意味着它屬於「低凝聚力」範疇。內聚力/功能性不是基於狀態。

當您試圖確定凝聚力時，請考慮整個類的作用，而不僅僅是實例變量。如果您正在查看的邏輯與通用概念（GenericObjectTransformer）相關，則將其留在那裏。

如果是計算月球軌道或者海洋深度將其移至公用事業類別（本領域的另一個臭味區域）的例程。

Answer 2

它感覺有點不潔，但似乎優於我能想到的替代方案。

我認爲原來的

公共無任何依賴性 在對象上狀態的方法不可能是有一個明確規定 包租對象的一部分 。

你提到的太黑白了，你的情況更加灰暗。

通過使用受保護的方法，您可以很好地記錄其旨在供派生類使用的方法。如果你沒有把它放在基類中，那麼很有可能它必須進入一些ObjectTransformUtility類。這是贏嗎？更多的文物，更多的地方看。

一個想法：如果你的ObjectTransormer類經歷了重大變化，那麼你有多大可能需要改變這些效用方法。畢竟，如果他們的業務是再次運作物體的界面，那麼實際上他們的凝聚力非常高。