Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Logik

Stran: 1 ... 55 56 [57] 58 59 ... 68
841
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 19. 12. 2010, 15:27:36 »
BLEK.: Samozřejmě, člověk nikdy neví, kam se vývoj vyvine. V tu chvíli je nejlepší popsat správně, to co je. Člověk by to ale měl popsat přesně. Rozhraní myši popisuje myš +- přesně (kdyby tam rovnou udělali podporu více tlačítek, tak by nemusela mít každá myš vlastní ovládací program).
Jinými slovy, když člověk v době vzniku rozhraní vzal kteroukoli myš, šla tím rozhraním popsat. Nadmyš schopná pracovat ve 3D, klikat na více místech najednou apod. je zařízení natolik od myši odlišné, že už se nedá označit jako "myš". Je to prostě něco jiného, byť se tím dá myš emulovat.

To je velkej rozdíl oproti myslivci - mít jednoho nebo více psů nijak nezmění podstatu myslivce a v době vzniku rozhraní myslivec už dávno existovali myslivci, které to rozhraní popisovalo špatně (protože těch více psů nepodchytilo).


PS: Navíc, vždy je možné zjednodušení, jako např. ve WINApi onmousedown/up a onmouseclick. Kdo chce jednoduché rozhraní používá jednoduchej click a když chceš více informací, můžeš použít onmousedown. 
Tvoje argumenty se vedou k tomu, že by bylo lepší, kdyby rozhraní ONMOUSEDOWN/ONMOUSEUP neexistovalo. Já tvrdím, že kdyby už v době prvního winapi zavedli rozhraní pro multitouch, bylo by to lepší řešení, než ho zavádět až teď.

Ono to i přesně odpovídá: kdyby to rozhraní bylo, tak by multitouch v pohodě zvládala všechna zařízení, co by to mohla umět (což nezvládají). Naopak situace byla taková, že každý výrobce multitouch tabletu si udělal "svojeho myslivce" - až teprv  microsoft přišel s jednotným univerzálním multitouch rozhraním. Bylo by snad lepší, kdyby zůstalo u jednotlivých proprietálních rozhraní?

To co tvrdím je: rozhraní mají být co nejvíce univerzální a mají se navrhovat tak, aby se co nejuniverzálnějšími mohli stát. A rozhraní myslivec s jedním psem to imho nesplňuje.

ondra.novacisko: Ale to je přeci naprosto nesouvisející věc. Ano, člověk se musí umět vypořádat se špatně napsaným rozhraním. To ale neznamená, že nemůže o tom rozhraní prohlásit, že je špatně napsané.

alefo: souhlas, jen bych do součtu doplnil knihovny. Možná je myslíš pod nástrojema, nebo pod jazykem ale myslím, že je to natolik významnej prvek, že si zaslouží vlastní sčítanec.

842
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 18. 12. 2010, 20:49:16 »
backup: evidentně se nepohybuješ ve fyzice. I ti, co sefyzikou zabývají, tak mezi sebou vedou dalekosáhlý spory, co vlastně kvantovka znamená,jak její výsledky interpretovat atd... Takže příměr sedí: nikdo neví, co to vlastně znamená, každej tomu rozumí jinak, ale všichni to používaj a dává to dobrý výsledky.

alefo: nikoli, ale architekt je i "umělec" (často bohužel). Myslímale, že i když se návrhy budou lišit, tak budou mít vždy např. vypínače vpodobné výšce, po vstupu do místnosti nejdřív zádveří či předsíň, v obýcákunebude záchod apod.

BLEK.: to je ale jiný případ. Myš je zařízení, které umí přijmout jeden klik. A ty knihovny pracovali s myší. Multitouch device je něco jiného než myš a proto má mít jiné rozhraní.  Takže v tomto případě to správně samozřejmě je, ale jde o jiný případ.

Multitouch device může myš "emulovat". Protože "má stejnou schopnost" jako myš: ukázat na jedno místo na obrazovce. Proto multitouch může implementovat i rozhraní myši. To ale přeci neznamená, že multitouch screen je myš.

Rozhraní myši myš popisuje dobře. Že nepopisuje dobře kočkodana (multitouchdevice) je přeci irelevantní. Naopak rozhraní myslivce s jedním psem nepopisujedobře myslivce - myslivec může mít více psů a furt to bude ten samý myslivec.

A ad sprasení: popsání objektu správně přeci neznamená, že následné ho nemůžeme"zjednodušit". Tzn. že by od začátku bylo rozhraní pro multitouch a rozhraní pro myš (které by multitouch devices implementovali také).

