Jste zastánci OOP programování?

Dekel

Re: Jste zastánci OOP programování?
« Odpověď #75 kdy: 05. 12. 2010, 15:43:01 »
Bobr: To já programuju zásadně objektově:
program.goto(radka)
:-D

Dekel: Jazyk porušuje principy OOP? Já měl za to, že jedinej , kdo je může porušit je programátor. Jazyk k tomu akorát může či nemusí dávat vhodné vyjadřovací prostředky.
Jinak také se obávám, že OOP tady nepochopil nikdo jiný - a ve slušné diskusi je zvykem
svá tvrzení podkládat argumenty a ne vytvářet flametvorné výkřiky do tmy :-)

tu máš argumenty: http://latrine.dgx.cz/ruby-on-rails-dekuji-nechci

ja som pochopil OOP na OOP zarábam peniaze. jazyk + knižnice a frameworky by mali (do určitej miery) programátora viesť k tomu aby neporušoval princípy OOP.


Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #76 kdy: 05. 12. 2010, 17:19:06 »
Ruby moc rád nemám. Nicméně to co ukazuješ je čistě jedna povolná možnost, která se v určitých případech hodí. Pokud ji nechceš v projektu používat, nemusíš. Můžeš dokonce snadno statickou analýzou kódu vyloučit, že se daná možnost nebude používat.
 Nicméně jsou naopak případy, kdy se daná vlastnost velmi hodí. Např. pro opravu cizí knihovny, když do ní nechci zasahovat (např. proto, že případný upgrade této knihovny mi opravu zas rozbije).
Oheň není špatný, špatný je člověk, který s ním zapálí barák.

Stejnětak prototypová dědičnost. OOP se nerovná třídy a objekty. OOP jsou paradigmata, jak správně navrhnout architekturu programu. Samozřejmě, když se pomocí prototypů budeš snažit emulovat pouze třídní dědičnost, tak Ti zbydou jen nevýhody. Když se jí naučíš používat, tak zjistíš, že má daleko silnější výrazové prostředky než klasická třídní dědičnost a při zachování elementárních pravidel nebude o nic chybovější.

Že cizí knihovny mohou mít v JS sideefekty? To mohou mít i cizí knihovny v C#. Např. funkce na setřídění Ti může jednou za čas z pole něco vyhodit. Že se to nedělá a že je to prasečina? Ale to je i modifikování globálních objektů v JS. Buďto srovnávejme správně napsané knihovny, nebo špatně. Srovnávat dobře napsané knihovny v C# a špatně v JS je trochu nefér, ne?

Samozřejmě - můžeš furt jíst syrový maso a máš jistotu, že se nepopálíš. Někomu však to pečený za tu možnost stojí...

Teď mě ještě napadá:přístup JAVY: socialismus. Zakážeme vše potenciálně nebezpečné, co kdyby něco. Přístup javascriptu. Dovolíme skoro vše, je na Tobě jestli to ke své škodě zneužiješ či ne. Nevím jak ty, ale já bych si socialismus nevybral... (a to mám Javu rád).

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #77 kdy: 05. 12. 2010, 22:33:40 »
Změna rozhraní je totéž jako změna předka - prostě v okamžiku, kdy todle člověk musí udělat, tak byla provedena špatně analýza.

Nemáte pravdu. Moje objekty běžně umí vícero rozhraní, nebo je umí různě proxovat. Pokud potřebuju přidat něco do rozhraní a přitom nechci to rozhraní přepisovat všude, napíšu to jako nové rozhraní a každá třída, u které to má smysl to rozhraní implementuje. A tam, kde potřebuju nové rozhraní použít nejprve ze starého rozhraní nechám získat nové. V C++ je na to operator dynamic_cast

Při vývojit tedy většinou rozhraní nemění, jen je přidávám. Takhle je navržen třeba celý DirectX. Například dnešní DirectX10 umí naprostou většinu starších rozhraní ze všech starých verzí.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #78 kdy: 06. 12. 2010, 02:04:32 »
Jsou dvě možnosti. Buďto nové rozhraní umí něco navíc. Pak nejde o změnu rozhraní, ale o vytvoření nového rozhraní, popisující nějaký speciálnější případ, rozšiřující funkčnost starého. To je v pořádku - tady nejde o změnu rozhraní, ale např. o vytvoření potomka rozhraní.

