Jste zastánci OOP programování?

[mon]

je to c++ ale nie je to oop, na to by si potreboval daku zakladnu spravu pamate implementovat (na op new)

[Reklama]

[ondra.novacisko.cz]

A co ta proměnná je, když ne objekt? A proč musí v OOP objekt vznikat dynamicky alokací na haldě? Proč třeba ne na zásobníku?

[hxn]

V C by určitě šlo podobného výsledku (ač nevím, co všechno váš EventManager implementuje) dosáhnout pár makry, ale dobrá, jde li pouze o syntaktický cukr, beru to - nějak jsem čekal, že budete používat virtuální metody, dědičnost apod. :-)

[Logik]

Já začal diskuzi tím, že někdo argumentoval, že nevýhoda rozhraní je ta, že když se změní, musí se pak změnit všechny objekty, které to rozhraní používají. Což je pravda, ale ne vždy je nutné to řešit změnou rozhraní.

Pokud chci, aby všechny objekty, které používali staré rozhraní, šly použít na místě, kde potřebuji nové rozhraní, tak ať už to vyřeším novým rozhraním, nebo updatem starého, do těch všech objektů prostě šáhnout musím. Srovnávalo se řešení, kdy navrhnu rozhraní od začátku tak, aby vyhovělo úpravám a tomu, kdy nikoli.

Definice nového rozhraní oproti modifikaci starého sice řeší to, že nemusím upravovat jiné klienty, pořád ale musím upravovat všechny servery a navíc mám dvě rozhraní řešící stejnou věc (a jelikož obě používám ke stejné věci, většina objektů bude muset implementovat obě).

třeba k tomu je důvod. Nevíte, jen vaříte z vody.

Pokud je k tomu důvod, pak už dané zařízení není čistě multitouch - protože má důvod prioritizovat nějaký klik. Prostě buď tam ten důvod je, pak to rozhraní ale je onetouch (protože umí určit prioritní klik), nebo ten důvod nemá a pak nemá co implementovat onetouch.

(ad CAPS/RTTI souhlasím - u emulátoru se musí nějak vyřešit, aby ex-multitouch umící z něčeho poznat primární dotek nebylo zbytečně emulováno. To však není ve sporu s mým tvrzení, že onetouch by mělo implementovat pouze to zařízení, které opravdu je schopno samo poznat, který klik je primární).

Co rozhodne? Zdali umí poznat prioritní dotek? No pokud neznám schopnosti zařízení, těžko pro něj mohu navrhovat vyhovující rozhraní. A pokud je znám, tak rozhodují schopnosti toho zařízení.

Bohužel tohle vždycky narazí na křivku zvyšujících se nákladů. Zvýšení kvality produktu o jeden stupeň generuje dvojnásobné náklady. V jednom okamžiku jsou náklady tak vysoké, že další zvyšování kvality je ve finále dražší, než všechny náklady, které to ušetří v budoucnu. Tady je třeba ctít ekonomiku. Prostě nelze vyrobit dokonalé rozhraní, protože v konečném důsledku bude jeho používání dražší, než nějaké primitivnější a mnohem levnější řešení.

Takže již se mnou souhlasíte, že je to řešení lepší, akorát někdy může být neúměrně drahé? To je dobrý posun. :-)

