Compositeにメソッドが必要ない理由はありisLeaf()
ますか?
(このパターンのポイントは(私が間違っていなければ)、リーフとコンポジットの両方を区別せずに同じものとして使用できるようにすることです。)
それとも、両方が同じものであるかのように使用できれば絶対に問題ありませんが、必要に応じてどちらがどちらであるかを調べますか?
Compositeにメソッドが必要ない理由はありisLeaf()
ますか?
(このパターンのポイントは(私が間違っていなければ)、リーフとコンポジットの両方を区別せずに同じものとして使用できるようにすることです。)
それとも、両方が同じものであるかのように使用できれば絶対に問題ありませんが、必要に応じてどちらがどちらであるかを調べますか?
Composite に関して議論されている問題の 1 つは、リーフ クラスで getChildren() を処理する方法です。インターフェイスを使用している場合は、それを共有インターフェイスに配置してから、リーフ クラスで UnsupportedOperationException をスローできます。
Visitor を使用して、異なるノード タイプに対して異なる処理を行うこともできます。そのため、フォルダー/ファイル コンポジットがコアである従来のファイル システムでは、異なるタイプ (または特定のタイプのみを処理します)。
どのように使用するかについての計画はありますか?おそらく、特定のケースは、メソッドの価値を判断するためのより良い方法でしょう。
また、このパターンの本質は、アイテムを反復処理するときに、参照している実際の型を知る必要がないということです。ただし、パターンを使用して、特定の型にキャストする試みを含めました。実質的に isLeaf で差別化するのと同じです。これは明らかにポリモーフィズムを軽視し、OCP に違反しますが、その状況では適切に機能しました。
私はデザインパターンを手錠ではなく手すりと考えています。