Druhá možnost je, že opravdu potřebuji změnit staré rozhraní. Tzn že jen potřebuji popsat naprosto stejnou věc, ale pomocí jiných sad metod.

Pak samozřejmě když místo změny udělám rozhraní verze2, tak si částečně ušetřím práci. Ale za cenu toho, že mám v programu o jedno rozhraní navíc (program je tedy nepřehlednější) a některé třídy budou implementovat zbytečně duplicitní metody (což je další možný zdroj chyb - člověk upraví jednu a druhou nikoli).

Dynamic_cast ze starého na nové je pak víceméně rezignace na největší výhodu staticky typovanch jazyků: typovou kontrolu. Protože nikdy nemohu zajsitit, že opravdu všechny objekty co do té fce přijdou, budou to nové rozhraní opravdu umět.

Další věc je, že objekt s novým rozhraním zpravidla pomocí starého rozhraní ani popsat nepůjde (pokud by šel, tak proč by bylo potřeba vytvářet nové rozhraní):

Např. rozhraní myslivec s metodou getPes() - no a pak potřebuju vytvořit myslivce se dvěma psy. Jasně getPes() může vrátit prvního psa. Jenže pokud bude někdo pomocí této metody testovat, čí pes to zakousl jeho králíka, tak se nic nedoví.

Samozřejmě, od projektů určité velikosti a hlavně stáří není vyhnutí a trochu "bastlit" se musí. Člověk by ale měl vědět, že zrovna bastlí a nepovyšovat to na standardní techniku.

Když to zjednoduším - proč musím měnit rozhraní? No protože nevyhovuje. A je udělané dobře, když nevyhovuje? No evidentně není, jinak by přeci vyhovovalo. Co jiného od rozhraní mohu chtít....
« Poslední změna: 06. 12. 2010, 02:47:14 od Logik »

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #79 kdy: 06. 12. 2010, 07:47:04 »
Dynamic_cast ze starého na nové je pak víceméně rezignace na největší výhodu staticky typovanch jazyků: typovou kontrolu. Protože nikdy nemohu zajsitit, že opravdu všechny objekty co do té fce přijdou, budou to nové rozhraní opravdu umět.

Další věc je, že objekt s novým rozhraním zpravidla pomocí starého rozhraní ani popsat nepůjde (pokud by šel, tak proč by bylo potřeba vytvářet nové rozhraní):

Např. rozhraní myslivec s metodou getPes() - no a pak potřebuju vytvořit myslivce se dvěma psy. Jasně getPes() může vrátit prvního psa. Jenže pokud bude někdo pomocí této metody testovat, čí pes to zakousl jeho králíka, tak se nic nedoví.

No dynamic_cast je náplastí na bolístku u OOP jazyka, jehož objekty neumí zpracovat jakoukoliv zprávu. Když si třeba vezmete Smalltalk... tam to jde normálně. Díky dynamic_castu se mohu objektu zeptat, zda podporuje nějakou sadu zpráv... jinými slovy, podporuje určitý protokol, stejně jako když v klasické smalltalkovské představě se mohu zeptat objektu, zda umí zpracovat určitou zprávu.

Pokud tohle přijmete, můžete pracovat s objekty jako s černými krabičkami, které podporují různá rozhraní a stačí jen změnit úhel pohledu (rozhraní) a získat tak nové vlastnosti, které staré rozhraní neumí. Neznamená to, že to neumí objekt.

Příklad myslivce a psa... je pěknou ukázkou nepochopení toho, jak se aplikace rozšiřuje. Nejdřív se ptám, proč musím vědět, s jakým psem myslivec pracuje? Doposud jsem to nepotřeboval. No tak tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo. Tam kde potřebuju víc, přetypuju si IMyslivec na IMyslivec2, který už počítá s tím, že myslivec může mít víc psů.

dynamic_cast, narozdíl od dynamických jazyků, má výhodu v tom, že si rozhraní vyresolvím jen jednou na začátku, a pak mohu pracovat už s novým rozhraní, stejně rychle jako se starým rozhraní.


Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #80 kdy: 07. 12. 2010, 15:03:51 »
Citace
No tak tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo.
Ale nemělo. Copak myslivec může vlastnit pouze jednoho psa? Nemůže. Takže prostě rozhraní myslivec nepopisovalo objekt myslivec správně. Akorát to autor programu nepotřeboval, tak mu to zatím nevadilo.

