Jste zastánci OOP programování?

[backup]

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.

ten primer je spatny a nehodny vaseho nicku. Jen nicotny zlomek lidi, kteri maji co docineni s fyzikou a okolnimi obory se zabyva prakticky s kvantovou fyzikou.

Naproti tomu, kazdy, kdo se jen lehce dotkne profesionalniho programovani je konfrontovan s tézí, ze OOP je ta 'prava' cesta  k tomu jak vytvaret spolehlive programy za nizkou cenu.

Kdyz se k diskuzi o OOP sejdou dva diskutujici, tak hned existuji 3 nazory - zrovna tak jako u pravniku. (viz priklad zde s temi psy a myslivci). To neni zadny zaklad pro praktickou cinnost.

[Reklama]

[alefo]

Ak dáte dvom architektom navrhnúť budovu s rovnakým účelom, budú sa ich návrhy bez diskusie zhodovať?

[BLEK.]

Ad to, že by se správně mělo od začátku navrhovat rozhraní myslivce s více psy. Když uvedu analogii, tak si představte, že událost kliknutí myši se v programu popisuje jako souřadnice X, Y, stav tlačítek a změna kolečka. Nojo, jenomže se objevily multitouch mobily, které zpracovávají víc kliknutí a tažení několika prsty současně --- takže prohlásíme, že všechny knihovny pracující s myší jsou špatně a budeme je preventivně navrhovat tak, aby obsahovaly seznam více současných kliknutí? Pak někdo třeba udělá touchscreen, který je současně čtečka otisků prstů a tak místo seznamu s kliknutími budeme jako "kliknutí" předávat bitmapu všech zmáčknutých bodů?

Ono, navrhováním těch rozhraní preventivně (dopředu myslet na to, že myslivec může mít víc psů) taky program dost zprasíme. Např.:
* místo souřadnice kliknutí myši budeme předávat bitmapu zmáčknutých bodů (touchscreen).
* místo ASCII kódu znaku stisknutého na klávesnici budeme předávat seznam současně stisklých kláves --- a ještě --- co kdyby uživatel měl víc klávesnic --- pro jistotu seznam všech klávesnic a ke každé klávesnici seznam stisklých kláves.
* místo kreslení do jednoho okna budeme pro jistotu paralelně kreslit do N oken, které můžou být ještě navíc na různých displayích, co kdyby uživatel chtěl výsledky programu zobrazovat současně na víc plochách.
* místo otevření socketu na internet budeme předpokládat, že program může přistupovat k N nezávislým internetům připojeným k N síťovým kartám.
... atd --- z toho programu vznikne zpatlanina. Další problém je, že tyto extrémní situace nebudou testovány (málo uživatelů má multitouch, víc klávesnic, víc X-serverů, víc internetů...) a tak se to nepodaří odladit. V programu pak bude spousta zbytečných a zabugovaných abstrakcí, což jeho vývoj zpomalí, nezlepší.

Naopak, myslím, že mít více rozhraní je správně. Je lepší mít rozhraní pro myš, které předává souřadnice, stav tlačítek a kolečko, a pak rozhraní pro touchscreen, které předává seznam všech stisklých bodů. S tím, že když program napsaný pro myš běží na touchscreenu, tak použije rozhraní pro myš a akceptuje jenom jedno kliknutí (a ostatní ignoruje), když program napsaný pro touchscreen je ovládán myší, tak dostane pouze jedno kliknutí (myší nelze kliknout na víc bodů současně), a pouze když program napsaný pro touchscreen běží na touchscreenu, tak může dostat seznam všech míst, kam se kliklo. Podobně --- pokud většina programů reaguje na stisk jedné klávesy, a menšina programů (akční hry) chtějí reagovat na stisk víc kláves, tak je rozumné mít jedno rozhraní pro jednu klávesu a druhé rozhraní pro více kláves, a nenutit všechny programy používat rozhraní pro víc kláves.

[Logik]

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

[ondra.novacisko.cz]

Souhlasim s BLEKem. Logiku, zapominas, ze ne vzdy jsou to myslivci, kteri navrhuji rozhrani. Nekdy ho predepisuje druha strana. A ta muze predepsat, ze myslivec ma jednoho psa. A s tim nehnes, je to 3rd part library. A co ted?

[Reklama]

[mon]

ad k teme:
som zastanca oop tam kam patri.
nebudem pisat erp proceduralnym stylom.
nebudem pisat pisat filter na prikazovej riadke pomocou oop.

co sa tyka jazykov, zastavam nazor, cim viac jazyk zjednodusi pracu programatorovi, tym dalej ho posuva od hw. takze kazdy jazyk ma svoje miesto, nie nadarmo na kazdu ulohu je vhodny nastroj.

os v c#? ano da sa, ale bez stipky assembleru a c?
pisat erp v c? aj to sa da, ale to by som radsej dal vypoved
middleware hru? c# no da sa ale nebude to mainstream (sice mozno na novych mobiloch ano), ale zasa ciste c? da sa, ale bez oop to zasa spomali pracu vyvojarom hier

