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.
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 kódu vytvořeného 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é rozhraní API neboli Application Programming Interface. 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 interagují ostatní.
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 nejsou přístupné zvenčí.
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
Kompozici a dědičnost si mohou vývojáři plést. 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ým principem 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 němu 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ěkolik příkladů a použít je, pak byste měli vědět, zda jste na správné cestě, nebo by snad dědičnost mohla být lepší cesta.
Podívejte se na další skvělý obsah a přihlaste se k odběru na MyITCareerCoach.com
.
