Celek je větší než součet jeho částí
-Aristoteles
Tento citát je připisován Aristotelovi. Základní myšlenka se týká synergie. V bestselleru Stephena Coveyho 7 návyků vysoce efektivních lidí je jeho šestým návykem Synergie. To, co platí u organizací, platí i v informatice. Tělo objektu je cennější než jeho jednotliviny. V informatice používáme termín kompozice.
Kompozice
Co tedy myslíme kompozicí? „Kompozice je jedním ze základních pojmů objektově orientovaného programování. Popisuje třídu, která v proměnných instance odkazuje na jeden nebo více objektů jiných tříd. To umožňuje modelovat asociaci has-a mezi objekty.“ Takto ji popisuje společnost Stackify zde. Představte si to jako orchestr. Jeden interpret je pěkný, ale když máte celou skupinu pohromadě, je hudba bohatší a hlubší.“
Přínosy
Hlavním přínosem pro kód vytvořený pomocí správné kompozice je opakované použití. Pokud jej správně navrhnete, mělo by být snadné jej znovu použít. Pokud ne, pak může být poměrně těžkopádný. Spolu s tím je intuitivní a čisté API neboli rozhraní pro programování aplikací. Jako zkušený programátor Javy jsem slyšel řadu lidí lamentovat nad návrhem API Javy pro práci s vlákny. Dobrý návrh by měl umožnit něco interně změnit a neměnit způsob, jakým s tím ostatní interagují.
Příklady
Vytvořme si příklad, abychom viděli, jak vypadá kompozice v Javě.
Máme zde definovanou třídu Role.
Třída Role se používá v této třídě Employee. V kompozici byste řekli, že třída Employee „má-a“ Role.
Skrytí
V našem příkladu API jsou třídy HotDogGrinder a HotDogGrill balíčkové soukromé a zvenčí k nim není přístup.
Tady je veřejná tvář našeho API, HotDogMachine. Tato třída má odkaz na dvě vnitřní třídy, které skrýváme pomocí našeho návrhu API.
Kompozice vs. dědičnost
Kompozice a dědičnost mohou být vývojáři zaměňovány. Jak upozorňuje Steven Lowe v tomto příspěvku na blogu společnosti ThoughtWorks, musíme pečlivě vybírat, kterou z nich použijeme.
Sdílí často slýchané pravidlo „upřednostnit kompozici před dědičností“. Jako u každého pravidla si musíme uvědomit, že neplatí vždy. Než tedy budeme pokračovat, ujasněme si několik věcí.
Definujme si dědičnost, protože o kompozici jsme již dlouze hovořili. Dědičnost je jedním ze základů objektově orientovaného programování. Máme-li například třídu jídlo, pak by třída chléb dědila od třídy jídlo. Kdežto kompozice se zabývá prvky, které jsou součástí většího celku.
Lowe připomíná, že když bychom mohli použít některou z nich, musíme si položit dvě různé otázky. Za prvé: „Reprezentace/implementace vašich doménových konceptů je jedním rozměrem“. V podstatě pokud jsou oba ve stejné doméně, je dědičnost pravděpodobně nejlepší volbou. Za druhé: „Sémantika vašich doménových konceptů a jejich vzájemné vztahy jsou druhou dimenzí.“ V tomto případě se jedná o dědičnost. Komponenty, které vytvoříte, začnou přeposílat na jinou, to by mohlo být znamením, že byste možná měli přehodnotit použití dědičnosti místo dědičnosti.“
Kompozice je velký princip při vývoji softwaru, který mnoho z nás profesionálů kazí. Sám jsem to udělal, když jsem vytvářel řešení, která k tomu nepřistupovala správně. Rychlá diskuse s kolegou na tabuli nebo načrtnutí něčeho na kus papíru vám může pomoci pochopit, kdy mezi dvěma objekty existuje vztah „má-a“. Po přečtení byste také měli pochopit výhody a vědět, jak je použít v příkladu. Zkuste si sestavit nějaký příklad a použít ho, pak byste měli vědět, zda jste na správné cestě, nebo by snad dědičnost mohla být lepší cestou.
.