Samozřejmě, jde to relativně bez větších úprav programu zalepit novým rozhraním a dynamic_castem, ale:

* místo statické kontroly datových typů za překladu mám dynamickou kontrolu typů za běhu. Tzn. ztratím veškeré výhody staticky typovaného jazyka (kontrolu za překladu a hlavně bezpečnou kontrolu  - u kontroly za běhu nikdy neotestuji co všechno na dané místo může doputovat), aniž bych se ale zbavil jeho nevýhod (např. nutnost uvádět typy).

* v okamžiku, kdy potřebuji myslivce se dvěma psy, tak musím přepsat velkou část objektů, které s myslivcem se psem pracují - přesněji všechny, které pracují se všema psy myslivce (jinak se program nechová správně).
Např.: Setkání s veterinářem (má naočkovat všechny psy), kontrola myslivce na hranici (kontrola, jestli má myslivec na psy papíry), setkání s rasem (chudinci pejsci), setkání s číňanem (only joking :-), my zas jíme hindům krávy :-)) atd...

No a tady je implementace nového rozhraní vyloženě nebezpečná, protože mi nikdo neřekne, které všechny objekty takto s myslivcem interagovaly, takže u většího programu skoro s jistotou na něco zapomenu. Takže sice budu mít "funkční program" ale přes hranice my myslivec s jedním nenaočkovaným psem projde.

Proto tvrdím, že je chybou původního návrhu, když v něm myslivec nemůže mít víc psů - když je teoreticky možné, že by jich měl více. I když to program v tuto chvíli nepotřebuje a i když si pak mohu nadefinovat nové rozhraní.

Samozřejmě někdy by implementace multipsího myslivce (obecně implemntace přesnějšího popisu reality) byla o tolik složitější, že se to nevyplatí a je lepší udělat "chybu" záměrně. To však neznamená, že člověk nedělá "chybu", jen o ní ví :-)
Přirovnal bych to k situaci, kdy se člověk rozhodne používat Newtonovu mechaniku (a zanedbá relativitu). To je samozřejmě korektní postup, ale
- člověk musí vědět, že něco zanedbává
- měl by si bejt OPRAVDU jistej, že tu relativitu potřebovat nebude.
Pokud napíšu systém s Newtonovou teorií a následně zjistím, že potřebuji relativitu, udělal jsem chybu. Pokud napíšu program s rozhraním myslivce se psem a pak zjistím, že potřebuji multipsa, udělal jsem chybu.


Tar

Re: Jste zastánci OOP programování?
« Odpověď #81 kdy: 07. 12. 2010, 16:40:40 »
tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo. Tam kde potřebuju víc, přetypuju si IMyslivec na IMyslivec2, který už počítá s tím, že myslivec může mít víc psů.
Za tohle by se melo kamenovat :)
Kdyz jsem myslivec s vice psy, je absurdni abych se vydaval za myslivce s jednim psem (tj. abych implementoval puvodni rozhrani), protoze to NIKDY nebude spravne. Tohle je presne cesta kterou se ze slusnych programu stavaj odporny skladky nespravovatelnyho kodu. Hlavne abychom nahodou nemuseli udelat nejakou praci "navic" :))

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #82 kdy: 07. 12. 2010, 17:03:30 »
Jo, dá se to říct i jadrnějc :-) plnej souhlas, tendle aspekt jsem nezmínil.

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #83 kdy: 08. 12. 2010, 00:03:35 »
Citace
No tak tam, kde to nepotřebuju může ta metoda vrátit nějakého náhodného psa, jestli že jich má víc, nebo toho prvního, nebo psa podle datumu v kalendáři. To je fuk, doposud to smysl mělo.
Ale nemělo. Copak myslivec může vlastnit pouze jednoho psa? Nemůže. Takže prostě rozhraní myslivec nepopisovalo objekt myslivec správně. Akorát to autor programu nepotřeboval, tak mu to zatím nevadilo.

Krásné jak víme, co je správné, aniž bysme znali vlastně zadání a původní návrh.

Samozřejmě, jde to relativně bez větších úprav programu zalepit novým rozhraním a dynamic_castem, ale:

Nejedná se o žádné lepení, ale o legální techniku. Pokud vám vadí dynamic_cast, tak použijte COM+, kde máte podobnou funkci QueryInterface. Celý COM+ je na tom postavený

