Deméteřin zákon (Law of Demeter) je další z důležitých návrhových principů. Tento princip definuje omezení v tom, s jakými objekty bychom měli přímo komunikovat a s jakými ne. Při dodržování těchto doporučení je výsledný kód mnohem méně vzájemně provázaný a jeho udržování je mnohem jednodušší.
Kniha je pro začátečníky a mírně pokročilé v AngularJS. Předpokládá se znalost JavaScriptu a HTML. Pokročilá témata jsou probrána jen lehce nebo v ní vůbec nejsou.
Před několika lety, když jsme v naší firmě přecházeli na Git, řešili jsme, jak ho vhodně začlenit do infrastruktury, a zvolili jsme řešení založené na softwaru Gitolite. Dnes ale máme více možností a podrobněji se podíváme na Atlasian Stash.
Když jsem se před časem poprvé ponořil do světa WebGL, začínal jsem na zelené louce. Kdybych chtěl mít rychle nějaký výstup, jistě bych sáhl po hotovém řešení, poskytujícím přímo graf scény (například vynikající three.js). Já chtěl ale vědět, jak a proč ty věci fungují; každou funkci si vyzkoušet a pochopit její účel. Své poznatky budu sepisovat, kdyby se náhodou někomu hodily…
Skládání objektů
Přijde mi to jako staré dobré „kde můžeš použít skládání objektů, tam ho použij“. Mýlím se?
Re: Skládání objektů
Deméteřin zákon spíše řeší jak by mělo skládání objektů vypadat. Tedy pokud mám objekt složený s dalších objektů jak by mělo vypadat jeho rozhraní.
Re: Skládání objektů
No pokud mám
private Wallet myWallet;
Wallet getWallet() {…}
tak to nepovažuju za skládání. Skládání je podle mě právě to, když buď metody vloženého objektu zopakuju do rozhraní vnějšího objektu, nebo mám mechanismus předávání neznámých zpráv.
Re: Skládání objektů
V tom případě akorát každý pod skládáním objektů rozumíme trochu něco jiného.
Vaše definice se s Deméteřiným zákonem v podstatě shoduje.
Re: Skládání objektů
Mám za to (můžu se samozřejmě mýlit), že skládání se v učebnicích OOP uvádí jako mechanismus, pomocí kterého se dosahuje podobného efektu jako u dědičnosti, ale jinými prostředky.
Pokud bych pod skládáním myslel i to, že nějaký objekt vlastní jiný objekt (má ho v property), tak by skládáním bylo všechno a všude, protože (téměř) všechno je objekt :)
Re: Skládání objektů
No tak jak to chápu já skládání (kompozice) neimplikuje, že vnitřní objekt není z vnějšku dostupný. Ale tohle asi nemá cenu řešit. Jde jen o odlišné chápání jednoho pojmu (možná vycházíme z odlišné literatury). Na hlavní myšlence se shodujeme.
Re: Skládání objektů
- if (theWallet.getTotalMoney() > payment) {
+ if (theWallet.getTotalMoney() >= payment) {
Re: Návrhové principy: Deméteřin zákon
To je zase takové plané konzultantské žonglování s pojmy.
Je sice krásné, že Wallet z vnějšku není vidět, jenže to pak implikuje duplikovat spoustu metod z Wallet i do Customer a to i když není jisté kolik z nich se využije. Pak když se změní Wallet, tak musím měnit i ty duplikované funkce v Customer, přičemž v praxi se ukázalo, že je levnější umožnit zvnějšku přístup k Wallet, než se pořád drbat s těmi duplikovanými funkcemi.
Pokud se vyskytne problém, tak právě na to byla vynalezena funkčnost friend function a friend class, kdy si Wallet a Customer mezi sebou vyřídí něco extra, ale toto extra není pro ostatní přístupné.
Závěr je tedy chybný. Správně to má být:
Aplikace Deméteřina zákona vede k přehlednějšímu a čistšímu kódu. Udržování software je pak mnohem mnohem složitější.
Re: Návrhové principy: Deméteřin zákon
Uvedenou nevýhodu v článku také uvádím – jde o nejčastější protiargument proti Deméteřinu zákonu. Nesouhlasím s Vámi ale v několika předpokladech:
1) Customer nemusí a ani by neměl slepě duplikovat metody z Wallet, které nemají z pohledu třídy Customer význam. Účelem třídy Customer není vystavit rozhraní třídy Wallet, ale poskytovat rozhraní pro práci se zákazníky. Samozřejmě existují případy, kdy je potřeba pouze vystavit celé rozhraní vnitřní třídy a v takovém případě je třeba se nad výhodností Deméteřina zákona zamyslet.
2) Změny rozhraní třídy Wallet se do rozhraní třídy Customer musí promítnout pouze v případě, že jde o duplikaci rozhraní 1:1. To by neměl být častý případ – třída Customer může mít vlastní rozhraní, které nemusí být zrcadlovým obrazem rozhraní Wallet. V takovém případě nám dodržení Deméteřina zákona práci ušetří – změny v souvislosti s rozhraním třídy Wallet provedeme na jednom místě (v třídě Customer) a ne na všech místech, kde se Wallet z Customer používá.
Jak uvádím v závěru: Vzhledem ke zmíněným nevýhodám v některých případech může být porušení Deméteřina zákona ospravedlnitelné. Vždy bychom ale měli důsledně zvážit výhody a nevýhody z jeho porušení plynoucí.
Re: Návrhové principy: Deméteřin zákon
Ty negativni vlastnosti mi pripadaji ponekud zvelicene.
Priklad v clanku ukazuje situaci Nakupu, kdy se krasne vydelil interface Zaplat, ktery lze prirozene implementovat, jak na Penezence tak na Zakaznikovi. A treba i na dalsich vecech jako Firma, Vlada, Stat. Podivejme, jak ta Demetra najednou pracuje, kdo vsechno muze v puvodnim Nakupu najednou nakupovat.
Jenomze tohle nemusi platit. Dejme tomu, ze by neslo o Nakup, ale o KapesniKradez, kdyz se Zlodej rozhoduje, jak s Penezenkou nalozi podle jejich vlastnosti. Potom by patricne rozhrani implementovane na Zakaznikovi bylo nesmyslne.
Demetra nas totiz v takovem pripade nevede k tomu implementovat rozhrani Penezenky na Zakaznikovi, ale naopak k tomu predat si jeho Penezenku nejak normalne (konstruktor, parametr), aby zavislost na ni byla zrejma a ne utajene ziskana.
Re: Návrhové principy: Deméteřin zákon
1) Wallet vystavím ven z Customera například tehdy, že se mi nechce psát znovu těch 20 metod z Wallet. Pokud si vystačíte tak do tří pěti kusů metod, tak to pak vám věřím že se vám to líbí.
2) Když se změní třeba datový typ parametru nebo přidá nový parametr, tak to měním všude tak jako tak a s Demeterem ještě na více místech.
Netvrdím že Demeter je vysloveně špatně, ale připadá mi to jako Bronštejnova metoda z Básníků.
Re: Návrhové principy: Deméteřin zákon
ad 1) Zde bych se zamyslel zda pravdu potřebujete, aby Customer vystavil všech 20 metod z Wallet? Vystavovat všechny metody Wallet může totiž být chyba sama o sobě. Pokud je ale opravdu potřebujete všechny vystavit pak se může jednat právě o ten případ kdy je porušení Deméteřina zákona v pořádku.
ad 2) Zde bych se v první řadě zamyslel nad tím jak často měníte rozhraní oproti změnám chování. Jendo místo navíc, kde musím provést změnu při změně rozhraní, podle mě ve většině případů vyvažuje úbytek míst (na jedno), kde musím provést změnu při každé úpravě chování.
V druhé řadě mnoho změn rozhraní Wallet může bez problému pokrýt Customer tak, že jeho rozhraní zůstane beze změny (provede přetypování parametru, hodnotu dodatečného parametru je schopen sám určit, …). To je mimo jiné jedna z výhod, kterou Deméteřin zákon přináší – změny vnitřních objektů se nemusejí promítnout ven.
Samozřejmě existují případy, kdy nějaká změna v rozhraní způsobí nutnost upravit rozhraní všech odvozených tříd. Ve většině případů si ale myslím, že tato nevýhoda je více než vyvážena ostatními výhodami.
Určitě zle nalézt proti příklady, kdy tomu tak není a v takových je zcela správné Deméteřin zákon porušit. Jde spíš o to se vždy zamyslet zda k tomuto porušení mám dostatečně pádný důvod.
Re: Návrhové principy: Deméteřin zákon
ad 1) Vždyť jsem to napsal, když vám stačí 3 metody, tak je to všechno fajn. Když potřebujete 20, tak se upíšete k smrti.
ad 2) To jsem psal už na začátku, v praxi se ukázalo levnější vystavit celý objekt a ne obráceně, tedy objekt schovat a psát na to extra metody. (Někdy to samozřejmě nejde, někdy se objekt musí schovat kvůli funkčnosti)
A Deméteřin zákon je zákonem jenom v republice konzultantů :-)
Re: Návrhové principy: Deméteřin zákon
Název „Law of Demeter“ je opravdu trochu nešťastný. Nejedná se rozhodně o zákon, který by nebylo možné porušit. Lepší by bylo používat (jak ve svém komentáři doporučoval René Stein) název „Deméteřino doporučení“.
Ohledně toho co se v praxi ukázalo levnější máme odlišné zkušenosti. Z vlastní praxe mohu říci, že by mi v mnoha případech práci ušetřilo, kdybych radši ty metody navíc napsal než pak při údržbě hledal všechna použití (ano i u nás tento zákon občas porušíme). Úprava kódu tak, aby splňoval Deméteřin zákon, je ale jeden z častých refaktoringů. Na druhou stranu souhlasím, že existují případy, kdy je porušení tohoto zákona opravdu výhodnější.
Striktně lpět na jakékoliv poučce je obvykle v návrhu SW chyba. Vždy je potřeba posuzovat konkrétní případ.
Re: Návrhové principy: Deméteřin zákon
> jenže to pak implikuje duplikovat spoustu metod z Wallet i do Customer
Anebo použít pořádný OOP jazyk, který umí pohodlně předávat zprávy jinému objektu…
Re: Návrhové principy: Deméteřin zákon
Ono i když to ten jazyk podporuje, tak je stejně potřeba řešit směrování různých zpráv ke správným vnořeným objektů, takže to není až taková výhra.
Re: Návrhové principy: Deméteřin zákon
Myslím, že problém je v míchání dvou věcí. Jde o to, které objekty jsou součástí struktury zákazníka, a které jen používá. To může být různé v různých aplikacích. Peněženka součástí struktury být nutně nemusí, adresa může.
Klientský kód komunikuje se zákazníkem. Chce od něj zaplatit. Kde si obstará zákazník obnos je jeho věc – je třeba, aby zaplatil, nikoliv aby měl peněženku. Pokud si budu od zákazníka vyžadovat peněženku, kladu si omezení – zákazník se bez peněženky neobejde (může být v některé aplikaci správně, to rozhoduje zadavatel).
Chce to tyto zákony znát. Neaplikovat je však mechanicky. Zvážit je-li dané místo případ, o němž zákon mluví. Listen to your code :)
Re: Návrhové principy: Deméteřin zákon
Třída, která funkčně sdílí 20 metod s jinou třídou je špatně navržená. vyjmenujte mi nějaký nástroj z reálného světa, který má 20 funkcí. U Walletu jsou metody pouze tři. Vložit peníze, vybrat peníze, kolik je peněz v peněžence. Ale žádně zaplať, platí zákazník, ne peněženka, či účet. Logicky rozhraní Wallet nesmí obsahovat metodu Zaplať. V reálném světě, existuje vztah zákazník-peněženka, obchod-zákazník a ne vztah peněženka zákazníka-obchod. Porušení Deméřina zákona ukazuje na to, že software nesprávně modeluje poměry v reálném světě.
Radikální všelék
Chápu, že u všeho nového je potřeba udělat velký humbuk a všem opakovat, že konečně jsme vyřešili všechny neduhy a od teď vše bude úžasně snadné. Ale v případě tohoto zákona je to opravdu hodně odvážné tvrzení.
Základní metodou, kterou lidé zvládají komplexní problémy, je metoda „rozděl a panuj“. Udělám si objekty Customer a Wallet a budu si každý používat nezávisle na sobě. Protože spravovat dva různé objekty je pro mně jednodušší než jeden überobjekt. Věřím, že kód to zjednodušší a zpřehlední, ale člověk se v tom dlouhodobě nevyzná.
Nebo se článek snaží hodně nešikovnou formou říci, že pokud chci, aby zákazník zaplatil, tak se mu nemám sápat po peněžence, ale prostě po něm chtít peníze a nestarat se o to, kde je vezme? Protože na tomhle se shodneme. Pokud ale z nějakého důvodu budu chtít jeho peněženku (to asi ne, ale třebas kreditku bych rád viděl), tak si o ní řeknu a budu s ní pracovat (kupříkladu ověření PIN kreditky a transakce).
Svět není černobílý. A metody typu rozděl a panuj nebo modulární systémy jsou tu s námi již tisíce let. Využívali je už faraoni. Akorát se tomu tenkrát říkalo jinak, třebas dělba práce. V praxi to funguje dodnes, když firma A nakupuje od firmy B, tak to probíhá tím, že si nákupčí z firmy A najde kontakt na prodejce z firmy B a pošle mu objednávku. Podle Demeteřina zákona by si asi musel objednávat generální ředitel od generálního ředitele. Nebo by to byly recepční?
Re: Radikální všelék
Rozhodně se neodvažuji tvrdit, že Deméteřin zákon řeší všechny neduhy. Jak je v článku uvedeno jeho dodržování má i své nevýhody a v některých případech je jeho porušení výhodné. Návrh software je inženýrský disciplína – nikdy neexistuje „správné řešení“, ale několik „trochu špatných“ mezi kterými je nutné vybrat to nejméně špatné. Návrhové principy pouze poskytují vodítka jak se mezi nimi rozhodnout.
Deméteřin zákon Vám nijak nebrání používat objekty Customer a Wallet nezávisle. Pouze říká, že pokud je Wallet interní součástí Customer, mělo by se s ní pracovat prostřednictvím Customer, pokud není nějaký pádný důvod k ní přistupovat přímo.
„pokud chci, aby zákazník zaplatil, tak se mu nemám sápat po peněžence, ale prostě po něm chtít peníze a nestarat se o to, kde je vezme“ – ano i takhle by se to dalo parafrázovat. Prostě vykonat něco bych měl chtít po objektu se kterým pracuji ne po nějaké jeho vnitřní součásti. Vnitřní struktura objektu by měla být soukromá a z vnějšku bych o ní měl vědět co nejméně.
Důvody pro přímý přístup k vnitřním objektům samozřejmě existovat mohou. Smyslem Deméteřina zákona není zakázat z metod vracet vnitřní objekty v případech, kdy je to potřeba. Jeho smyslem je vnitřní strukturu objektu co nejvíce skrýt tak, aby se minimalizoval dopad jejích změn.
Re: Radikální všelék
Všechna tato pravidla a „zákony“ je třeba chápat jako zdroj inspirace, ne jako statement „dělejte to takhle a ne jinak, protože právě takhle a ne jinak je to správně“. V sw designu není žádná „objektivní pravda“, pro každý problém existuje více „správných“ cest jak ho řešit, přičemž výběr té konkrétní závisí na kontextu. Návrhové vzory jsou tu proto, aby začátečníkovi ukázaly cestu a pokročilého inspirovaly. Nic víc, žádné evangelium ani misie.
Pokud Vám ten misionářský tón vadí, nečtěte zjednodušené výcucy na rootu a raději si přečtěte přímo GoF Design Patterns, tam je to hezky probráno ze všech stran, pravidlo vedle protipravidla a příklad vedle protipříkladu, pěkně s náhledem.
Demeteřin zákon, spíš doporučení
Nevím, jaké zkušenosti má autor s aplikací Demeteřina zákona, ale většina lidí velmi rychle pochopí, že slovo „zákon“ je nešťastné a že se jedná spíš o doporučení a také varování před některými konstrukcemi, které zvyšují razantním způsobem závislosti napříč systémem.
Také nevím, proč autor převzal v článku zmiňované znění Demetéřina doporoučení, protože na následující verzi je lépe vidět, jak je zákon problematický.
Toto je tzv. slabá verze „zákona“
Zákon DEMETER (s jakými objekty může metoda pracovat?)
Samotná instance (this)
Argument metody
Instanční proměnná včetně zděděných proměnných a objektů v kolekcích
Objekt, který metoda vytvoří
Globální objekt
Na wikipedii je to takto:
„O itself
M’s parameters
any objects created/instantiated within M
O’s direct component objects
a global variable, accessible by O, in the scope of M“
Skoro každý bod je problematický, každého asi uhodí do oči, že „zákon“, který má snižovat počet závislostí v systému spoléhá na globální proměnné.
Slabá je tato verze zákona proto, že v tzv. silnější variantě „zákona“ nemůžete používat zděděné proměnné/metody. To odpovídá puristickému pohledu, že dědičnost je apriori zlo a stejný purismus čiší i tohoto zákona. Navíc delegace na interní objekty a vystavení „makro-rozhraní“ skutečně nejsou všespásné metody a velmi rychle se dostanete do napětí třeba s principem, který říká, že třída má mít jednoduché rozhraní, které je v souladu s její odpovědností.
Já Demeteřino doporučení beru a i na svých kurzech ukazuju jako nepříliš výstižnou verbalizaci pravidla, že není vhodné tvrdit, že objednávka je „samostatnou, zapouzdřenou, znovupoužitelnou černou skříňkou, která se nestará o své okolí blablabla další OOPlky“, i když její veřejné rozhraní vypadá krásně, když uvnitř nalezneme *několik konstrukcí tohoto typu *.
Customer.Type.Subtype.DefaultCategory.DefaultSubcategory.Koeficient.
U takové třídy nejen že neplatí, že se nestará o své okolí, taková třída má naopak razantní předpoklady, jak vypadá (pravděpodobně) úplně jiná část systému. A většinou díky tomuto neklamenému indikátoru špatného návrhu rychle (třeba i v unit/integračních testech) zjistíte, že vám v systému nějaké entity / business služby a vztahy chybí.
Mezi anemickým doménovým modelem a použitelným business modelem totiž existuje spousta mezistupňů v podobě „kripl business modelů“ – a jeden kripl model může porušovat Demeteřin zákon a další dogmaticky naplňovat delegací. Cesta do objektového pekla je široká a rámována dobrými úmysly vykladačů OOP mystérií.:)
Re: Demeteřin zákon, spíš doporučení
:))
+1
Re: Demeteřin zákon, spíš doporučení
Nemohu než souhlasit.
Jak je vidět i z dalších komentářů tak uvést, že porušení tohoto zákona mají v některých případech smysl pouze v závěru bylo nedostatečné. Deméteřin zákon stejně jako všechny ostatní návrhové principy je nutné chápat vždy pouze jako doporučení. Ostatně většina jich je do určité míry ve vzájemném rozporu. Vždy je nutné použít zdravý rozum a dojít k vhodnému kompromisu.
Poznámka: Text zákona jsem převzal z knihy Čistý kód.
Re: Demeteřin zákon, spíš doporučení
.. A omlouvám se za chybějící čárky v některých vedlejších větách a za další překlepy, musím se odnaučit psát delší příspěvky na telefonu.:)
Bičík
Na Deméteřin zákon je v poslední době populární bič používaný nesprávným způsobem. Společně s bičíky service locatorem a dědičností.
Já ho vždycky akceptoval ve zjednodušené (a možná nesprávné) interpretaci: pokud mám metodu, která chce provést platbu, tak ji nebudu předávat zákazníka-majícího-peněženku, ale rovnou peněženku.
Re: Bičík
To je jeden ze způsobů jak se porušení Deméteřina zákona vyhnout – předávat jen to co je opravdu potřeba a ne prostředníka.
Re: Bičík
No a pak přijde exekutor s požadavkem, aby v peněžence zůstával zůstatek do výše pohledávky :-)))
formatovanie
nic v zlom, ale ked uz davam do clanku javovy kod, tak si aspon dam sakra pozor na formatovanie :)
Re: formatovanie
Nic ve zlém, ale Java si žádný extraspeciální přístup nezaslouží 8-)
Re: formatovanie
Souhlasím. Minimálně:
Street = User.address.street;
by zasloužilo opravit. Nejde jen o tu Javu (i když snad každý jazyk si zaslouží, aby se dodržovaly jeho konvence), ale hlavně o čtenáře. Když člověk nemá při ruce IDE nebo kompletní zdroják, je dodržování konvencí dvojnásob důležité.
Velkým písmenem začínají názvy třídy, takže tady to vypadá, že addres je veřejná statická proměnná jakéhosi typu, který má jinou veřejnou vlastnost street. A to se snažíme pomocí operátoru = přiřadit do třídy (velké písmeno na začátku), což je nesmysl.
Takových zmatečných příkladů je lepší se zdržet a psát pořádně.
Další poznámky
Myslím si, že z velké části tato věta v článku není pravdivá.
„Mnoho návrhových vzorů představuje konkrétní realizaci Deméteřina zákona. Známé návrhové vzory jako Adapter, Proxy, Decorator používají Deméteřin zákon ve smyslu skrytí obalovaných objektů a jejich zpřístupnění přes jiné (plošší) rozhraní[...]„
Proxy (surrogate) nabízí stejné rozhraní jako reálný objekt – určitě není hlavní charakteristikou vzoru proxy, že nabízí „plošší rozhraní“. Klient si nesmí být vědom, že používá proxy a ne reálný objekt (role real subject ve vzoru).
U vzoru dekorátor mám tu samou výhradu. Dekorátor přidává chování a/nebo stav, ale originální třída ani zbytek aplikace nejsou existencí dekorátoru dotčeni – dekorátor má z hlediska aplikace stejné rozraní jako třída, kterou zapouzdřuje.
Vzor adaptér sice převádí cizorodé rozhraní, které aplikace neumí používat, na důvěrně známé aplikační rozhraní, ale nedá se říci, že by vždy rozhraní adaptéru mělo být „plošší“ – naopak někdy se stává, že rozhraní je opulentnější (místo celého csv řádku adaptér vystavuje typové vlastnosti).
Nebo sousloví „plošší rozhraní“ vyjadřuje něco jiného?
Re: Další poznámky
Bylo tím myšleno, že implementace těchto návrhových vzorů splňuje Deméteřin zákon ve smyslu, že navenek skrývají svoji vnitřní strukturu a poskytují rozhraní v podobě metod obalového objektu namísto zpřístupnění vnitřních objektů. Deméteřin zákon zde není jako hlavní motivace vniku daných návrhových vzorů, ale jejich implementace jej dodržuje – tím, že navenek není přístupná vnitřní struktura objektu (obalovaný objekt).
Plošší rozhraní tedy bylo myšleno ve smyslu „voláme pouze metody jednoho objektu“ na jedné úrovni.
Re: Další poznámky
Díky za doplnění. Přesto si to nemyslím:
“ tím, že navenek není přístupná vnitřní struktura objektu (obalovaný objekt).“
To je obyčejný popis zapouzdření.
Nebo abych to upřesnil – vaše chápání zákona Demeter je příliš široké.
Ve stejném duchu můžete pod Demeter subsumovat motivat pro zavedení vzorů:
1) Composite – s rozhraním složeného objektu se zachází stejně jako s rozhrnaím jednoduchého objektu a vnitřní struktura složeného objektu není patrná.
2) Iterator – jednotné rozhraní pro procházení složité struktury, aniž bych znal detaily.
3) Chain of responsibility – zavolám jednoduchou metodu pro zpracování požadavků a přitom nikde v řešení neprosvítá, jak je požadavek delegován na další členmy řetězu.
atd.
Jednoduše je (podle mě) zbytečné zmiňovat Demeteřino doporučení v tomto obecném kontextu, protože neexistuje žádná „specifická diference“, z níz by plynulo, že zrovna u těchto vámi vybraných vzorů se jedná o nějaký referenční případ aplikace „Demeteřina doporučení“.
Re: Další poznámky
Uvedené vzory měly sloužit pouze jako příklady, kde lze v určité podobě Deméteřin zákon (doporučení) vidět, žádná „specifická diference“ tedy neexistuje jak říkáte.
Jak jsme uvedl v perexu předchozího článku: „Návrhové vzory jsou však jen konkrétní aplikace hlubších principů, na kterých by měl být objektově orientovaný návrh založen.“. U většiny návrhových vzorů tedy vždy v nějaké podobě tyto principy najdeme.
Co se týče uvedené souvislosti Deméteřina zákona a zapouzdření tak já Deméteřin zákon opravdu více méně chápu tak, že jde doporučení, jak správně zapouzdřovat objekty. Deméteřin zákon podle mě představuje konkrétní pravidlo jak se vyhnout narušení zapouzdření tím, že bych zpřístupnil vnitřní strukturu objektu.
Doopravdy máme povoleno volat metody objektů předaných jako argument?
Porušuje následující přístup popisovaná pravidla? Připadá mi že podle uvedené definice ne, ale vzhledem k tomu že jde pouze o tupé přeuspořádání v rámci jednoho objektu, základní princip porušuje. Že by tedy ta definice byla špatně?
private boolean handleWallet(Wallet theWallet, double payment) {
if (theWallet.getTotalMoney() < payment) return false;
theWallet.subtractMoney(payment);
return true;
}
payment = 2.00;
if (handleWallet(myCustomer.getWallet(), payment)) {
//platba probehla uspesne
} else {
// platbu nelze provest
}
Re: Doopravdy máme povoleno volat metody objektů předaných jako argument?
Definici to formálně neporušuje, i když nejde zrovna o ideální způsob jak porušené Deméteřina zákona vyřešit.
V každém případě i uvedené přeuspořádání je zvýšením kvality kódu, protože uvedená metoda handleWallet může být použita vícenásobně a případná úprava chování by tedy byla soustředěna jen na jedno místo.
Umístění této metody do kontextu volajícího je ale chybou z jiného důvodu – pokud bychom stejné ošetření platby chtěli dělat v jiném objektu musíme danou metodu duplikovat a každá duplikovaný kód je chybou. Pokud je stejná metody umístěna v rámci třídy Customer jde o univerzálnější řešení.
Žádný návrhový princip nelze brát izolovaně od dalších principů a obecných zásad psaní kvalitního kódu. Při zvažování různých variant řešení je pak nutné porovnat varianty ve světle všech principů a vybrat tu nejvýhodnější.
Re: Doopravdy máme povoleno volat metody objektů předaných jako argument?
Peníze jako double? Jen to ne!
Špatné pochopení zadání
Pokud chci provést platbu žádného zákazníka nepotřebuji. Proces platby a proces podání peněženky prodávajícímu jsou dva nezávislé procesy, které plno programátorů není schopno rozlišit v modelu od fyzického světa.
Nejspíš byl přidán, aby byl vytvořen slabý argument, proč Deméteřino pravidlo je důležité.