No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně
(pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa.

[ondra.novacisko.cz]

Pokud chci, aby všechny objekty, které používali staré rozhraní, šly použít na místě, kde potřebuji nové rozhraní, tak ať už to vyřeším novým rozhraním, nebo updatem starého, do těch všech objektů prostě šáhnout musím.

Nové rozhraní se vytváří většinou proto, aby se nemuselo zasahovat do věcí, které už fungují.

Definice nového rozhraní oproti modifikaci starého sice řeší to, že nemusím upravovat jiné klienty, pořád ale musím upravovat všechny servery a navíc mám dvě rozhraní řešící stejnou věc (a jelikož obě používám ke stejné věci, většina objektů bude muset implementovat obě).

Ono jde o to, co tu změnu iniciovalo. Například to, že jeden jediný klient (objekt, který rozhraní používá) požaduje novou funkcionalitu, kterou servery (objekty, které rozhraní implementují) zkrze staré nemohou implemenetovat. V tom případě s novým rozhraním vzniká zároveň i emulátor, který se snaží "nějak" novou funkcionalitu emulovat zkrze staré rozhraní, nebo nová funkcionalita prostě není k dispozici vůbec (multitouch může zkrze onetouch rozhraní emulovat starou funkcionalitu - onetouch myš). Tady se vám mění jen jeden klient.

Kód: [Vybrat]

Jako příklad uvedu rozhraní, které chci obohatit o funkci toString(). Klient, který chce
objekty tisknout se jich bude ptát, zda existuje rozhraní s funkcí toString(). Pokud existuje,
provede ji, pokud ne, emuluje ji například tak, že to převede na řetězec
"Unknown object:"+typeid(obj).name()

Po změně rozhraní sice bude existovat kvantum objektů, které se nebudou umět vytisknout,
ale časem takových objektů bude ubývat, jak bude zbývat čas tuto funkcionalitu
dodefinovávat. Projekt to ale nezastaví, nikoho to neblokuje, změna tedy nemusí být tak
drahá.

Z výše uvedeného dále vyplývá i výhoda, že nové rozhraní není povinné ve všech projektech. Některé projekty třeba nepotřebují objekty tisknout a tak nové rozhraní ani nebou používat, mohou používat staré objekty bez nového rozhraní. S novým rozhraním totiž
mohu změnu realizovat další úrovní dědění:

Kód: [Vybrat]

class ObjektSeStarymRozhranim: public IStareRozhrani {...};

class INoveRozhrani {...};

class ObjektSNovymRozhranim: public ObjektSeStarymRozhranim, public INoveRozhrani {};

My odkojení C++ dokonce tohle řešíme šablonou

Kód: [Vybrat]

template<class Base>
class ImplementaceNovehoRozhrani: public Base, public INoveRozhrani {...};

Kde Base je pak nějaký objekt, který implementuje IStareRozhrani. Šablona může definovat všechny funkce nového rozhraní, dokonce může zajistit i výchozí implementaci. Speciality se pak řeší specializačí šablony

Kód: [Vybrat]

template<>
void ImplementaceNovehoRozhrano<ObjektSeStarymRozhranim>::novaFunkce() {...};


Nemáte ani pravdu v tom, že servery musí implementovat obě rozhraní, nebo že rozhraní jsou duplicitní. Nové rozhraní většinou implementuje funkcionalitu, kterou straré rozhraní neumí... takže není duplicitní. Server také nemusí nutně implementovat obě. Může také komplet zahodit staré rozhraní, pokud se neplánuje, že nebude fungovat se starými klienty. V tom je opět svoboda, kdy o tom, co bude server implementovat rozhoduje majitel objektu, který rozhraní implementuje a není závislý na ničem jiném.

Takže již se mnou souhlasíte, že je to řešení lepší, akorát někdy může být neúměrně drahé? To je dobrý posun. :-)

Ani náhodou. To jste špatně pochopil. Lepší řešení nemůže být neúměrné drahé. Neuměrně drahé řešení je v konečném důsledku špatné řešení. Možná jen, když zanedbáme ekonomiku celého návrhu, ... jenže to je krátkozraké. Programátor by se neměl utápět ve svých paradigmatech aniž by se ohlížel na ekonomickou stránku celého vývoje. To je pak špatný programátor.

No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně
(pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa.

Akademická diskuze

[Reklama]

[ondra.novacisko.cz]

V C by určitě šlo podobného výsledku (ač nevím, co všechno váš EventManager implementuje) dosáhnout pár makry, ale dobrá, jde li pouze o syntaktický cukr, beru to - nějak jsem čekal, že budete používat virtuální metody, dědičnost apod. :-)

Dědičnost je taky syntaxtický cukr. Virtuální metody jsou pointry na funkce. To všechno lze na Atmega udělat (i když tedy avr-lib neposkytuje plnohodnotný framework, lze si ho dopsat)

EventManager je pole o N bytů a pole o M longů. N bytů implementuje frontu, M longů implementuje N programovatelných časovačů (čas vypršení). Dalo by se to udělat pomocí struktury a dvou polí, a ano, nakonec makrem. Ale přijde mi to jako zamést bordel pod koberec.

[Logik]