* místo statické kontroly datových typů za překladu mám dynamickou kontrolu typů za běhu. Tzn. ztratím veškeré výhody staticky typovaného jazyka (kontrolu za překladu a hlavně bezpečnou kontrolu  - u kontroly za běhu nikdy neotestuji co všechno na dané místo může doputovat), aniž bych se ale zbavil jeho nevýhod (např. nutnost uvádět typy).

Jenže my objektoví programátoři kolikrát nevíme, jestli chceme jazyk s dynamicky typovanými objektu, nebo staticky typovanými objekty. Jenže u staticky typovaných objektů třeba zapomeňte na polymorfismus. Protože ani ten Vám překladač neohlídá. Maximálně ohlídá matchování rozhraní, ale to je tak všechno.


* v okamžiku, kdy potřebuji myslivce se dvěma psy, tak musím přepsat velkou část objektů, které s myslivcem se psem pracují - přesněji všechny, které pracují se všema psy myslivce (jinak se program nechová správně).

To je Váš názor. Já před sebou vidím návrh, kde nemusím.


Např.: Setkání s veterinářem (má naočkovat všechny psy), kontrola myslivce na hranici (kontrola, jestli má myslivec na psy papíry), setkání s rasem (chudinci pejsci), setkání s číňanem (only joking :-), my zas jíme hindům krávy :-)) atd...

Tohle v původním návrhu není. Zato vaše komponentní aplikace má takový úspěch, že každé myslivecké združení má vlastní implementaci myslivce. Zkuste jim teď říct, že v nové verzi budou muset investovat do programátora, aby to všechno přepsal?

No a tady je implementace nového rozhraní vyloženě nebezpečná, protože mi nikdo neřekne, které všechny objekty takto s myslivcem interagovaly, takže u většího programu skoro s jistotou na něco zapomenu. Takže sice budu mít "funkční program" ale přes hranice my myslivec s jedním nenaočkovaným psem projde.

No už se stalo. Asi by to člověk měl smazat a začít znova? Nebo s tím praštit úplně :-D

Proto tvrdím, že je chybou původního návrhu, když v něm myslivec nemůže mít víc psů - když je teoreticky možné, že by jich měl více. I když to program v tuto chvíli nepotřebuje a i když si pak mohu nadefinovat nové rozhraní.

Nejlepší je v tuto chvíli začít hledat viníky a strhávat jim prémie  ;D

Samozřejmě někdy by implementace multipsího myslivce (obecně implemntace přesnějšího popisu reality) byla o tolik složitější, že se to nevyplatí a je lepší udělat "chybu" záměrně. To však neznamená, že člověk nedělá "chybu", jen o ní ví :-)

Pověste ho vejš, ať se houpá!  ;D

Přirovnal bych to k situaci, kdy se člověk rozhodne používat Newtonovu mechaniku (a zanedbá relativitu). To je samozřejmě korektní postup, ale
- člověk musí vědět, že něco zanedbává
- měl by si bejt OPRAVDU jistej, že tu relativitu potřebovat nebude.
Pokud napíšu systém s Newtonovou teorií a následně zjistím, že potřebuji relativitu, udělal jsem chybu. Pokud napíšu program s rozhraním myslivce se psem a pak zjistím, že potřebuji multipsa, udělal jsem chybu.

Tak pánové, až příště půjdete na nějaký ten pól, tak nezapomeňte zásoby násobit dvěma.

 ;D ;D ;D ;D

Kecy kecy kecy!

 ;D ;D ;D ;D

Programoval jste vůbec někdy nějakou větší aplikaci? Nebo jen akademicky melete? Představte si, že máte komponentu Lov, kam chodí myslivci na lov. Myslivec vystřelí a zasáhne cíl a pes vyběhne a cíl přinese. Tahle komponenta běží už delší čas, má jí skoro každé myslivecké sdružení a používá se tam jednoduché rozhraní IMyslivec, který předpokládá, že k lovu využije jediného psa, který po výstřelu vyběhne, najde střelený cíl a přinese ho. Protože s každým výstřelem můžete trefit jediný cíl, stačí vám pouze jeden pes, proč se trápit s problémem, který není.

Pak se jednoho dne rozhodnu jako produktový manager vydat třeba komponentu veterinář pro kontrolu psů a zjistím, že by myslivec měl mít psu víc. A co teď? Říkám Vám rovnou, že odpovědí na Váš návrh přepsat původní rozhraní bych reagoval v lepším případě strhnutím prémií z výplaty. A ještě dlouho bych řešil "jaké paka jsem si to do firmy pozval".

