Příspěvky

856

Server / Re: Jaký load je na web serveru ideální?

« kdy: 12. 12. 2010, 11:42:57 »

Hezké shrnutí, ale jestli se nepletu, tak jsi zapoměl na jeden detail - více jader. Pokud mám čtyři běžící procesy a čtyři jádra, tak každej běží na jednom a nečeká nikdo, ne? Takže load averadge musí být větší ne než 1, ale než počet jader, ne? (+ popř. u hyperthreadingu nejlépe 1/2 jader). Nebo se pletu?

857

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 12. 12. 2010, 11:22:01 »

Já mám neblahé tušení, že nevíte co rozhraní je. Zvlášť po tom, co se ptáte, kterého myslivce máte poslat na lov. To je jako kdyby jste se ptal, u televize, která má dva video vstupy, kompozitní a SCART, kterým vstupem připojíte video?

No a já mám zas dojem, že to nevíte Vy. Vy byste opravdu udělal Televize implements IScart?
K tomu není co dodat, jen, že v okažiku, kdy dostanete televizi se dvěma scarty, tak jste... no víte kde. Schválně: hoďte sem příklad kódu televize implementující rozhraní IScart tak, aby podporovala dva Scarty. A aby šla co nejrychleji a s co nejméně modifikacemi rozšířit o další konektor (ať už SCART nebo s novým rozhraním HDMI). Až to uděláte, dam sem své řešení já (už ho mám v hlavě) a můžeme porovnávat.

U úředníka kontrolujícího psy můžete mít také vlastní rozhraní. Je to rozhraní, kterým komunikuje úředník s myslivcem.

A tomu říkáte reusability? Pro každou blbost vytvořit nové rozhraní? Reusability imho znamená také to, že navrhuji rozhraní tak, aby ho mohli používat pokudmožno všichni. Tzn. když někdo chce vědět, jakého mám psa(y), tak ať už je to veterinář, úředník nebo ras, tak použije to jedno stejné rozhraní.

Rozhraní není objekt, je to komunikační protokol.

Nesouhlasím, ale o tom jsme si psali. Že to je blbina jde ukázat třeba na TCP/IP. Copak je TCP/IP (komunikační protokol po ethernetu) rozhraním ethernetu? Jedním z největších vynálezů v síťování bylo oddělení vrstev s tím, že vyšší vrstva nezáleží na nižší.
S Vaším přístupem by ale nižší vrstva (ethernet) musí znát všechny protokoly, které po něm poběží.

Já tvrdím, že rozhraní je v podstatě popis objektu, říká čím objekt je (Myslivec) popř. co umí. Takže ethernet umí posílat pakety na danou MAC, tak bude mít metodu pošli paket. Jaký komunikační protokol nad tím vystavím je ethernetu naprosto šumák - to neni jeho věc.

A pak jsem pochopil, že Vás trápí název rozhraní. Ale název je jen idenitifikace a nemusí mít
význam...

No, mě trápí to, že rozhraní Myslivec ve skutečnosti nepopisuje myslivce, ale jeho velmi speciální případ. Takže není znovupoužitelný, protože málokdy budu potřebovat takový speciální případ myslivce.
Podtrhuje to i to, že navrhujete, ať ho tedy nepojmenuju myslivec, ale AASDSDSDS. Samozřejmě, v jednom programu bych takový název zkousnul. Ale vy byste takové rozhraní použil v jiném projektu?
Jméno jako takové je pouze identifikátor. Ale jedním z programátorských pravidel je: Co mohu jednoduše popsat tak, že každý dle názvu pozná, o co jde, je správně napsané. A čím jednodušeji to jde popsat, tím je to napsané lépe. (A pokud možno, název objektu/rozhraní by měl shrnovat tento popis do jednoho "multiSlova" popř. "multi_slova" - pak je v podstatě půl dokumentace hotové).

V podstatě to znamená, že čím se mi podaří problém rozložit na jednoduší samostatné entity, tím bývá design programu lepší (samozřejmě s mírou). A ještě významnější důsledek: čím jsou tyto entity obecnější, tím je design programu lepší.
I proto je myslivec je lépe napsaný než myslivec s jedním psem a rozhodně mnohem lépe než myslivec co chodí k úředníkovi, myslivec, co chodí k veterináři atd...

Občas se stane, že během vývoje rozhraní svůj název přestane dokonale vyplňovat.