Stejně, jako jsou dvě rozraní pro klávesnici, kdy jedním se pracuje jednoduše a s jedním se pracuje (ONKEYUP a ONKEYPRESS události) a pomocí prvního z nich se se seznamem stisknutých kláves dá pracovat. Kdyby bylo takové rozhraní i pro multitouch, třeba by se místo ohromného haló tendle způsob ovládání už dávno používal.... Naopak by byl bonus, že by bylo jasně specifikováno, jak se multitouch gesto interpretuje program psaný pro myš (jestli získá první nebo všechny stisky).

Nebo Ty považuješ za dobré, že v normálnim winapi s multitouch pracovat nelze??

A ad více klávesnic? Kdyby to šlo, myslím, že např. překladatelé do ruštiny byněkdy přivítali, kdyby mohli mít vedle sebe dvě klávesnice, jednu na azbuku ajednu na latinku... A opět to při rozumném designu nemusí znamenat pražádné zesložitění programu.
Já nepopírám, že lze na všechno přijít. Ale na to, že myslivec mná více psů může přijít každý.

843
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 18. 12. 2010, 14:05:43 »
Málo lidí rozumí kvantové teorii a je kolem ní plno sporů. To je ten největší důkaz, že kvantová teorie je problematická záležitost a skoro jistě na ho.no.


844
Server / Re: Chci si postavit domácí cloud
« kdy: 18. 12. 2010, 00:05:48 »
Pokud z toho nejsi moudrý, znamená to imho jediné. Zamysli se, jak jde úloha rozseknout (např. podle jednotlivých site) a spouštěj na každém serveru úlohu zvlášť. Pokud bys to chtěl spouštět z jednoho místa, pak si najdi něco o MPI a paralelizuj úlohu pomocí MPI. Obě řešení jdou s malou námahou implementovat bez potřeby nějakého speciálního (komerčního) software.

845
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 17. 12. 2010, 10:43:16 »
Vau :-) dík za info, řikal jsem si, že takovou hezklou věc určitě už někdo musel vymyslet :-)

846
Server / Re: Jaký load je na web serveru ideální?
« kdy: 16. 12. 2010, 18:23:29 »
Je třeba ale říct i B, a to že čím víc disků, tím je to poruchovější a víc to žere, takže pro nějakou rozumně velkou databázi (kdy by se disky kupovali opravdu jen kvůli rozložení zátěže) by daleko lepší investicí byl kvalitní SSD nebo rozšíření paměti (disková cache).

RAID navíc víc pomáhá u kontinuálního IO, u serveru bejvá většinou náhodný.

Tím nechci říct, že RAID je nesmysl, jen pokud není databáze příliš velká, jsou imho lepší možnosti, jak upgradem hardware systém urychlit.

847
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 16. 12. 2010, 14:10:21 »
Vau, konečně spřízněná duše :-). I když s Tigerem bych se ati taky shodnul.


Citace
Hlavne mi nie je jasné, ako psy súvisia s interfejsom Myslivca. Podľa mňa veľmi treba zvážiť, či ten coupling tried je naozaj potrebný. Naozaj má každý myslivec psy? Čo ak mám robotického myslivca, ktorý o psoch netuší?
Souhlas. To jsem i snad už někde v postech psal, že vlastnit psy může kdokoli a tedy by mělo být spešl rozhraní IVlastníkPsů. Pak je otázka, zdali Myslivec je musí nutně vlastnit, pokud ano (my jsme si ho tak neformálně definovali), pak by měl být od toho rohraní poděděn (v podstatě se tím říká myslivec je člověk, který bla bla bla a taky vlastní psy), pokud ne, tak ne.

Za zmíňku možná tady stojí, že pokud 95%myslivců má psy a často se s nima pracuje, tak považuju za legální říci, myslivec má psy, a robotický myslivec pak bude mít nula psů. Práce s tím (zbytečné definování metody getPsy u robota) bude menší, než neustálé dotazy: implementuje tento myslivec IVlastnikPsu?

Co my schází v objektovvých jazycích je "multitypová kontrola". Např. objekt A implementuje rozhraní IA, IB, IC a ID. Mám funkci, která požaduje objekty implementující IA a IB. Ve všech jazycích s typovou kontrolou, co znám, se to musí vyřešit tak, že nadefinuji rozhraní IAB extends IA, IB a checkuji proti němu.
To má ale velké nevýhody - ten objekt A by tedy měl být poděděn z IAB, IC, ID. To ale tvůrce objektu nemusel vědět. Navíc, další funkce můžče chtít objekt implementující IA a IC. Nebo IB a ID.. Takže v podstatě pro každou použitou kombinaci rozhraní musím psát vlastní rozhraní a to už je trochu opruz. Jak by bylo krásné, kdyby šlo do definice funkce napsat, sem smí objekty, které implementují IA a zároveň IB. Něco jako
fce(IMyslivec + IMaFlintu myslivecSFlintou)
nebo
fce(IMyslivec + IMaPsy myslivecSePsem)