Samozřejmě, když se objektu přidává NOVÁ funkcionalita, má mít nové rozhraní. To jsem tvrdil u metody toString, to jsem tvrdil u onetouch/multitouch (porotože IMHO ani jedno z těch rozhraní není nadstavba druhého, jak jsem ukázal v minulém postu). Ale onepes a multipes není implementace různých služeb, jde o tu samou službu.

V původním příkladu nešlo o novou funkčnost - ta si samozřejmě nové rozhraní zaslouží - ale o zpřesnění staré funkčnosti. Neexistuje myslivec, který má jednoho psa a nemá psy - a každý myslivec, který má psy je myslivec, který má psa. Takže každý myslivec se psy bude chtít být použitelný i tam, kde je použitelný myslivec se psem a vice versa. Takže mezi Vašimi příklady a původním není analogie.

Prostě budu-li chtít implementovat myslivce s x psy, tak ať modifikuju staré rozhraní, nebo udělám nové, tak jestli budu chtít pustit multipsa do systému, musím opravit všechna místa, kde klient zpracovává JEDNOHO mysliveckého psa a ve skutečnosti je chtěl zpracovávat VŠECHNY. Pokud to neudělám, tak program nebude korektní (za hranice budou chodit nenaočkovaní psy, budu vybírat málo poplatků za psí známky atd...) Takže se úpravě klientů nevyhnu.

A co se týče dilematu, jestli změnit staré rozhraní, nebo definovat nové, tak v tomto případě je to v podstatě dilema: přinutí mě kompilátor projít všechna místa, kde se pracuje s mysliveckým psem (což stojí hromadu času), nebo mě nepřinutí a já budu muset nějak přijít, na kterých místech je ta oprava nutná, protože se tam má pracovat se všemi psy a ne s jedním. To samozřejmě záleží na situaci, ale první možnost mi zaručí, že v programu nezůstane (logická) chyba. Druhá nikoli. Tím neříkám, že je ta druhá vždy horší, jen ukazuji, že má i nevýhody.

[ondra.novacisko.cz]

Takže se úpravě klientů nevyhnu.

To je právě to, že vy si pořád myslíte, že je častější případ, kdy uživatelů rozhraní je víc, než těch co jej implementují. Jenže to v praxi velmi často bývá naopak. Uživatel rozhraní je většinou právě jeden a objektů, které rozhraní implementují je mnoho. Viz důvody k polymorfismu. Všichni psy štěkají z jednoho místa, ale může tam přijít libovolné množství různých psů.

Jinak, pokud se přidává nová funkcionalita na rozhraní, uživatelé rozhraní se nemusí nikdy nějak extra upravovat. Ano v případě, kdy jde o přechod z jednoho psa na N psů, pak se to dá řešit formou emulace (například vyzvednu prvního psa) a patřičnou funkci označit jako "deprecated", což je krásně vidět třeba v Javě. Viz přechod z funkcí show() a hide() na funkci setVisibility(). Vsadím se, že funkce show() a hide() fungují i dnes, jen je překladač označí patřičným warningem.

V C++ (ve MSVC) se to dělá pomocí declspec(deprecated)

Váš argument s nenaočkovanými psy je divný. Přece pokud úprava na rozhraní vznikla kvůli očkování, je nesmysl, aby veterinář byl nucen používat staré rozhraní. Psa u myslivce, jehož rozhraní podporuje pouze jednoho psa lze taky naočkovat ne?

[Logik]

Pokud se rozhraní navrhujou dobře, tak je používá víc klientů. Např. To vaše toString lze využít na různých místech v GUI, při logování, při debugování, při generování komentářů do konfiguračních souborů apod...
jinými slovy, psů je sice mnoho, ale také štěkaj všude, kam přijdou. (chudák zajíc :-)).

Ad nenaočkovaní psy a deprecated: malej problém by byl, kdybych měl myslivce, kterej najednou chce jít přes hranice či k veterináři - a tam je třeba řešit všechny psy. Jenže daleko častěji se spíš stane, že mám myslivce, kterej chodí přes hranice i k veterináři, akorát doteď měl jen jednoho psa.
A najednou za mnou přijde zákazník se slovy: "ale my tam máme myslivce, co má dvě dogy." A takovejdle překvápkům se člověk při vývoji nevyhne. 
A v tu chvíli nestačí označit jednu funkci za deprecated (což jinak máte pravdu, že je to jeden z nejrozumnějších konceptů, jak se vyrovnat se změnou rozhraní). Protože musím upravit všechnu funkčnost v klientech, které doteď předpokládali, že jeden myslivcův pes jsou všichni myslivcovi psy.

