コンポジションの基本原則
メニューを表示するにはスワイプしてください
コンポジションは、より複雑なオブジェクトを、より単純で独立したコンポーネントを組み合わせて構築することに重点を置く手法。継承のように固定的な階層構造を作るのではなく、コンポジションではクラスが内部に持つオブジェクトを通じて協調することができる。このアプローチにより、システムは柔軟性、モジュール性、保守性の向上が実現され、コンポーネントを全体構造を壊すことなく置き換えたり拡張したりできる。
123456789101112131415161718192021222324252627282930313233class Payment: def pay(self, amount): return f"Paid {amount}" class Inventory: def reserve(self, item): return f"{item} reserved" class Shipping: def ship(self, item): return f"{item} shipped" class Order: def __init__(self, item, price, payment, inventory, shipping): self.item = item self.price = price self.payment = payment self.inventory = inventory self.shipping = shipping def process(self): return " | ".join([ self.inventory.reserve(self.item), self.payment.pay(self.price), self.shipping.ship(self.item) ]) order = Order("Laptop", 1200, Payment(), Inventory(), Shipping()) print(order.process())
Orderは支払い、在庫管理、配送のロジック自体を実装していない。
その代わり、個別のオブジェクト(Payment、Inventory、Shipping)を所有し、それらを利用して処理を完了させている。
各コンポーネントは一つの責任のみを持ち、Orderはそれらを調整する役割のみを担う。
支払いや配送の仕組みを変更したい場合でも、Orderクラスを修正せずにコンポーネントを差し替えることができる。
コンポジションを利用する際の注意点としては、あまりに多くのコンポーネントを集約して管理が困難になるゴッドオブジェクトの生成、外部クラスを通じてコンポーネントのAPIが漏れ出しインターフェースが煩雑になること、コンポーネント同士が内部実装に過度に依存し隠れた結合が生じることなどが挙げられる。
ゴッドオブジェクトは過剰な役割を持ちすぎる。多くのコンポーネントを保持し、多くの責任を担うため、そのクラスは理解・テスト・保守が困難になる。
外側のクラスが、そのコンポーネントの内部メソッドや属性を公開してしまう場合に発生する。独自の明確なインターフェースを提供せず、ユーザーに内部オブジェクトへ直接アクセスさせてしまう。
コンポーネント同士が内部の詳細で密接に結びついてしまう。ある部分を変更すると、予期せず他の部分が壊れることがあり、明確な契約ではなく内部構造に依存している状態。
フィードバックありがとうございます!
AIに質問する
AIに質問する
何でも質問するか、提案された質問の1つを試してチャットを始めてください