Nejlépe tak, že by šlo definovat
IMyslivec + IMaPsy = IMyslivecSePsy
ale nikoli ve formě dědičnosti, ale opravdu rovnosti. TJ. že každý objekt implementující tyto dvě rozhraní by se považoval za IMyslivceSePsy.

Citace
Má každý myslivec (vzhľadom na aktuálne poznatky o systéme) práve jedného psa a je to bezpodmienečne nutné?....
Souhlas.

Citace
A IMyslivec extends IVector je už zhůveřilost.
Právě! :-) Jen jsem ukazoval, proč je to zhůvěřilost. Pokud se na rozhraní kouká čistě jako na poskytované služby, jako na něco, čím s polu komunikují dva objekty (v tomto případě myslivec a někdo, kdo chce znát jeho psy), tak by to bylo v pořádku. Proto jsem tvrdil, že tento pohled na rozhraní není správný. Že rozhraní není jen nějaký anonymní popis toho, co daný objekt poskytuje, ale vyjadřuje schopnosti či identitu daného objektu. A jelikož myslivec není seznam psů, tak nemůže implementovat rozhraní ISeznamPsu (respektive IVector<PES>.
Pokud potřebuji vědět, že myslivec je vlastník psů, tak může implementovat rozhraní IVlastnikPsu (to je) a IVectorPsu zahrnout právě jak píšeš nikoli dědičností, ale agregací.

Ono i todle (pod)téma vlastně začalo nad tím, kdy jsem protestoval nad zneužíváním dědičnosti. (na místě, kde by měla být agregace) :-)

848
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 16. 12. 2010, 11:13:59 »
Citace
ja by som nevahal prirovnat interfejs k sade operacii na sluzbe)
Poklud je to sada operací k jedné službě, tak to do jednoho rozhraní patří. Např. otevřít "soubor", zapsat, přečíst, zavřít soubor. Tam je to úplně v pořádku - zavření a otevření nemá od operace čtení nebo psaní smysl. I když tady by to asi chtělo rozdělit na IReadable, IWritable a IReadableWritable.

Samozřejmě v reálu člověk z těchto akademických kritérií někdy sleví i v jiném případě (pokud píšu malý jednoúčelový kód, tak nestrávím dva roky návrhem rozhraní). Měl by ale vědět, že: "tady jsem něco zjednodušil". Aby když to v tom zjednodušení začne skřípat (začnu potřebovat lesní stráž), tak hned věděl kde a proč a mohl to opravit - v rané fázi vývoje je většinou takovýto jednoduchý refaktoring (vydělení části služeb z rozhraní A do rozhraní B a podědění A od B) jedodušším řešením, než implementace x metod s výjimkou
UnsupportedOperationException.

Citace
Z prispevku vam vypadlo, aky je druhy druh rozhrania. Prvy uplne chapem.
No právě to rozhraní "jsem", oproti rozhraní "umím". Zpravidla rozhraní umím definuje jedmnoduché služby, zatímco rozhraní "jsem" je agreguje do funkčního celku (např. ISortable, IRandomAcces je co umí, ISortableVector pak definuje identitu objektu: být řaditelným seznamem - a je poděděn z ISortable a IRandomAccess).

edit: jasnější příklad.
Jsou to sice subtilní rozdíly, ale pro návrh aplikace je myslím nutné si uvědomit, co které rozhraní reprezentuje. Např. pokud má myslivec psy, tak by někdo mohl propadnout pokušení mu implementovat rozhraní IVector<Pes>. Ale co když pak budu chtít pracovat jen s jeho jezevčíky, nebo jen s jeho oblíbenými psy, nebo..... Těžko budu implementovat rozhraní IVector<Pes>, budu to muset řešit jinak a aplikace bude nekonzistentní.

Pokud si předem řeknu je myslivec seznam psů? "Aha, není"... a místo toho mu udělám metodu getPsy(), tak snadno mu pak dodělám metodu getJezevciky() a getOblibenePsy().





Citace
Neviem si predstavit priklad, ako by interfejs mohol zmysluplne vynucovat kardinalitu.
Pokud bude mít myslivec metodu getPes(), vynucuje kardinalitu 1:1 (popř. 1:0). Pokud bude mít metodu getPsy(), tak je kardinalita 1:n.
U myslivce:psa je správná kardinalita 1:n, např. u syna a (biologické) matky je 1:1 - tam by metoda getMatky() byla podivná.... i když to dneska už možná ani neplatí :-) :-).

