3

ここでこの記事を読んだばかりです: http://hamletdarcy.blogspot.com/2008/04/10-best-idea-inspections-youre-not.html、特に最後の部分で、自分のコードについて考えさせられました。特にアドバイス：

オブジェクト内のどのフィールドにも依存しないパブリック メソッドがオブジェクトに対して行っていることは、一体何なのでしょうか? これは確かにコードの匂いです。問題は、検査の「自動修正」が static キーワードを適用することです。いやー。それはあなたがしたいことではありません。オブジェクトの状態に依存しないパブリック メソッドは、明確に宣言された憲章を持つオブジェクトの一部になることはできません。まとまりがなく、別の場所に配置する必要があります。したがって、メソッドがプライベートの場合は自動修正を受け入れますが、メソッドがパブリックの場合は受け入れません。

問題のコードは、基本的にオブジェクト トランスフォーマーです。型 A のオブジェクトを受け取り、それを別の型に変換します。

私の階層は次のようなものです：

インターフェース ObjectTransformer -> GenericObjectTransformer

この下では、GenericObjectTransformer が ObjectTransformerA と ObjectTransformerB によって拡張されます。

現在、ObjectTransformerA と ObjectTransformerB の両方でいくつかの機能が必要ですが、実際には GenericObjectTransformer のインスタンス変数に依存していないため、GenericObjectTransformer の保護された静的メソッドです。

これは上記のルールに違反していますか? 明らかに、これはパブリックではなく保護されていますが、それでもクラス自体とは何の関係もないクラスの外部からアクセス可能なメソッドですか?

何かご意見は？

4

2 に答える 2

5

あなたが引っ張った抜粋には同意しません。

オブジェクトの状態に依存しないパブリック メソッドは、明確に宣言された憲章を持つオブジェクトの一部になることはできません。まとまりがなく、別の場所に配置する必要があります。したがって、メソッドがプライベートの場合は自動修正を受け入れますが、メソッドがパブリックの場合は受け入れません。

メソッドが静的で状態とは関係がないからといって、それが「凝集度の低い」カテゴリに分類されるわけではありません。結束/機能性は状態に基づいていません。

凝集性を判断しようとするときは、インスタンス変数だけでなく、クラス全体の役割について考えてください。見ているロジックが一般的な概念 (GenericObjectTransformer) に関連している場合は、そのままにしておきます。

月の軌道や海の深さを計算するルーチンである場合は、それをユーティリティ クラス (私たちの分野のもう 1 つの臭い領域) に移動します。

于 2010-07-30T13:17:34.977 に答える
0

少し汚れているように感じますが、私が考えることができる代替手段よりも好ましいようです.

オリジナルだと思う

オブジェクトの状態に依存しないパブリック メソッドは、明確に宣言された憲章を持つオブジェクトの一部になることはできません。

あなたの参照は白黒すぎて、あなたの状況はさらに灰色です。

保護されたメソッドを持つことで、派生クラスでの使用を意図していることをうまく文書化できます。基本クラスに入れない場合は、おそらく ObjectTransformUtility クラスに入れる必要があります。それが勝ち？より多くのアーティファクト、より多くの場所。

1 つの考え: ObjectTransormer クラスが大幅に変更された場合、これらのユーティリティ メソッドを変更する必要がある可能性はどれくらいか。結局のところ、彼らのビジネスがオブジェクトのインターフェースに対して機能することである場合、実際には彼らの結束力は非常に高い.

于 2010-07-30T13:20:27.707 に答える