Je nemyslitelné a finančně velice náročné přepisovat všechny implementace rozhraní IMyslivec. Představte si, že jste Microsoft a máte vylepšit rozhraní IDirect3D. Na světe existuje několik milioónů aplikací využívající staré rozhraní. Vy byste si lajznul takovou změnu?

Existuje tedy jediná cesta a to vytvořit nové rozhraní, IMyslivec2

Kód: [Vybrat]
class IMyslivec {
public:
 ...
   virtual IPes *getPes() = 0;
 ...
};

class IMyslivec2: public IMyslivec {
public:
   virtual PsiKontejner &getPsy() = 0;
   virtual IPes *getPes() {return getPsy().empty()?0:&getPsy()[0];}
};

Pokud přivede myslivec psy k veterináři, bude veterinář požadovat rozhraní IMyslivec2. Dokonec už ve funkci:

Kód: [Vybrat]
void jdiKVeterinari(IMyslivec2 &m)

...můžete vyžadovat nové rozhraní. Holt starý myslivci k veterináři chodit nebudou, ale to neznamená, že by nemohli po staru lovit dál. Třeba si veterináře zajišťují svými silami.

Jaký to má výhody? Kromě toho, že nemusíte sahat do existujících fungujících komponent (po vzoru, co funguje na to nesahej), existence starého rozhrani vám umožňuje v jednoduchých situacích použít původní osvědčené rozhraní, které nevyžaduje implementaci kontejneru psů. Například když si uděláte se svým mazlíčkem doma cvičný lov. Během cvičného lovu nemusíte chodit k veterináři. Leckteré místo se Vám z jednoduší.

A dynamic_cast? Ten tam ani nemusí být

Kód: [Vybrat]
class MujMyslivec: public IMyslivec2
může jít jak na lov, tak k veterináři.
Kód: [Vybrat]
class StaryMyslivec: public IMyslivec
může jít pouze na lov.

A pokud někde obdržím referenci na objekt IMyslivec a budu ho chtít před loven poslat k veterináři, mohu to napsat takto

Kód: [Vybrat]
function PredLoven(IMyslivec &m) {
  IMyslivec2 *m2 = dynamic_cast<IMyslivec2 *>(&m);
  if (m2) jdiKVeterinari(m2);
  jdiNaLov(m);
}

Považujete tohle řešení za prasácke?

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #84 kdy: 08. 12. 2010, 12:26:08 »
Citace
Krásné jak víme, co je správné, aniž bysme znali vlastně zadání a původní návrh.
V tom je totiž krása OOP - chyby návrhu každého objektu se dá posoudit, aniž by bylo třeba znát "okolí".
(Samozřejmě okolí je potřeba pro to, aby se posoudila vhodnost toho interfacu pro interakci s okolím, ale toto posuzování má přijít teprve po posouzení správnosti daného rozhraní jako takového).

Citace
Tohle v původním návrhu není.
V původním návrhu je myslivec. Může myslivec vlastnit více psů. Ano, takových myslivců je spousta. Takže popisovat ho rozhraním, které umožní pouze jednoho psa je špatně.

Citace
Zato vaše komponentní aplikace má takový úspěch, že každé myslivecké združení má vlastní implementaci myslivce.
Ne, v mém pojetí se všichni lidi, kteří používají dané rozhraní pořádně zamyslí, navrhnou rozhraní tak, aby ho už pokud možno nebylo nutné modifikovat a používají ho. Samozřejmě ne vždy se to povede, ale protože já považuji některé návrhy rozhraní za apriori špatné, nestane se mi totéž, co Tobě:
Ve Tvém návrhu se nejdřív nabastlí myslivec s jedním psem, pak někdo přijde na to, že potřebuje myslive s více psy, tak nadefinuje druhé rozhraní, někdo další zjistí, že potřebuje myslivce s více flintami, nadefinuje nové rozhraní, pak někdo zjistí, že potřebuje myslivce s více dýmkami... nové rozhraní.....
Já, protože vím, že apriori je blbina myslivec s jednou flintou, psem či dýmkou (vždy jich může mít víc) tak nemusím žádná nová rozhraní definovat, protože už původní rozhraní funguje správně.