Pozor, tím neříkám, že implementace myslivce pak nemůže mít pouze jednoho psa. To samozřejmě ano - to je jeho interní záležitost. Rozhraní ale umožňuje mít více psů a tedy pokud kdykoli (v tomto nebo jiném) projektu budu potřebovat více psů, jde o elemenární úpravu.

849
Server / Re: Jaký load je na web serveru ideální?
« kdy: 15. 12. 2010, 18:37:59 »
Disk by měl problém, pokud byv tompu bylo hodně procesů ve stavu D, popř. to zjistíš pomnocí vmstat (io in/out).
Nicméně v topu se procesy čekající na disk započítávají do čekajících procesů, takže pokud máš load 0,5 - 1,8, tak to imho není nic hrozného.
Disku (mimo jeho posílení např. rozložením zátěže na víc disků) pomůže i upgrade paměti, někdy může pomoci lepší nastavení parametrů databází (větší cache apod.). Tady asi obecný návod neexistuje, tady musíš zjistit co zatěžuje disk a podle toho konat.

850
Vývoj / Re: Semafor a zastavení procesů
« kdy: 15. 12. 2010, 16:05:02 »
Jo, rozhodně bych místo textového souboru použil databázi, klidně něco malého ko sqllite nebo embeded firebird. Nevýhoda ale je, že tydle jednoúčelové databáze jsou povětšinou jednouživatlské. To jde ale snadno vyřešit jedním centrálním správcem + komunikací např. pomocí UDP protokolu nebo třeba message queues (klient pošle do message queueu serveru zprávu s identifikací svojí message queue). Další možnost je thready a kritická sekce. Ale to by byl jiný program :-)

Dej si do lock a unlock logovací výpisy PID, Akce a stav semaforu (viz sem_getvalue). Možná Ti to napoví, kde je chyba, třeba něco omylem zamykáš dvakrát nebo tak.

851
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 15. 12. 2010, 13:35:57 »
Ondra: Implementace je významy přetížené slovo - možná jsem ho nezvolil šťastně, v každém případě tím, že rozhraní implementuje, myslím že postihuje, vystihuje, reprezentuje danou věc. Myslím, že kdo se snaží pochopit to pochopí, komu jde jen o to ukázat, že je druhý vůl, se na tom samozřejmě může povozit. Většinou to lidi dělají, když jim dojdou rozumné argumenty.

Alefo: IMHO jsou dva typy rozhraní. Jeden z nich je to co píšeš, až na jeden IMHO ale důležitý detail: vždy tady budou lidi, co umí strážit les, ale neumí krmit a  vice versa. Např. lesní stráž či pouze honí pytláky. Proto by mělo být pro každou schopnost vlastní rozhraní, abych nenutil lesní stráž s sebou táhnout pytel žaludů.
Ovšem pak nemám žádné rozhraní pro myslivce. Jak píšeš, myslivec je ten, který umí strážit zvěř a hlídat les. Proto budu mít rozhraní IMyslivec, poděděné z rozhraní IStraziLes a IKrmiZver. Toto rozhraní pak už neříká až tak co daný objekt umí ( když to z něj plyne), jako spíš definuje, co daný objekt je. Protože pokud myslivec je objekt, který umí strážit les a krmit zvěř, tak každý objekt, který implemenentuje toto rozhraní je (z pohledu klienta) nerozlišitelný od myslivce. Ta definice v podstatě říká: "Myslivec je někdo(něco), která umí to, to a to".

Pokud tuto distinkci mezi rozhraním definujícím schopnost a rozhraním definujícím identitu neuděláš, tak se dopustíš té chyby, že uděláš monolitické ropzhraní pro myslivce - a v okamžiku kdy budeš chtít udělat lesní stráž (dejme tomu, že myslivec má pravomoci lesní stráže a navíc krmí zvěř), tak budeš muset zasahovat do třídy myslivec. Pokud to správně rozdělíš předem, tak stačí implementovat rozhraní IHlidaLes a máš lesní stráž.

S tím, že konkrétní implementace je z hlediska rozhraní irelevantní, pak stopro souhlasím.

To, že můžeš navrhnout x druhů myslivců souhlasím - a i klidně třídu s jedním psem. Problém ale začne v okamžiku, kdy ve svém ROZHRANÍ pro myslivce řekneš, že myslivec je i ten, co má psa. Protože to prostě není pravda, nepopysuje to nic smysluplného.
Buďto nepotřebuješ rozhraním postihnout vztah myslivce a jeho psů (pak stačí rozhraní výše), nebo chceš. Myslivec je ale někdo, kdo má PSY!
Takže pokud uděláš rozhraní myslivecsjednimpsem, tak v podstatě uděláš rozhraní pro v realitě neexistující objekt. A takové rozhraní bude v podstatě nepoužitelné v dalších projektech, popř. Ti to bude dělat problém při rozšiřování funkčnosti Tvého projektu...

