クラス設計では、あるメソッドが同じクラスの別のメソッドを呼び出すのは悪い習慣ですか(たとえば、3つのメソッドが同じクラスの1つのメソッドを呼び出す)。
ありがとう
クラスを適切に設計していれば、当然のことです。小さなパブリック インターフェイスを使用する必要があります。実装が複雑な場合は、おそらく同じクラスで多くのプライベート メソッドを呼び出すことになります。
実際、これを行わないとアンチパターンになる可能性があります。常に別のクラスのメソッドを呼び出している場合、それは Feature Envy と呼ばれ、おそらくクラスを結合する必要があります。すべての実装を 1 つの巨大な関数に入れている場合、それはメンテナンスが不可能であり、おそらく多くのコードの重複が含まれています。
物事を他の再利用可能な方法に分割することは良いことです。同じメソッドを呼び出す 3 つのメソッドのケースは、完全なコードの再利用です。その 1 つの関数のコードが呼び出し元の関数のそれぞれで重複していると、非常にまずいことになります。
メソッドは単なる関数であり、関数はコードの再利用と設計の改善に役立つ抽象化です。1つのクラスの3つのメソッドが実行中に同じことを行う必要がある場合、それらのコードをコピーして貼り付けるか、別のメソッドを呼び出す必要がありますか?
コードの意味のある部分を他のメソッドによって呼び出されるメソッドに分離することは、コードの再利用のもう1つの例であり、実際にやり過ぎない限り、これは良いことです。
いいえ。実際には、これを行うことをお勧めします。それとも、呼び出しを行う 3 つのメソッドはそれぞれ、呼び出されたコードを複製する必要があると思いますか?
いいえ。DRY 原則を支持する有効な用途を見つけたようです。
全くない。実際、まったく逆です。メソッドは特定のタスクを達成するためのものであり、まさにそのために使用する必要があります。
はい。これらのメソッドがオーバーライド可能な場合、つまりクラスやメソッドが final でない場合。その理由は、動作をオーバーライドしたり、サービスの層を提供しようとするサブクラスは、その層が複数回入力される可能性があるため、確実に実行できないためです。HashSet.addAll
が独自のを呼び出すと仮定した例 (Scala 疑似コード) HashSet.add
:
class MemCountingSet[T] extends HashSet[T] {
private def sizeOf(t: T) = ...
private var memCount = 0
def add(t: T) = {
memCount += sizeOf(t)
super.add(t)
}
def addAll(coll: Collection[T]) = {
memCount += coll.foreach(sizeOf)
super.addAll(coll)
}
}
使用addAll
すると、ダブルカウントになります。