Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Elka 13. 07. 2017, 07:44:25
-
Řekněme že mám nějaké rozhraní "A" v němž je deklarována metoda "a". Dále mám rozhraní "B" v němž je deklarována metoda "a" s úplně stejnou signaturou jako v metodě "a" z rozhraní "A". Obě tyto metody však slouží k naprosto jinému účelu a nijak spolu nesouvisí. Teď si chci definovat třídu, která bude implementovat obě tyto rozhraní-půjde to?
-
Nebylo by jednodušší to vyzkoušet nebo vygooglit?
-
Řekněme že mám nějaké rozhraní "A" v němž je deklarována metoda "a". Dále mám rozhraní "B" v němž je deklarována metoda "a" s úplně stejnou signaturou jako v metodě "a" z rozhraní "A". Obě tyto metody však slouží k naprosto jinému účelu a nijak spolu nesouvisí. Teď si chci definovat třídu, která bude implementovat obě tyto rozhraní-půjde to?
Půjde. Ale dej si pozor ať lidé co po tobě ten kód převezmou neví kde bydlíš.
-
Půjde. Ale dej si pozor ať lidé co po tobě ten kód převezmou neví kde bydlíš.
Co je na tom špatně?
-
Jak určí, kterou z těch dvou metod s různou funkcionalitou ale stejnou signaturou má volající kód zrovna na mysli?
-
Jak určí, kterou z těch dvou metod s různou funkcionalitou ale stejnou signaturou má volající kód zrovna na mysli?
Implementace je jen jedna. Nic určovat nemusí.
-
Implementace je jen jedna. Nic určovat nemusí.
Samozřejmě, jenže tazatel specifikuje "Obě tyto metody však slouží k naprosto jinému účelu a nijak spolu nesouvisí". Jak se v té jedné metodě rozhodne, který z těch dvou účelů zrovna nastal?
-
Implementace je jen jedna. Nic určovat nemusí.
Samozřejmě, jenže tazatel specifikuje "Obě tyto metody však slouží k naprosto jinému účelu a nijak spolu nesouvisí". Jak se v té jedné metodě rozhodne, který z těch dvou účelů zrovna nastal?
To nejde. Metoda musí být stejná. Podlešák tvrdí, že to jde, ale je to špatně. Podle mě, když mohu použít stejnou metodu, není na tom nic špatně. Když nemohu, tak to nejde.
-
Jde to mraky způsoby, ale všechny jsou ukrutné prasárny vyžadující spolupráci volajícího kódu - ThreadLocal, nastavení nějaké vnější proměnné atd. atd. Kamil má pravdu, kdo to tak hloupě navrhne, že se bude muset dělat taková čuňárna, zaslouží pověsit do průvanu.
-
V Javě prostě implementujes jednu z těch metod -- V C# můžeš využít explicitní implementaci ... takže můžeš implementovat obě,ale uvedes i název rozhraní.
-
Jde to mraky způsoby, ale všechny jsou ukrutné prasárny vyžadující spolupráci volajícího kódu - ThreadLocal, nastavení nějaké vnější proměnné atd. atd. Kamil má pravdu, kdo to tak hloupě navrhne, že se bude muset dělat taková čuňárna, zaslouží pověsit do průvanu.
A to je ještě v případě, že si dá práci implementovat obě možné sémantiky. V praxi je se spíš stane, že implementátor implementuje jen jednu konkrétní variantu (třeba A). Za rok pak někdo instanci takové třídy dostane jako parametr typu B... a nestačí se divit.
Naštěstí to není tak časté, většinou když dojde ke konfliktu názvů s odlišnou sémantikou, liší se i parametry nebo návratová hodnota. Takže bych se spíš podíval kde se takové dvě rozhraní vzala, tohle docela smrdí.
-
Implementace je jen jedna. Nic určovat nemusí.
Samozřejmě, jenže tazatel specifikuje "Obě tyto metody však slouží k naprosto jinému účelu a nijak spolu nesouvisí". Jak se v té jedné metodě rozhodne, který z těch dvou účelů zrovna nastal?
O implementaci se stara trida, ktera implementuje rozhrani. Ta proste udela, co ma v dane metode naimplementovane. Takze je to na Tobe co to udela. Interface jen rekne, jake dana metoda ma jmeno, jake parametry a co vrati.
Pokud ma kazda metoda jiny navratovy typ, tak se to neprelozi.
Pokud jeden s interface tu metodu implementuje jako default function v danem interface, tak ji MUSIS stejne implementovat v te Tride. Nevyuzije se implementace z interface.
Rozhodne bych to nedelal. Pouzit jednu implementacni tridu na vice rozhani doporucuji jen v extremnich pripadech,
treba kdyz chces, aby byl objekt dane tridy serializovatelny a zaroven implementoval nejaky jiny interface
public class Ddd implements Serializable, Ccc { ....
dalsi varianta je, ze dany objekt neni immutable a potrebujes napriklad opet serializaci
public class Fff implements Cloneable, Serializable { ....
Misto implementace dvou interface v jedne tride bych vetsinou implementoval dve tridy, kazda by implementovala jeden interface a pak bych vytvoril tridu, ktera ma oba interface jako parametry konstruktoru, pokud by tam byl duvod tridy pouzivat spolecne.
btw. dobry programator se pozna, ze sna spoustu pravidel a vi kdy je ma porusit ;)
-
Takže bych se spíš podíval kde se takové dvě rozhraní vzala, tohle docela smrdí.
mohou být ze dvou nesouvisejících knihoven.
-
Naštěstí to není tak časté, většinou když dojde ke konfliktu názvů s odlišnou sémantikou, liší se i parametry nebo návratová hodnota.
A proto čím dřív přijde java s value types, tím líp. Co nejkonkrétnější a nejužší specifikace typu zabrání mnoho chybám.
-
mohou být ze dvou nesouvisejících knihoven.
Pak se musí implementovat v různých třídách a spojit to třeba kompozicí, jak popisuje Zdenek Henek.
-
(...) Rozhodne bych to nedelal. Pouzit jednu implementacni tridu na vice rozhani doporucuji jen v extremnich pripadech (...)
Ještě máme defaultní implementace metod v rozhraní, což někdo používá jako traity. To tam těch rozhraní pak může být docela dost a IMHO to není nic proti ničemu.
Obecně mi nepřijde nic špatného na tom, když nějaká třída implementuje více rozhraní. Jestli je návrh dobrý nebo se pozná podle spíš podle toho, která konkrétní rozhraní to jsou - jestli jde o smysluplnou kombinaci funkčnosti.
V případě, že dvě rozhraní mají metodu se stejnou signaturou ale jinou sémantikou, tak to smysluplné podle mě není, protože bych měl mít vždy možnost napsat pro ně i dvě odlišné implementace, což ale nemám, čím vzniká bezprostředně problém. A naopak v případě, že by ta sémantika byla stejná, tak mi to přijde sice lehce varovné, ale ještě přijatelné. Varovnost spočívá v tom, že pokud by ta rozhraní byla určena pro společné použítí a měla mít společnou metodu, byla ta metoda nejspíš ve společném předkovi těch dvou rozhraní. Pokud to tak není, může to znamenat, že v té implementaci chci kombinovat příliš funkčnosti naráz a mohla by být lepší ta kompozice, jak již bylo řečeno.
-
Pouzit jednu implementacni tridu na vice rozhani doporucuji jen v extremnich pripadech,
Běžně v jedné třídě implementuji až 5 různých rozhraní a nevidím v tom problém. ISP v SOLID.
-
Jak určí, kterou z těch dvou metod s různou funkcionalitou ale stejnou signaturou má volající kód zrovna na mysli?
Implementace je jen jedna. Nic určovat nemusí.
V Jave 8 moze byt implementacia sucastou rozhrania, tzv. default implementacia. V pripade, ze trieda implementuje 2 rozhrania, obe s metodami s rovnakou signature a obe s default implementaciami, programator musi urcit, ci si zela pouzit uplne vlastnu implementaciu a vyuzije iba siganturu alebo zvoli jednu z defaultnych implementaci - je na to novy Java 8 syntax. Kompiler to neprepusti len tak.
-
Defaultní metody jsou vzhledem ke svým omezením vhodné jen na něco jednoduššího. Nemožnost rozpadu kódu do privátních metod a uložení stavu do fieldu instance je zásadní omezení využitelnosti. S nimi by se to mixinovalo, ale třeba se taky dočkáme (privátní metody v java 9, fieldy nevím).
-
Defaultní metody jsou vzhledem ke svým omezením vhodné jen na něco jednoduššího. Nemožnost rozpadu kódu do privátních metod a uložení stavu do fieldu instance je zásadní omezení využitelnosti. S nimi by se to mixinovalo, ale třeba se taky dočkáme (privátní metody v java 9, fieldy nevím).
Osobne si myslim, ze primarne ide o to, aby ste mohli opatchovat viac metodove rozhrania tak, aby sa z nich stali SAMy a bolo mozne robit lambdy aj z povodne neSAMoidneho trebars historickeho rozhrania.