Když to shrnu: IMHO není vždy chybou, když třída nepostihuje přesně danou entitu. Člověk nemusí psát všechno. Není chybou, když rozhraní nepostihuje celou entitu/schopnost (když je potřeba další vlastnost, jde rozhraní podědit a vlastnost doplnit). Je ale chybou, pokud rozhraní danou entitu/schopnost postihuje špatně. Tzn. je špatně, když rozhraní popisuje vlastně něco jiného, než se s ním člověk snaží popsat. A jedním z exemplárních chyb v návrhu rozhraní je špatná kardinalita vztahů mezi objekty.

PS: Možná by šlo ještě doplnit, že v některých případech se rozdíl mezi rozhraním typu "umím" a rozhraním typu "jsem" stírá, většinou to je v tom případě, kdy danou věc definuje jedna schopnost. Ono také jde říci, že např. umět se seřadit (ISortable) znamená také  "být seřaditelným objektem".
A naopak pokud členy mysliveckého sdružení z deinice jsou právě a jen myslivci, tak schopnost říci číslo svého mysliveckého průkazu je inherentní schopnost myslivce a nemá smysl ji vydělovat do samostatného rozhraní. V obou případech je ale třeba dávat pozor, zdali je to oprvadu invariant, nebo zdali např. myslivci neuvažují nad píjmáním svých manželek do organizace.

852
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 15. 12. 2010, 02:24:00 »
Řekněte, zdali je správné toto rozhraní:
Kód: [Vybrat]
interface AASDASDASD
   {
   color getColor();
   };

Pro popis barvy je to dobré rozhraní. Pro popis oběda nikoli. To jasně ukazuje, že kvalitu rozhraní NELZE hodnotit samo o sobě, ale pouze ve vztahu k tomu, co má popsat.
Takže pokud se bavíme od začátku o rozhraní myslivec, tak se bavíme o tom, zdali toto rozhraní dobře popisuje Myslivce. Jinými slovy, nebavíme se o "nějakém anonymním rozhraní IMyslivec", ale o tom, zdali je IMyslivec dobrou implementací Myslivce.

853
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 14. 12. 2010, 17:23:50 »
Citace
Nevím, kdo mě tu přesvědčoval o tom, že když od začátku píšu skříň, že musím už dopředu počítat s tím, že do ní vložím víc než jeden šálek.
Vždyť píšete sám, že říkám, že to má být pořádně od začátku, tak proč m prosimvás furt cpete do toho, že chi někde něco nutně a za každou cenu přepisovat??

Právě proto, že je to ve výsledku daleko jednodušší, než se pak snažit nacpat do skříně na jeden šálek víc, je lepší to udělat pořádně hned. Právě proto, že pracovat se skříní jednou jako s jednošálkouvou a jednou jako s vícešálkovou přináší spoustu problémů.

Citace
O čemž jsem se přesvědčil právě ve Vaší poslední odpovědi ke které jsem Vás donutil
Nikoli, akorát jste prokázal, že celou dobu mluvíte o něčem jiném. Myslivec vlastnící psy je pořád stejný myslivec, ať už má jednoho nebo více psů, furt je to myslivec. Zbraň na skřety nebo na skřety i draky je furt nutně zbraň i nutně zbraň na skřety.
Ale editovatelný objekt není nutně objekt na serializaci a vice versa, objekt, který umí se vypsat na string není nutně objekt sloužící k serializaci a vice versa. (Vaše zadaní jsem nepochopil, no a? To, jestli slouží metoda tostring k serializaci, nebo k něčemu jinému, na podstatě věci naprosto nic nemění). Proto tyto případy spolu nesouvisí.

Citace
Zajímavé je také, že MouseListener nemá nic společného s Canvasem, přestože vy jste mě celou dobu přesvědčoval, že IMyslivec, konstruované pro lovecký účel by měl implementovat víc psů...
Canvas je něco na co se kreslí. Má to nějakou souvislost s myší. Ne. Tak proč by to implementovalo IMouseLisener?
Myslivec je člověk, který se psy a flintou se stará o les. Takže vlastnictví psů je v něm inherentně obsaženo. Proto je Vaše analogie špatná - respektive to analogie není.