Pokud se toto stane, pak je IMHO chyba v designu. Pokud mám rozhraní IMyslivecSePsem a najednou potřebuji myslivce s více psy a rozhraní předělám, neodpovídá název. A o čem to svědčí? Že při analýze jsem chybně myslel, že stačí jeden pes.
Dokonce bych řekl, že to bývá jedna z velmi častých chyb při programování - pokud rozhraní A nevyhovuje, protože na daném místě vlastně očekávám B, tak místo abych nadefinoval B a použil ho, ohnu A. Pak o pár dní později zjistím, že jsem ohnul A a tak mi nevyhovuje zas tady, a tak se ho snažím ohnout zpátky - a vznikne paskvil.

Pozor, to je jiný případ než s myslivcem: myslivec s jedním psem i s více psy je furt myslivec, tady nejde o ohnutí, ale opravu. Pokud ale někde chci příjmat smečku a v současné době tam příjmám psa, je velká chyba (byť někdy z důvodu nemožnosti modifikace zbytku kódu nejmenší zlo) ohnout rozhraní Pes. Správné řešení je nadefinovat nové rozhraní Smečka.

858

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 12. 12. 2010, 10:44:25 »

No proste si predstav, ze delka vstupu v tomto pripade je umerna poctu objednanych ks.

Ano, pokud by byla, tak by to platilo. Ale vstup by byl velmi neefektivní. Když se baví lidé o algoritmu bez zadaného vstupu, bere se za samozřejmé, že je vstup optimální.

Stejnětak bych mohl tvrdit, že POC není NP, protože můžu vzít jeho vstup, doplnit 2^N bytama redundance a kontrolních součtů a mám z toho polynomiální algoritmus.

Na rozdil od obchodniho cestujiciho. U ktereho pro 100 zastavek...

Ano, ale tam musí být každá zastávka ve vstupu jako samostatnej kus dat se vzdálenostma od ostatních. Nejde napsat vyřeš POC, který má sto zastávek. To je právě ten rozdíl.

Coz se presne shoduje s definici NP.

Neshoduje. Prosím, přečti si definici NP. Tam je složitost prostě definovaná tak jak je. Nemá smysl se bavit o NP, když nevíš, jak je definovaná.

859

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 10. 12. 2010, 17:24:11 »

Vraťme se, k začátku diskuse. Tam já jsem tvrdil, že jeden konkrétní navržený interface je dobře, protože je velmi špatně rozšiřitelný. A když ho budu chtít rozšířit. Jestli jste to pochopil jako kritiku OOP, tak si to přečtěte ještě jednou, nebyla to kritika OOP, ale kritika využití dědičnosti na místě, kam prostě dědičnost nepatří. To není nic proti OOP, to je naopak pro OOP. A demonstroval jsem, že z určitých důvodů je ten návrh špatně.

Vy jste na to odpověděl, že není špatně, protože to jde "opravit" pomocí nového rozhraní. A já pouze tvrdím, že to sice jde, že to je někdy i nejlepší řešení, ale že bylo špatně, když se to neudělalo pořádně hned.

A abych se nedržell u země, vždycky se dá vyrobit úplně nová hierarchie.

Ano jde. Jde psát program pomocí spousty goto. Jde o to, jak bude takový program čitelný. A rozhodně program s méně univerzálními enterfacy bude čitelnější, než program, kde je pro každou věc nadefinovaný nový interface.
Interface je abstrakce, zobecnění. Pokud tedy pro každou věc nadefinuji nový interface, tak kde je ta abstrakce?

Nebo co komu vadí, když můj myslivec bude mít takovou deklaraci

No vadí tomu spousta věcí. Např. chci objekt na lov. Mám tam poslat IMyslivce,nebo
IMyslivce2?
Chci napsat nové rozhraní na kontrolu všech psů (např. úředníkem). Mám dvě možnosti: První je využít existující rozhraní. Tady ale místo jednoho rozhraní IMajitelZvirat musím kontrolovat rozhraní IMyslivec, IMyslivec2, IKlientVeterinare (a deset dalších).
Navíc, mezi těmi rozhraními není vztah, co když přijde někdo implementující IMyslivec i IKlientVeterinare? Mám kontrolovat objekt pouze skrze jedno z nich, nebo skrze obě? Jak vým, jestli myslivec chodí k veterináři s kočkou, nebo svým mysliveckým psem? Ve výsledku napíšu hromadu zbytečnýho kódu řešící existenci deseti duplicitních rozhraní.

Druhá možnost je napsat nové rozhraní IKontrolovanýClovek. Jenže todle rozhraní nikdo neumí, takže nic nezkontroluji, aniž bych přepsal všechny objekty, které chci kontrolovat - a právě proti tomu brojíte.