Jinými slovy. Poku chci najednou posílat myslivce přes hranice, tak je to blíž situaci, kdy implementuju novou funkčnost. Největší problémy jsou ale při změně stávající funkčnosti: (myslivec už dlouho přes hranice chodí, ale teď chce s sebou vzít o psa více...).

[BLEK.]

Logik: "No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně (pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa."

To je abstraktní příklad a není jasné, co je tím "myslivcem" a "psem" vlastně myšleno, tak pak nejde na takovou otázku o kolik se vývoj zdraží odpovědět. Když však uvedu konkrétní příklady --- o kolik zdraží navrhovat aplikaci, aby pracovala s více klávesnicemi současně, zobrazovala na více obrazovek současně nebo aby její síťová vrstva přistupovala k více internetům současně, aby místo přístupu na disk používala abstraktní vrstvu pro více datových úložišť --- pak odpověď je --- prodraží to tu aplikaci hodně, kód provádějící danou "zobecněnou" činnost několikanásobně nakyne.

Logik: Vzhledem k tomu, že drtivá většina zařízení je  onetouch, bylo by nejlepší řešení obě rozhraní, plus ve WINAPI převodní funkce z multi na onetouch. Tím by se zajistila konzistence. V současné době každý multitouch může implementovat onetouch jinak a to vede k zmatení uživatele - jednou to vezme první stisk, jednou všechny..... Navíc každý, kdo implementuje multitouch, tak musí psát sám emulaci onetouch, místo toho, co by byla ve WINAPI napsaná jednou.

To je příliš kategorické uvažování způsobem "tak to má být". Představme si, že do WINAPI dáme funkce na konverzi všech možných vstupních rozhraní na klávecnici a myš, nejen multitouch, ale třeba i volantu na závodní hry, polohového/akceleračního senzoru, podložky na tancování, EEG snímače (ano, i myšlenkami se počítač dá ovládat a při nějaké terapii se to tak dělá) atd. Pak z toho WINAPI nebude krásné sjednocené rozhraní, ale totální bordel zasypaný spoustou technologií s minimálním podílem na trhu.

A co se týče multitouch, rozšíří se natolik, aby mělo cenu kvůli tomu Windows zesložiťovat a dávat do nich obecnou konverzi? To nikdo neví, proto bych nedělal ani takové kategorické soudy, jakože "multitouch má být sjednocen a když si každý výrobce multitouch napíše emulaci myši po svém, tak je to špatně".

V případě, že se multitouch nerozšíří, pak bude naopak správné, aby každý výrobce multitouch zařízení si napsal emulaci myši po svém a nezesložiťoval tím základní systémové knihovny.

[Logik]

o kolik zdraží navrhovat aplikaci, aby pracovala s více klávesnicemi současně...

Ale aplikace ať klidně pracuje s jednou klávesnicí. API OS by mělo být postaveno tak, aby kdyby aplikace chtěla, tak by mohla pracovat s více...
Stejně tak myslivec mže poskytovat více psů a aplikace může pracovat  pouze s prvním psem. Náročnost oproti jednopsu je tady minimální.

ale třeba i volantu na závodní hry, polohového/akceleračního senzoru, podložky na tancování, EEG snímač

no z volantu myš snad udělat nejde, podložku na tancování nikdo jako myš používat nebude. Multitouch displej je od začátku zamýšlen jako něco, co má zároveň emulovat myš. To je trochu rozdíl, ne?

Pak z toho WINAPI nebude krásné sjednocené rozhraní, ale totální bordel zasypaný spoustou technologií s minimálním podílem na trhu.

A co jiného je hromada integrovaných driverů dodávaných s windows nebo ještě lépe do linuxového kernelu? To konverzní rozhraní může bejt modul, kterej se doinstaluje v okmažiku, kdy se naisntaluje první multitouch. Proč by z toho měl být bordel nechápu.

A co se týče multitouch, rozšíří se natolik, aby mělo cenu kvůli tomu Windows zesložiťovat a dávat do nich obecnou konverzi?