Rozhraní IMyslivec popisuje co? Myslivce, který nemůže mít více než jednoho psa. Co to vůbec je? Copak existuje myslivec, který nemůže mít více než jednoho psa? Jestli ano (například to má zakázáno soudně), tak je to naprostá výjimka. Proto je rozhraní IMyslivec navrženo špatně - nepopisuje vlastně nic smysluplného.
Proto také není reusabilní - většina programů, co člověk píše, pracuje s nějakými reálnými objekty (respektive jejich reprezentací). Rozhraní, které reprezentuje nesmysl se do žádného dalšího projektu nebude hodit. A velmi často se ukazuje, že se nebude hodit ani do svého vlastního projektu.

Citace
IMyslivec slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti.... ...Taky jsem psal, abyste se nenechal zmást názvem
To mě jako chcete říkat, že jste říkal myslivec, ale myslel jste kočkodana? Od začátku byla debata o MYSLIVCI, nikoli o nějakém rozhraní, které se náhodou jmenuje IMyslivec. Pokud jste se bavil od začátku o kočkodanovi (nebo o "něčem, co slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti"), tak jste to měl říci. Ale celou dobu jste používal slovo myslivec, čemuž normální čech rozumí tak, že myslíte myslivce.

Jinými slovy, nezávisí na tom, jak se rozhraní jmenuje, ale co REPREZENTUJE. A pokud rozhraní reprezentuje myslivce, tak protože myslivec může mít více psů, tak má těch více psů mít.

Ono to možná ale přesně ukazuje na jádro pudla: kdybyste při návrhu myslivce místo nad "něčím, co slouží k zachytávání informací o revíru během lovu nebo výkonu myslivosti" myslel nad myslivcem, tak by se nestalo, že by měl jen jednoho psa.

"Reusability": přemýšlím nad objekty takovým způsobem, abych je mohl příště použít.


Citace
Celá diskuze se točí o udržení čistého kódu po celou dlouhou dobu vývoje software
:-) Uf. Celou dobu tu diskusi kolem toho točíte Vy. A zřejmě nemůžete pochopit, že diskuse začala o něčem úplně jiném. Já (a jestli jsem pochopil tak i Tiger a tar) se bavíme, jak navrhovat třídy, aby byly co nevíce znovupoužitelné, nikoli o tom, jak ji upravit, když ji někdo navrhnul tak, že znovupoužitelná není. Tam už jde o volbu nejmenšího zla.
  O tom jsem již snad desetkrát psal, že v okamžiku, kdy bych musel refaktorizovat již používanou hierarchii, tak že může být jiné řešení výhodnější. Tak to napíšu po jedenácté a snad už Vám to konečně dojde.

---

btw. když už jsme tedy u toho, co udělat, když mám opravit chybu v rozhraní, tak jestli se nepletu, tak ani DirectX (přiznám se, že zrovna DX moc neznám, v jiných knihovnách to tak funguje) nedělá to, že by mělo pro jednu samou věc více rozhraní. Ano, existuje rozhraní ve verzi 7, které je jiné než ve verzi 8. Ale tam se předpokládá, že se bude používat pouze v8 a v7 je čistě pro zachování zpětné kompatibility. Tzn. nejsou to dvě plnohodnotná rozhraní, ale jedno z nich je deprecated, existuje jen proto, aby staré aplikace fungovaly. Rozhodně však není dobrý nápad ta stará rozhraní implementovat v nových aplikacích.
Druhá možnnost (často používaná ve WinApi) je existence dvou rozhraní, jednoduchého a složitého (funkce Něco a NěcoEx). Tady ale nejde ve skutečnosti o shodné rozhraní, jedno poskytuje jiné služby. Kdyby to bylo v objektové hierarchii, tak by to byly pravděpodobně poděděné objekty (NěcoEx od Něco).

854
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 14. 12. 2010, 14:47:40 »
Na to "nejzajímavější" jsem nereagoval, protože za a) o tom jsem od začátku nic netvrdil (debata začala od čistýho návrhu nějakejch rozhraní do RPG, nikoli o jejich úpravě, toto téma do debaty furt zavlékláte vy), zadruhé je to natolik závislé na tom, jaký je to projekt, kolik lidí a jakým způsobem se podílí na vývoji, jak velk jsou potřeba úpravy a čeho všeho se úpravy dotknou atd...., že nelze říci, kterou metodu bych zvolil. Pro pořádek v kódu je vždy nejlepší mít rozhraní čistá, ale člověk musí často dělat kompromisy.