mam rad jazyky, ktore mi toho vela dovolia... php, javascript, python, c++, ked v tom vie clovek robit tak to vyzera prehladne, jednoducho a funguje to efektivne. ale kedze malo zakazuju, vychovavaju vela zlych programatorov.

nemam rad javu, lebo sa uz len nabaluje. ked som videl lamba v jdk7, som bol sklamany. podobne je na tom java class library, ktoru povazujem za zastaralu.
mam rad c# a .net pre ich schopnost dat nieco rychlo dohromady.

nakoniec, dobry navrh je zaklad vsetkeho, ale zasa raz za cas nie je naskodu refaktoring, pripadne zahodit a zacat znova (vid jpa vs entity beans v jave). kratkodobe naklady zvysi, ale dlhodobe znizi. vsetko ma svoju zivostnost...

[BLEK.]

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

Ano.

Když Winapi vzniklo, tak existovaly pouze myši se dvěma souřadnicemi a s jedním, dvěma nebo třemi tlačítky. Nikdo nemohl předpokládat, že vznikne kolečko na myši, trojrozměrná myš nebo "myš" s více ukazateli (multitouch).

Takže při navrhování Winapi jsi měl možnosti:

• Udělat tam podporu pro myš, co existuje (myš s dvěma souřadnicemi a nejvýše třemi tlačítky)
• Udělat tam myš s kolečkem a s více stisknutými body, aby to bylo rozšiřitelné do budoucnosti
• Udělat tam supermyš, která má N souřadnic, N ukazatelů a N tlačítek, N koleček a N přepínačů

Bod 2 je neproveditelný (nejseš jasnovidec a nevíš, jaké typy myší v budoucnu vzniknou a jak moc se rozšíří). A když si máš vybrat mezi body 1 a 3, tak je lepší bod 1, protože se to programuje výrazně jednodušeji.

Ono třeba i to kolečko je do toho Winapi dost hnusně dohackované (mám pocit, že se tam posílá zpráva o scrollování, kterou systém předtím nikdy neposílal a mohl ji generovat pouze scrollbar a některé staré programy se s tím neumí vyrovnat a blbnou), jenomže je to furt lepší, než kdyby tam udělali supermyš podle bodu 3.

Dnes jseš třeba v situaci, kdy není technicky problém napsat do Xserveru a GTK multitouch. Problém je, že nevíš, zda se multitouch rozšíří nebo ne. Nevíš, jestli za 10 let budou mít lidi běžně na stole napodobeninu iPadu a budou ho ovládat doteky více prstů nebo ne. Pokud do rozhraní napíšeš multitouch a on se nerozšíří, je to špatně (zkomplikuješ psaní všech aplikací a výsledek bude žádný). Pokud tam nenapíšeš multitouch a on se rozšíří, je to taky špatně (tvůj systém bude zastaralý a těžko ovladatelný). Tak si vyber.

[backup]

@mon_:  ...pisat erp v c? aj to sa da, ale to by som radsej dal vypoved ...

to je jen problem vaseho omezeneho rozhledu a nepochopeni, k jakym ucelum byla C vyvinuta. Takze jeste jednou:

Jazyk C se nepouziva na psani aplikaci , ale na psani nastroju pro psani aplikaci.

@mon: ...nebudem pisat erp proceduralnym stylom.

proc? Existuji studie, kolikrat rychleji se napise ERP za pomoci OOP nez proceduralne?
Existuji srovnavaci studie, podle kterych je prokazano, ze OOP ERP je levnejsi, stabilnejsi, vykonejsi ... nez ERP procedural?

[mon]

@backup
ja viem ze c nebolo stvorene na pisanie takychto aplikacii, c bolo stvorene pri tvorbe os, je to stale nizkourovnovy jazyk.

k erp, kazde normalne je postavene nad oop, nemusi to byt zrovna klasicke oop ako tu spominate (java) ale moze to byt ako lotus notes (kde objekty su dokumenty a operacie nad nimi).
neviem si predstavit tu rozsiritelnost a spravovatelnost erp systemov alebo inych informacnych systemov, ktore by nemali objekty.

[ondra.novacisko.cz]

@backup
ja viem ze c nebolo stvorene na pisanie takychto aplikacii, c bolo stvorene pri tvorbe os, je to stale nizkourovnovy jazyk.

Programy pro AVR (jednočipy Atmega) píšu v C++

[alefo]

V ERP sa nevyznam, ale ak to zoberieme vseobecne: realita je pripadova studia :-) Keby OP jazyky neboli lacnejsie / efektivnejsie / rychlejsie, nepouzivalo by ich tolko vyvojarov a nebolo by v nich tolko projektov.

Nejde len o paradigmu, ale aj o kombinaciu ,,jazyk + paradigma + nastroje + uciaca krivka + udrzovatelnost".

Ja mam z backupa pocit, ze ma voci OOP strasne predsudky.

[Logik]

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.

[alefo]

