Kernprincipes van compositie
Veeg om het menu te tonen
Compositie richt zich op het bouwen van complexe objecten door eenvoudigere, onafhankelijke componenten te combineren. In plaats van te vertrouwen op overerving, wat starre hiërarchieën creëert, maakt compositie het mogelijk dat klassen samenwerken via ingesloten objecten. Deze benadering maakt systemen flexibeler, modulairder en makkelijker te onderhouden, omdat componenten vervangen of uitgebreid kunnen worden zonder de gehele structuur te breken.
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 implementeert niet zelf de logica voor betaling, voorraad of verzending.
In plaats daarvan heeft het aparte objecten (Payment, Inventory, Shipping) en gebruikt deze om het werk uit te voeren.
Elke component heeft één verantwoordelijkheid en Order coördineert deze alleen.
Als je wilt veranderen hoe betaling of verzending werkt, kun je de component vervangen zonder de Order-klasse aan te passen.
Enkele valkuilen bij het gebruik van compositie zijn het creëren van god-objecten die te veel componenten verzamelen en moeilijk te beheren worden, het lekken van component-API's via de buitenste klasse in plaats van een duidelijke interface te behouden, en het introduceren van verborgen koppeling wanneer componenten te veel afhankelijk zijn van elkaars interne details.
Een god-object probeert te veel te doen. Het bevat veel componenten en behandelt veel verantwoordelijkheden, waardoor de klasse moeilijk te begrijpen, testen en onderhouden is.
Dit gebeurt wanneer de buitenste klasse de interne methoden of attributen van zijn componenten blootstelt. In plaats van een eigen duidelijke interface te bieden, dwingt het gebruikers om direct met interne objecten te werken.
Componenten raken sterk met elkaar verbonden via interne details. Het wijzigen van één onderdeel veroorzaakt onverwacht problemen bij een ander, omdat ze afhankelijk zijn van elkaars interne structuur in plaats van duidelijke contracten.
Bedankt voor je feedback!
Vraag AI
Vraag AI
Vraag wat u wilt of probeer een van de voorgestelde vragen om onze chat te starten.