Jinak to StringNode etc... jsem vynechal proto, protože se na to zaprve vztahuje celý předchozí odstavec, zadruhé jsem se chtěl věnovat tomu, co je IMHO důležité a to mi stačilo demonstrovat na televizi, a za třetí jde o rozšíření funkčnosti, naprosto nezávislé na původním účelu objektů (serializovat/deserializovat do/z řetězce můžu i naprosto cokoli a je mi jedno, jestli to je node nebo islámský terorista) tak není důvod, proč pro to nezavést nové rozhraní (nebo ještě lépe použít již existující rozhraní na serializaci), naopak by byla chyba toto rozhraní vázat na nějaké nody. (Navíc by ta rozhraní i mohla být dvě, protože jedna věc je serializace do strojového zápisu a druhá věc serializace do human-readable, ale to je detail).
S původním tématem to tedy nemá v podstatě společného už vůbec nic.

855
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 13. 12. 2010, 16:48:46 »
Ad IScart: Takže to chápu tak, že to uděláte jako

Kód: [Vybrat]
Televize -<Iskart>- Multiplexor  -<Iskart> 
                                 -<Iskart>
                                 -<Iskart>

A jak pak třeba uděláte volbu, který kanál na televizi pustit? To bude řešit ten multiplexor? A když budete chtí přidat HDMI, tak předpokládám musíte měnit definici multiplexoru? Nebo pro každé rozhraní bude mít televize vlastní multiplexor - takže budu muset měnit i samotnou televizi?

Citace
A před něj strčím objekt multiplexeru, kterým to budu přepínat a který zvládne těch rozhraní více klasicky funkcí getRozhraní(int index). Mám pak větší volnost.
Ne, IMHO máte zaděláno na chybu. Je večer, koukáte se na nejnovější epizodu seriálu přes settopbox. Přijde malej klučina, kterej neví nic o tom, že televize má více scartů (tedy že tam je ještě multiplexor) a vezme scart od videa a zapojí ho do televize do volného konektoru (použije rozhraní IScart od ITelevize). No a co udělá televize? Začne mixovat data z multiplexoru s daty ze scartu. Nebo přepne rovnou na to video. ale to by reálná televize neudělala.

Tím, že implementujete rozhraní IScart jak u televize, tak i u multiplexoru prostě není jasné, co se má kam připojovat - tímto řešením jste vytvořil zbytečný zmatek.

----

Já bych to řešil takto: Mám televizi. Ta má nějaké konektory. Z těch tečou do televize různá data, takže interpretace těch dat je v podstatě záležitost "konektorů" (každej má jiné). No, a když jsem to takhle popsal, tak už je návrh jasný:
Kód: [Vybrat]
ITelevize {
public:
   IKonektor getKonektor(typKonektoru, pozice=0)
   //metody pro komunikaci s konektorem
   void prijmiVideoData(IKonektor, data)
   void prijmiAudioData(IKonektor, data)
}

IKonektor {
    bool zapocniPrijem() //konektor začne posílat data televizi
}

IHMDIKonektor extends IKonektor
{
    void prijmiPaket();     
}

IDsubKonektor extends IKonektor
 {
    void prijmiRGB();     
}
 
IScartKonektor extends IKonektor
 {
     void prijmiRGB();     
     void prijmiKompozit();     
    void prijmiAudio();     
 }
nevím, jestli to co teče DSubem je totéž, co teče skatem, pokud jo, pak by ještě mělo být rozhraní IRGBKonektor, z kterého by se podědil jak scart, tak RGB.

No a výhody: pro vytvoření televize s jiným rozhraním nemusím vůbec šahat do televize. Pouze vytvořím a implementuji nové rozhraní pro nový konektor (display port). Do televize musím šahat pouze, pokud televize má umět něco více. Pak ale v podstatě to už není ta stará televize, ale např. televize s teletextem, takže v tu chvíli není nic divného na tom, že musím tu televizi upravit (a pravděpodobně podědit nové rozhraní).

Mohu vytvořit televizi s jedním, třemi scarty,sedmi scarty a vždy bude jasné, co kam zapojit a televize se furt bude chovat tak jak má.

A celý tento podle mne čistý návrh plyne z toho, že se na rozhraní koukám nikoli na komunikační protokol: to bych opravdu měl televizi přiřadit rozhraní IScart, protože telvize s ním komunikuje, ale jako na entity. Takže pokud má televize scart konektor, tak prostě telvize musí poskytnout patřičný objekt, nikoli rozhraní. Z toho vyplývá mé chápání rozdílu mezi třídou a rozhraním: rozhraní říká CO, třída říká JAK.

---