Nechápu, co je na tom za zesložitění. Jeden "abstraktní ovladač" bez nějakejch závislostech na ostatních komponentách systému.
Na windows v podstatě skoro každá myš, lepší klávesnice atd... si instaluje vlastní ovládací programy, kterejma se víceméně nastavuje to samý, co v stadardním dialogu plus jedna blbina navíc. To se Ti zdá lepší řešení, než kdyby nastavení těch blbin poskytovali jednotně windowsy?

---

Samozřejmě, že někdy se ekonomicky nevyplatí to řešit vše "správně a maximálně obecně" . To ale nic nemění na tom, že všechna zjednodušená řešení mají své chyby a své limity, na které člověk zpravidla později či (z mých zkušeností spíš) dříve narazí.

Zásadní ale je, že k rozhodnutí, jestli to udělám "systémově správně", nebo to zjednodušším mohu udělat až poté, co vím, jak by to mělo být. Pokud budu obě řešení považovat za "rovnocené", tak nemám důvod, proč volit to složitější řešení. Pouze "uvědomění si" problémů jednoduššího řešení mi umožňuje "svobodně" volit mezi nevýhodami (časová náročnost x rozšiřitelnost).

[korCZis]

Jste zastanci OOP programovani? Zalezi. Je to paradigma, ktere se hodi na reseni urcite, byt pomerne rozsahle, mnoziny problemu. Na neco je vhodne OOP, na neco funcionalni pristup, atp.

OOP je dobre na jistou mnozinu problemu, ale neni to "silver bullet".

http://en.wikipedia.org/wiki/No_Silver_Bullet

Tem kdo necetli, tak doporucuji knihu "The Mythical Man-Month" od autora "Fred Brooks".

[BLEK.]

Logik: Na windows v podstatě skoro každá myš, lepší klávesnice atd... si instaluje vlastní ovládací programy, kterejma se víceméně nastavuje to samý, co v stadardním dialogu plus jedna blbina navíc. To se Ti zdá lepší řešení, než kdyby nastavení těch blbin poskytovali jednotně windowsy?

Ano, je to tak lepší než kdyby každá z těch firem vyrábějících myš/klávesnici přišla za Microsoftem a řekla "hele, my bychom potřebovali do ovládacího panelu přidat tuto položku" a Microsoft jim to tam přidal.

Je lepší, když ten ovládací program napíše každá firma sama, protože: Když ten ovládací program padá, můžeš ho odinstalovat (kdyby bylo ovládání všech možných klávesnic a myší v základním systému, tak to při chybě neodinstaluješ). Když ten ovládací program sežere moc času/peněz na naprogramování a jeho vlastnosti se ukážou jako zbytečné, tak to sežere čas a peníze té firmě co to vyvíjí, ale ne Microsoftu.

BTW. chtěl bys, aby ve standardních Windows byl i ovladač na tohle: http://reidun.files.wordpress.com/2009/05/keyboard-for-blondes2.jpg ?

[D.A. Tiger]

BTW. chtěl bys, aby ve standardních Windows byl i ovladač na tohle: http://reidun.files.wordpress.com/2009/05/keyboard-for-blondes2.jpg ?

To je pěkný  Jestli se dá koupit tak mám pro někoho opožděný dárek k vánocům 

EDIT : Tak dá. Stojí zhruba 1300 Kč (49.95$). No je otázka jestli to za tu legraci stojí...

[Logik]

BLEK.: To co píšeš je ale čistě ekonomické hledisko. Z hlediska čistoty zdrojového kódu i uživatelské přítulnosti GUI  to jednoznačně řešení horší. Čili jak jsem psal: někdy člověk musí slevit z dobrého kódu kvůli ekonomice.

To, že pro microsoft je levnější, když to za něj napíšou jiné firmy je jasné, ale v původním problému, z kterého se diskue vivinula, bych to musel tak jako  tak napsat všechno já (nebo nějakej kolega ze stejný firmy).

(kdyby bylo ovládání všech možných klávesnic a myší v základním systému, tak to při chybě neodinstaluješ).

Ty nepoužíváš linux? Tam jsou v jádře ovladače snad na všechno a že by to způsobovalo nestabilitu....
Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?

A ad klávesnice pro blondýny: to je normální klávesnice a ovladač na ní samozřejmě ve windows je. To ale nic nemění na tom, že kromě ceny nemá chybu :-)