それらの例を使用するために、スクロールしたり、さまざまな方法で(またはまったく)境界線をペイントしたりできるウィンドウクラスがある場合があります。継承を使用してこれらすべての機能をカバーする場合は、機能の実行可能な組み合わせごとに1つのサブクラスが必要になります(境界なしスクロールなし、境界なしスクロール、境界なしスクロール、境界およびスクロールなど)。クラスの数が急増しているため、機能を追加すると、これは柔軟性のないメンテナンスの悪夢です。
ここで彼らが主張している主なポイントは、この問題をよりよく解決するために、ストラテジーパターンまたはデコレーターパターンのいずれかを使用できるということです。スクロールストラテジーオブジェクトとボーダーストラテジーオブジェクトをカプセル化するWindowクラスを持つことができます。または、Windowオブジェクトを取得して、境界デコレータ内にラップし、スクロールデコレータ内にラップすることもできます。
しかし、あなたはあなたの理解において完全に正しいです。これらは、異なるアプリケーションにつながる異なる特性を持つ2つの異なるデザインパターンです。デコレータを使用すると、コンポーネントは機能を追加しているエージェントを認識しません...そのため、既存のコンポーネントクラスを中心に構築することになりがちです。ストラテジーでは、コンポーネントがさまざまなタスクを実行するためにエージェントを使用している(したがって、知っている)ため、逆になります。これらのエージェントは、通常、管理コンポーネントについて知りません。