Citace
Bohužel, každého bude zajímat něco jiného.
Ne vždy. A spousta informací bude společných. On už koncept myslivce je zbytečně speciální - správný koncept je IMHO např. vlastník zvířat. Ten poskytuje metody jako jaká mám zvířata apod. Pokud veterinář chce něco speciálního, tak pak vytvořím pro něj nové rozhraní: protože člověk, co k němu chodí je speciální případ člověka, neboť umí speciální dovednost: podat veterináři informace o zdravotním stavu zvířat. Stejnětak člověk cestující přes hranice např, musí umět dát doklady.
Koncept myslivce v podstatě pak zahrnuje těchto x různých schopností. Máte pravdu v tom, že v jedné aplikaci může být potřeba posílat myslivce k veterináři, v jiném nikoli. V tu chvíli opravdu v každém může být pro "myslivce" (naschvál v uvozovkách, protože každý myslivec vlastně označuje něco jiného) jiné rozhraní. To je ale rozdíl proti tomu, když mám v jednom projektu myslivce s jedním psem a v druhém myslivce s více psy. Myslivec s více psy evidentně zahrnuje i myslivce s jedním psem. Ale nemohu vzít myslivce s jedním psem a přidat mu vlastnictví více psů - protože furt ten myslivec bude mít jednoho "privilegovaného" psa navíc.
Mohu samozřejmě jeho metody přepsat tak, aby toho psa navíc integroval do smečky - jenže to mě ve výsledku zabere více práce, než kdybych vzal myslivce bez psa a implementovat v něm metody vlastnictví psů.

Citace
Jak jste přišel na to, že nižší vrstva musí znát všechny protokoly nad ním?
Vy tvrdíte, že rozhraní je komunikační protokol, pomocí které daná entita komunikuje s ostatními objekty. Např. switch v ethernetu příjmá data v protokolu TCP/IP (a posílá je dálú Ergo kladívko, měl by implementovat protokol TCP/IP. To je důsledek vaší definice rozhraní - jako komunikační kanál.

Já tvrdím, že implementovat rozhraní znamená být/mít schopnost. Switch nemá schopnost rozumět protokolu TPC/IP, proto nemá toto rozhraní implementovat.

---

Ad název rozhraní. Doporučil bych Vám připustit, že někdo může mít jiný názor a že jedním slovem (např. rozhraní) může každý označovat trochu jiný pojem. A že pokud ten pojem není pevně přiřazen ke slovu (což v OOP není, jinak by nebyly ty sáhodlouhé debaty, který jazyk je ten jediný správně OOP), že se nedá říci, který význam daného slova je správnější. Takže se prosím smiřte s tím, že chápu pojem rozhraní trochu jinak než vy a místo hádek o termíny se pojďte bavit o tom, který z těch významů je praktičtější a proč.

Co se týče psa a štěkání, tak IMHO slučujete dvě věci. Jedno je schopnost přijmout povel ke štěknutí (k zápisu na disk, k ....). Tomu odpovídá dané rozhraní IStekable s meodou štěkni. Druhá věc je pes ten je zpravidla štěkable, proto by měl implementovat dané rozhraní.
Pak mohu vymyslet koncept psa: řeknu, že pes (rozhraní IPes) je zvíře (extends IZvire), které umí štěkat (extends IStekable). Kodkoli teď může vyrobit (implementovat psa) a může mi ho poslat a já budu vědět, co s ním.

No a pak jsou dvě věci. Někdo umí ovládat psy. Takový člověk by nikdy neřek štěkej robotovy, on to umí se psy. Takže komunikuje s rozhraním IPes. Tento koncept je ale užitečný spíše zřídka. Anebo někdo umí dávat povely ke štěkání: pak umí s rozhraním IŠtěkable a je mu jedno, komu ty povely posílá.... a co protistrana dělá.

Váš pojem rozhraní je pak v podstatě specializace mého: schopnost rozumět konkrétnímu protokolu je vlastnost a jako taková může mít své rozhraní. Až na to, že tím, že si přesněji specifikuji, co je rozhraní, vyloučím špatné návrhy. Např. u televize:
Televize rozumí protokolu scartu? No to přece až tak ne: když scart pustím do HDMI, tak tomu nebude rozumět. Ten kdo rozumí protokolu scartu je pouze ten konektor televize.
A mám s minimem námahy (IMHO hodně dobrý) návrh.

Zatímco ve vašem přístupu televize opravdu komunikuje scartem, takže není nic divného na tom, aby toto rohraní implementovala - v tu chvíli se ale dostáváte do problémů a musíte vymýšlet nějaký multiplexor a stejně to nemusí fungovat - kdokoli může narvat signál do televize přímo.

---
Na zbytek už nebudu reagovat, protože už jsem asi desetkrát psal, že mluvím o tom, jak by se měli aplikace navrhovat od začátku a že pokud je návrh na začátku blbej, tak přepsat ho na dobrej je sice akademicky čisté, ale ne vždy možné či nejlevnější řešení.
 

Stran: 1 ... 55 56 [57] 58 59 ... 68