No a pak je třetí možnost, že mam v kódu pořádek, IMyslivec byl od začátku poděděnej od IMajitelZvirat, toto rozhraní používá i veterinář a když chci napsat kontrolu úředníkem, opět využiji to samé rozhraní IMajitelZvirat.
Toto řešení je IMHO nejlepší, nejčistší, s nejmenší pravděpodobností výskytu chyb. Také nejvíce odpovídá principu OOP, protože podporuje reusability.

Vy neustále dokazujete, že se umíte vyhnout multi-interfaců

Už jsem tu jednou psal, nevylučuji, že to řešení s dynamic_castem nebude někdy nejlepší možné. Ani nevylučuji, že se mi návrh nepovede a multi-interfacům se nevyhnu. To ale přeci nepovyšuje bastl na standard.

Když chci přejít řeku a vím, že se tam nebudu vracet, stačí mi doprostřed naházet šutry a přeskákat. To ale neznamená, že mohu prohlašovat, že ty naházené kameny jsou most. Je to bastl - i když v dané situaci nejlepší řešení.
Stejně tak když na 1GB harddisku na data udělám 100MB partition, protože si blbě přečtu velikost - tak pak může být nejlepším řešením udělat ze zbylého místa druhou partition (např. proto, že data nemám kam odzálohovat). To ale přeci neznamená, že by to měl být standardní postup, nebo že řešení se dvěma partition je nejlepší.

co když místo čísel budem sčítat matice, nebo rovnice?

Právě proto existují určité zásady, jak navrhovat rozhraní - aby se minimalizovala práce při rozšiřování funkčnosti programu. A podle těchto zásad jdou rozhraní posuzovat. Ano, je možné, že budu mít problém, i když ty zásady dodržím, ale ten problém nebude tak často a bude zpravidla daleko jednodušeji řešitelný.
Jednu z těchto zásad sem postnul Tiger. A jelikož IMyslivec tuto zásadu porušuje, jde toto rozhraní označit jako špatně navržené.

860

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 09. 12. 2010, 18:28:17 »

No původně to mělo bejt třeba takhle:

Kód: [Vybrat]

IPes {};

IMyslivec 
{
   set<IPes> getPsy();
}

Takže pokud budu potřebovat, by vši lidé chodili k veterináři, tak to trochu upravím:

Kód: [Vybrat]

IZvire {};
IPes extends IZvire  {};

IMajitelZvirat 
{
   set<IZvirata> getZvirata();
};

IMyslivec extends  IMajitelZvirat
{
   set<IPes> getPsy();
}

V Izvire zadefinuju potřebné metody (popř. je přesunu z IPes). Ve všech psech a myslívcích budu muset sice nadefinovat potřebné metody - což jestli je pořádek v kódu neni problém - ale zas budu mt jistotu, že žádný zvíře nebude naočkovaný.

Pokud bych potřeboval očkovat pouze psy, tak je to ještě jednodušší - udělám rozhraní IMajitelPsu, tam přesunu metodu getPsy z myslivce a myslivce z ni podědím. Všechny lidi pak podědím z majitelů psů. Tady ani dokonce nemusím upravovat ani myslivce, ani psa, pouze ostatní lidi, kteří musí být schopní veterinářovi poskytnout své psy...

Je ještě druhá varianta, která může být někdy užitečná - z IMajitelZvirat nepodědím všechny lidi, ale pouze opravdové majitele zvířat. Na hranicích či u veterináře se pak pomocí RTTI se zeptám, zdali je to majitel zvířat.
To je ale úplně jiná situace, než přetypování IMyslivce na IMyslivce2, protože zde dotaz pomocí RTTI v podstatě supluje metodu mamZvirata(). Buď tedy mám zvířata, nebo neimplementuju toto rozhraní - tercium non datur.
Naopak u myslivců, jak bude vypadat veterinář? Ten se zeptá: jseš IMyslivec? Jestli jo, naočkuje jednoho psa. Pak se zeptá jsi IMyslivec2? Jestli jo, naočkuje všechny psy. A jeden dostane pigáro dvakrát. Jinými slovy: u mého přístupu Majitel zvířat je právě ten, kdo implementuje rozhraní IMajitelZvirat. U Tvého řešení to tak neplatí, může implementovat rozhraní IMyslivec1, IMyslivec2, IMyslivec789 atd...

Jinak, to začínající programátor nebylo na Tebe :-)....
u Tebe už je evidentně pozdě :-D :-D (no offense, only joking :-))

861

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 09. 12. 2010, 02:14:45 »

Kdo je v té fázi? Já ne :-) Já bych od začátku udělal myslivce s x psy, celou dobu tvrdím, že už při implementaci IMyslivec se měl udělat s více psy, i když byl aktuálně potřeba jen jeden.