Citace
No už se stalo. Asi by to člověk měl smazat a začít znova? Nebo s tím praštit úplně :-D
Jo, člověk někdy udělá chybu, to je normální. Holt si prostě přizná: aha, při návrhu rozhraní myslivec jsem udělal pořádnou botu. A musí to buď přepsat (upravit rozhraní myslivce) nebo zaflikovat (udělat rozhraní myslivec2). Někdy je lepší to, někdy to, podle toho, jak je aplikace velká, kde všude se rozhraní používá, jak často se do ní šahá (čím více, tím se víc vyplatí čistší kód) atd...
U většího projektu může být dobrá cesta nadefinovat nové rozhraní, staré prohlásit za obsolete a pomalu (když se zrovna upravuje danej kus) ho z aplikace odstraňovat. Narozdíl od udržování dvou rozhraní se časem kód zas pročistí a přitom náklady budou srovnatelné (do budou spíš nižší, protože kód bude čistší).

Já neříkám, že řešení s dynamic_castem je vždy špatně. Říkám, že to, že je ho nutné použít ukazuje, že je něco špatně: většinou ten původní návrh.

---

Ve zbytku postu polemizuješ úplně s něčím jiným, než co tvrdím. Pokud už se chyba STALA, tedy pokud existuje rozhraní myslivec s jedním psem, samozřejmě může být levnější a tedy lepší řešení to opravit pomocí rozhraní myslivec2.
Co tvrdím je, že při PŮVODNÍM návrhu aplikace byla chyba udělat myslivce s jedním psem, pokud byla alespoň trochu reálná možnost, že myslivec může mít psy dva. Protože to při dalším vývoji aplikace způsobí to, že přes hranice budou chodit nenaočkovaní psi (a nebo drahý refaktoring).

---

Myslím, že to, v čem se lišíme je pragmatismus kontra idealismus. Vy tvrdíte, že pokud rozhraní vyhovuje pro dané účely v daném čase, je dobře.
Já tvrdím, že rozhraní má dobře popisovat daný objekt. Pokud popisuj dobře daný objekt, pak bude vyhovovat: a to nejen pro daný účel v daný čas, ale pro všechny účely a vždy.
Vzhledem k tomu, že jedním ze základním principů OOP je znovupoužitelnost, myslím, že můj pohled je bližší k filosofii OOP než Tvůj.
Já svého myslivce mohu použít jak při honu, tak u veterináře, tak i pro přechod hranic. Tvůj myslivec se hodí jen na ten hon (a to ještě nesmí sestřelit dvě kachny najednou, což se brokovnicí dosti často povede)...

Samozřejmě ne vždy lze postihnout úplně všechny možnosti. Ale např. v případě myslivce se psem je rozdíl v náročnosti implementace marginální (mohu tam dát ještě metodu getNejakyPes(), takže používat se to bude úplně stejně, jen holt místo pesPtr bude ve vlastnostech std::list<pesPtr>) ale v budoucnu to ušetří hafo problémů.
« Poslední změna: 08. 12. 2010, 12:37:39 od Logik »

ondra.novacisko.cz

Re: Jste zastánci OOP programování?
« Odpověď #85 kdy: 08. 12. 2010, 15:55:17 »
V tom je totiž krása OOP - chyby návrhu každého objektu se dá posoudit, aniž by bylo třeba znát "okolí".
(Samozřejmě okolí je potřeba pro to, aby se posoudila vhodnost toho interfacu pro interakci s okolím, ale toto posuzování má přijít teprve po posouzení správnosti daného rozhraní jako takového).

Obdivuju vaši jistotu  ;D

V původním návrhu je myslivec. Může myslivec vlastnit více psů. Ano, takových myslivců je spousta. Takže popisovat ho rozhraním, které umožní pouze jednoho psa je špatně.
Můj příklad byl akademický stejně jako váš. Místo myslivce tam může být Desktop a místo psa tam může být Monitor. Doby, kdy šlo připojit k desktopu jen jeden monitor existovali a nikoho tehdy nenapadlo, že by k desktopu bylo možné připojit monitorů víc. Dodnes existují aplikace, které nepočítají s vícero monitorama.

Ne, v mém pojetí se všichni lidi, kteří používají dané rozhraní pořádně zamyslí, navrhnou rozhraní tak, aby ho už pokud možno nebylo nutné modifikovat a používají ho. Samozřejmě ne vždy se to povede, ale protože já považuji některé návrhy rozhraní za apriori špatné, nestane se mi totéž, co Tobě:
V tom případě si nechte vaše pojetí pro sebe. Nemyslím, že by mělo smysl to dál rozvijet. Každopádně trvám na tom, že to je akademická diskuze, mající k praktickému smyslu daleko. Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.