No ale WinAPI vznikalo kedy? 198x? To musí byť dizajnér sakra dobrý vizionár, aby vedel predpovedať veci na 20 rokov dopredu. Multitouch je presne prípad, keď v danej chvíli ani Pýthia kombinovaná so Sibylou nemohol predpokladať, že raz sa bude Windows ovládať viacerými prstami. Rovnako ako nemôžeme predpokladať, že raz budeme systémy ovládať, ja neviem mentálne alebo Nintendo Wii spôsobom.

Môže sa tiež stať, že upadnete do overengineering syndrómu, čo je BLEK.ov veselý príklad so supermyšou.

--------------------
Knižnice sú veľmi a naozaj dobrá pripomienka!

[ondra.novacisko.cz]

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

Ono  by možná stačilo se zamyslet nad tím, jak vlastně takové rozhraní vzniká, za jakým účelem. Objekt definovaný pomocí třídy (class) je samozřejmě sám sobě rozhraním a chápu, že myslivec, pokud by měl postihovat všechny své dovednosti by asi měl mít i kontejner psů. Obecně kontejner objektů, které vlastní... protože když bysme to omezily jen na psy, zase se najde nějaký šťoural, který řekne "proč zrovna jen psy?"

Ale rozhraní často vzniká tam, kde jeden objekt chce komunikovat s jiným objektem, aniž by přesně specifikoval, kdo že to má být. Pouze říká, jaké má mít vlastnosti. Rozhraní totiž velice často nedefinuje ten, kdo jej implementuje, ale ten, kdo jej používá a očekává, že jej někdo bude implementovat.

Proto celou dobu tvrdím, že nevíte, co slovo "rozhraní" znamená. Takže pokud mám objekt, který potřebuje komunikovat s něčím, co je zelené, má flintu a psa, a prohlásí to, že je to myslivec, rozhraní máte dané. Stejně tak, pokud objekt potřebuje někoho, kdo umí mlátit kladivem do železa a nazývá to kovářem, tak je rozhraní zase dané. A to i přesto, že rozhraní neřeší třeba kovářovo účetnictví, nebo nákup materiálu.

Kód: [Vybrat]

class IKovar {
public:
  virtual void bouchniDoZeleza(Zelezo z) = 0;
}

Jen si to představte v UIčku. Třída Button definuje rozhraní IButtonAction a ta obsahuje jedinou metodu OnPressed(). A toto rozhraní implementuje třeba formulář, který se tak dozví, že uživatel zmačknou tlačítko. Přitom mohu se zeptat: "Je formulář akcí tlačítka". Odpovíte, že ne. Přesto tohle uspořádání má smysl (a neříkám, že to je jediné řešení, ale občas postačuje). A vidíte, rozhraní definuje druhá strana, ne strana, která jej implementuje.

[Logik]

Jenže pokud budete přistupovat k rozhraním takto, tak pro každou speciální věc budete muset navrhovat nové rozhraní. Jinými slovy, navržená rozhraní nebudou reusabilní.

V podstatě to, co tvrdím je, že rozhraní je tím více reusabilní, čím více odpovídá tomu, co objekt ve skutečnosti je či jaké má objekt ve skutečnosti schopnosti. (viz to rozdělení dvou typů rozhraní níže).
To ale v podstatě znamená, že dobře navržené rozhraní není jen komunikační protokol, ale vypovídá o vlastnostech samotného objektu.

Problém, na který narážíte s kovářem je ten, že dvě aplikace budou chápat pojem kovář jinak, pro jednoho je to ten, co kupuje železo, pro druhého je to ten, co do něj buší. To jsou ve skutečnosti ale dvě naprosto nesouvisející rozhraní. Tady se opravdu shoduje pouze slovo (identifikátor) a nikoli pojem.
Pokud by ale byly dvě aplikace, které obě potřebují bušiče do železa, tak doufám souhlasíte, že je ideálním stavem, když se podaří navrhnout rozhraní kováře tak, aby obě používali to samé.

----

Když bych to parafrázoval ještě z jiné strany: když si chci s někým porozumět, tak mi nestačí vědět, jaká používá slova, ale co ty jeho slova opravdu znamenají. Tzn. nestačí mi vědět, že mluví anglicky, ale musím znát jeho osobnost.
Pokud rozhraní specifikuje pouze komunikační protokol, tak znám pouze jazyk, takže nevím, jestli to co řeknu urazí, nebo poctí. Když znám i osobnost člověka, se kterým se bavím, tak se mi to nestane. Proto tvrdím, že rozhraní by mělo s sebou nést nikoli jen to, jak daný člověk mluví, ale i kdo je.


-----

Ad IButtonAction je rozhraní, které podle mne zhruba říká: objekt nesoucí toto rozhraní může přijmout pokyn k akci. V tu chvíli mu vyhoví jak tlačítko, tak i formulář. A sem v pohodě :-). Jelikož existuje spousta objektů, které v sobě inherentně obsahují možnost reagovat právě na jednu akci, tak je to rozhraní dobře navrženo. (Narozdíl od myslivce, kdy žádný myslivec v sobě inherentně neobsahuje vlastnost mít právě jednoho psa).