To, že když už to někdo zprasil (neuvědomil si, že psů je možné mít více), tak že to někdy nejde s rozumnými (tzn. odpovídajícími zisku) náklady přepsat nepopírám. Akorát tvrdím, že výsledné řešení bude horší (méně čitelné, s větším rizikem chyb a horším laděním), než kdyby byl IMyslivec navržen pořádně od začátku.

--

Udělání ze psa multipsa IMHO není příliš dobrý nápad  - veterinář ho naočkuje, naočkují se tedy všichni psy. Jenže veterinářovi ubyde jen jedna vakcína. A máme zas problém. Pokud má mít myslivec smečku, může jít o dobré řešení (některé pokyny se dají dát opravdu celé smečce), ale musí být všem jasné, že je to smečka (tak to myslím Tiger myslel), a ne ji maskovat za psa.

--

Tiger: To pravidlo se šálkami se mi líbí, to by se mělo tesat do kamene (a těma kamenama pak mlátit po hlavách začínající programátory) :-)

862

Vývoj / Re: Jste zastánci OOP programování?

« 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.

863

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 08. 12. 2010, 17:00:27 »

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ě.

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á.

864

Bazar / Re: Pomoc s bakalářskou prací

« kdy: 08. 12. 2010, 15:34:15 »

To je ale jeho volba, že si zvolil takové téma.

Jinak ho tady lidi nelynčujou, jen si z něj dělají legraci, na čemž v této situaci opravdu nevidím nic špatného, a pak jeden člověk to oznámil na patřičné katedře, což je imho taky správné, protože max, co mu za to hrozí (a vzhledem k neprokazatelnosti ani to ne) je vyhazov ze školy a pokud ani není schopnej napsat takovou bakalářku, tak si titul nezaslouží.

 Pravděpodobně jediný dopad ale to bude mít takový, že si školitel pořádně pohlídá, jestli tu bakalářku napsal opravdu on, což IMHO také mělo být cílem celé akce.

865

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 08. 12. 2010, 12:26:08 »

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).

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ě.

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ě.

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ů.

866

Server / Re: Jaký load je na web serveru ideální?

« kdy: 07. 12. 2010, 21:16:36 »

No i když je load 15, tak furt jedno jádro nemá co dělat...
Ono v tomdle případě asi víc, než zátěž CPU může bejt limitací bandwidth paměti
a diskový IO.

Jinak zátěž webovýho serveru je (pokud vyloučim chybama vzniklý nenažraný procesy) daná hromadou malejch požadavků, takže bude mít normální rozdělení (samozřejmě ještě závislý na čase, takže dejmetomu zatížení ve špičce bude normální rozdělení). Takže když si zjistíš typickej load a jeho střední hodnotu, tak můžeš snadno odhadnout, v kolika procentech času bude "nestíhat" (proložíš si tím normální rozhdělení a tam kde přeteče kapacit serveru, tam nestíhá.

867

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 07. 12. 2010, 17:03:30 »

Jo, dá se to říct i jadrnějc :-) plnej souhlas, tendle aspekt jsem nezmínil.

868

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 07. 12. 2010, 15:03:51 »

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.

869

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 07. 12. 2010, 14:20:31 »

Jak je definovaná složitost jinde je pooměrně irelevantní - pokud se bavíme o NP úplnosti, tak prostě musíme brát složitost tak, jak je definovaná v NP úplnosti.

Jinak problém téí naivní definice je v tom, že to není deinice. Ono podle toho bys moh tvrdit, že složitost je lineární - jde vyjádřit lineární závislostí na počtu nutných prohození prvků aby to bylo setříděné.
Jednoduše řečeno, jiný relevantní údaj než délka vstupu, který bybyl společný pro všechny algoritmy nemáš.

Btw. Složitost bublesortu je i podle definice v NP úplnosti O(n^2), protože délka vstupu je úměrná počtu prvků.

Co jsi chtěl vyjádřit tím vblakem už vůbec nechápu, zaprve výpočet a převoz zboží je jaksi něco jiného, zadruhé pokud bych připustil nějakou analogii, tak na vstupu algoritmu převez
n balíků nemůže být počet balíků, ale ty samotné balíky, takže ne log n prvků, ale n prvků.

Pokud bych měl počet těch balíků, tak jediné co mohu převést je zas jen ten počet balík. A ten jde vyjádřit opravdu v log n bitů, takže pokud bych uměl zabalit jeden bit do jedné krabice, tak bych opravdu musel převést pouze log n krabic.

870

Vývoj / Re: Jste zastánci OOP programování?

« 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....