Citace
Samozřejmě ne vždy lze postihnout úplně všechny možnosti. ....
Toho bych se držel a zkusil najít výhody OOP právě v tom, že nikdo z nás nemá patent na rozum.

JS

Re: Jste zastánci OOP programování?
« Odpověď #86 kdy: 08. 12. 2010, 16:45:47 »
Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.

A jake to ma podle vas vysledky v praxi? Nechci flamovat, ale prijde mi, ze je to dost zoufale. Kdyz se podivam na opensource, tak nejlepsi reusability se ukazuje u aplikaci s textovym rozhranim (tedy dilem unixova filozofie), ktere je mozne pak ruzne volat z ruznych dalsich mist. Zatim jsem nevidel, ze by nekdo napsal OOP aplikaci (ne knihovnu - to je neco jineho), a pak nekdo jiny vzal polovinu objektu a nad tou postavil jinou aplikaci (mozna date nejaky uspesny priklad, co ja vim). Ono nakonec i s temi knihovnami - co ja vim, tak nejvic reusable jsou klasicke knihovny s C rozhranim, protoze to umi obalit prakticky kazdy skriptovaci jazyk.

Ono je to asi podobne jako s tou multiplatformnosti. Java je pry multiplatformni, ale bezi na kolika, na 6 platformach? Zatimco C program prelozite na vsem. Sliby, sliby, sliby a marketing..

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #87 kdy: 08. 12. 2010, 17:00:27 »
Citace
Místo myslivce tam může být Desktop a místo psa tam může být Monitor.... Dodnes existují aplikace, které nepočítají s vícero monitorama.
Proto také člověk, který navrhoval desktop udělal chybu, když nevymyslel, že může být víc monitorů. A teď se musí flikovat.
Můžeme se k tomu postavit dvěma způsoby. Buď nad tím mávneme rukou a nebudeme to řešit a příště zas splácáme myslivcopsa, nebo to alespoň jasně pojmenujeme jako chybu, poučíme se a až budeme navrhovat svůj desktop, tak už to uděláme správně.

Citace
Hlavní smyslem OOP je re-usability, a tímto přístupem právě tenhle smysl jaksi narušujete.
??? Jaksi nechápu čím narušuji reusabilitu??? Já tvrdím, že se objekty mají navrhovat korektně, i když třeba některé jejich vlastnosti (např. možnost mít více psů) se v dané chvíli nevyužijí. A to rozhodně re-usabilitu zvyšuje a ne naopak.

To Vy tady hájíte myslivce s jedním psem, který v následném vývoji dělá problémy s re-usabilitou, ne já.

martin

Re: Jste zastánci OOP programování?
« Odpověď #88 kdy: 08. 12. 2010, 17:25:22 »
Proto také člověk, který navrhoval desktop udělal chybu, když nevymyslel, že může být víc monitorů. A teď se musí flikovat.

Já bych to nenazýval chybou. Zrovna tak není chyba, že původní okenní systém není třírozměrný. V tomhle jsem na straně pragmatizmu. Nač plýtvat zdroji na něco, co není dnes potřeba, a během doby se může ještě změnit.

Snaha o dokonalost je příliš nákladná činnost s pochybným výsledkem. Komplexní nadčasové věci v IT snad ani neexistují.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re: Jste zastánci OOP programování?
« Odpověď #89 kdy: 08. 12. 2010, 20:41:03 »
Samozřejmě, pokud je implementace "správného" rozhraní daleko dražší, pak má zjednodušení své místo. Běžně např. taky člověk používá Newtona a ne Einsteina.
Chyba je, pokud člověk ale používá Newtona, aniž by si ověřil, že toho Einsteina nebude potřebovat. A pokud ví, že ho bude, tak má např. připravit rozhraní tak, aby byl Newton rychlej a přitom Einstain použitelnej.

V našem případě to třeba znamená, u myslivce uděšlat jak metodu GetPsy(), tak i metodu GetNejakyPes() a používat zatím tu druhou. Tady to nic nestojí a ušetření práce v budoucnu je obrovské.

Samozřejmě, že predikovat např. deset let dopředu nejde. To ale přeci neznamená, že je správné a to zcela rezignovat.