Jste zastánci OOP programování?

[ondra.novacisko.cz]

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.

Čistota kódu je věc velice subjektivní. Zatímco ekonomické hledisko je věc objektivní. Proto posuzuju čistotu kódu z hlediska ekonomického. Jako měřítko používám čas vyžadující údržbu, nebo znovupoužitelnost kódu. Což může zahrnovat i psaní dokumentace, která může tento potřebný čast výrazně zkrátit. Čistý kód tedy nemusí být superčistý, ideálně podle všech norem a doporučení, ale měl by být dobře zdokumentovaný, minimálně aspoň na úrovni popisu jednotlivých prvků rozhraní. A hlavně jeho údržba či znovupoužitelnost by neměla stát vyrazně víc času. Rozhodně výrazně méně,  než čas nutný k reimplementaci na zelené louce

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

Nejen, že to je levnější, ale také dává možnost napsat to jinak, nebo lépe. Nehledě na to, že se to psát nemusí víckrát, klidně si ty firmy nebo oddělení mohou šířit jednu knihovnu, kterou používají.

Tohle je otázka, co má obsahovat operační systém? Filesystem? Správu paměti? Správu displaye? Správu jinýho HW. Má obsahovat taky knihovnu pro databázi? Patří to tam? Argument, že stejně většina programů používá MySQL nebo MS SQL, takže by měla být přirozenou součástí OS... cítíte, že je tam něco špatně? Proč proboha ovladač myši by měl mít tu výsadu, že by měl být standardní, pro všechny druhy ovládání?

Každý balíček doinstalovaný do počítače může přinášet nové rozhraní. Kdo tvrdí, že by aplikace musela používat pro vstup myši WinAPI. Když dost výrobců myší začne používat jiné rozhraní, může i naše aplikace používat toto nové rozhraní nezávisle na OS. Konečně, ve Windows existují dvě rozhraní pro myší vstup. Jedno je realizováno přes WinAPI a druhé realizuje DirectInput. To proto, že WinAPI rozhraní neumí některé vlastnosti, jako sledovat akceleraci, nebo relativní pohyb. Valná většina aplikací to totiž nepotřebuje, tak proč by to mělo WinAPI podporovat. A je to také hezký příklad právě na můj argument, že kolikrát je lepší místo přepisování existujícího rozhraní, napsat rozhraní nové. Vždyť vás existence DirectInput nijak neomezuje v používání WinAPI. A ti, kdo rozhraní používají (tedy plní jej daty)? Opět, buď budou data posílat do obou rozhraní, nebo jen do jednoho a nechají systém emulovat to druhé. Jako s tím myslivcem co má jednoho psa a co má víc psů. Myslivec implementuje obě rozhraní, a uživatel rozhraní nechť si vybere, které mu vyhovuje. A nebo myslivec může implementovat jen jedno rozhraní a druhé rozhraní nechat emulovat.

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?

Tohle jsem chtěl použít jako protiargument. Nestabilitu samozřejmě ovladače způsobují. Viz moje trápení třeba s ovladači ma Wifinu RT2500. Neexistenci jednotného rozhraní v jádře způsobuje, že s každou verzí jádra se musí všechny ovladače přeložit. Pak chápu neochotu výrobců HW dodávat ovladače v linuxu. Jednak musí otevřít zdrojový kód a jednak ho musí neustále udržovat, jak se mění jádro.

Kdyby jádro v linuxu bylo napsáno v C++, pak by byla rozhraní jednoznačně identifikována, přesně definována a jakákoliv změna v rozhraních by se realizovala definicí nového rozhraní a zařízením emulace na staré rozhraní. Staré ovladače by byly binárně kompatibilní a emulace by umonžnila běh starých ovladačů, a přitom by neustálá pomalost emulací dál nutila výrobce používat pro nové ovladače nová rozhraní.

[Reklama]

[Logik]

Pokud jediné kritérium, podle kterého budete kvalitu měřit, je zisk v době uvedení na trh, tak bude nejlepší naprosto nedokumentovaný kód napsaný jedním vývojářem někde v garáži. Ten se totiž napíše nejrychleji a tedy nejlevněji. Kupodivu takový kód považují všichni za špatný.
Pokud ho chcete posuzovat podle zisků, které přinese v budoucnu, tak pokud nemáte křišťálovou kouli, tak je to úplně stejně vágní kritérium, jako čistota kódu (už proto, že tato kritéria jsou zcela jasně korelované).
Ona ta "výhleová ekonomická výhodnost" kódu je poměrně složené kritérium: zahrnuje čas na napsání, čas na zaučení nového vývojáře pro úpravu kódu, reusabilitu atd... Pokud umíte od pohledu všechna tato kritéria odhalit najednou, asi jste machr. Noirmální člověk zhodnotí jednotlivá částečná kritéria a udělá syntézu. Proto tvrdím, že se bavit o čistotě kódu má smysl (byť jak celou dobu tvrdím, to není jediné a tedy absolutní kritérium).

---

Pokud si jednu knihovnu budou půjčovat různá oddělení, tak o co jiného jde, než definici standardního rozhraní?
A kde tvrdím, že ovladač pro myš by měl být společný pro všechny druhy ovládání? Já tvrdím, že ovladač pro myš by měl být společný pro všechny myši v tom smyslu, že kterákoli myš, když ji zapojím do počítače, má aplikacím vysílatstejné zprávy a chovat se konzistentně.
Ad databáze - ten příměr je mimo z mnoha důvodů. Zaprve různé databáze nejsou různá rozhraní, ale různé implementace. O unifikaci rozhraní různých databází se výrobci evidentně snaží, proč jinak by schvalovali standardy SQL? Další věc je, že databáze není služba, kterou by měl poskytovat OS. Pokud by byla, mělo by být jedno API, jenže to tak prsotě není. Jednotná služba je např. filesystém, přístup ke konfiguraci atd... A tady jde jednoduše ukázat, že filesystémy maj všude jednotné api, i když implementací v linuxu je mraky - a nikdo nenapíše filesystém, který by byl nekompatibilní. Naopak konfigurace ve windows je vcelku jednotná (registry) zatímco v linuxu každý pes jiná ves. Nechci hájit registry, maj dost much, ale samotná myšlenka jednotného ukládání konfigurace linuxu velmi schází.

---

Ad linux: ale přeci to, že jsou v linuxu ovladače se považuje za velké plus linuxu. Strčím placku a funguje to.
Problém linuxu není v tom, že má v sobě ovbladače. Problém linuxu je v jeho naprosto nemodulárním jádře, které se musí kvůli každé blbině překompilovat.

Problém linuxu není v tom, že není v C++. Takto by to šlo napsat i v C (byť o něco pracněji). Problém je v tom, že kdyby tam bylo x verzí rozhraní pro každou blbost, tak by jádro místo jednoho volání vždy muselo dělat x emulací a výkon by šel do kopru. Zrovna v linuxovíém jádře je to, že stará rozhraní nenechají dožít, ale odstraňují je pokud možno hned, pochopitelné.

[Logik]

A todle si nechám na samostatnej post, protože je to důležitý :-)
Obrovskej rozdíl mezi WINAPI + DirectInput kontra onepes a multies je v tom, KDO POŽADUJE ZJEDNODUŠENÍ.
U myši 99% aplikací chce pouze vědět, kam se kliklo. Proto se udělalo jednodušší rozhraní pro myš. Původcem zjednodušení je tedy typický klient.

Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.

Pokud zjednodušuji na žádost klientů, tak server umí poskytovat i komplexní služby, není tedy problém mít od začátku dvě rozhraní (jednodušší a komplexní), popř. v horším případě to komplexní dopsat. Nemohu se přitom dopustit chyby, kompilátor vychytá, u kterých všech objektů je nové rozhraní potřeba doimplementovat.

Pokud ale zjednodušuji kvůli serveru, tak v okamžiku, kdy chci vytvořit plnohodnotný server, musím opravit všechny klioše, používající zjednodušené rozhraní. Ale TADY MI NIKDO NEPOVÍ, kteří to všechny jsou. S velkou pravděpodobností se dopustím chyby.

PS: A klientů je velmi často hodně: např. krásně to jde ukázat na myši. Čeho je více? Typů myší, nebo aplikací myš používajících? Nebo čeho je více? Typů soubor (soubor, socket, nějaký bitový device apod.), nebo aplikací starajících se o soubory? Existuje více databází, nebo více uživatelů databází.


PPS: Navíc ten příklad jen podporuje mojí teorii, protože se věci poněkud změnili :-).
DirectInput je deprecated, místo něho se má pro myš použít RAW Input, komunikující standardně pomocí windowsích zpráv. Z pohledu WINAPI jde v podstatě o rozšíření původního rozhraní o jednu zprávu - metodu.
Proč tedy microsoft ustoupil od definování nového rozhraní a místo toho rozšířil staré rozhraní, když je to tak špatně???

Nebo jsi možná myslel DirectInput rozhraní pro herní ovladače? I to je deprecated a místo toho je XInput. A kupodivu to je nedoporučené používat pro myši a podobné zařízení. Proč? No protože myš není herní ovladač. Opět to potvrzuje to, co jsem tvrdil. Pro věci stejné povahy má být jedno rozhraní, a naopak věci různé povahy implementovat stejné rozhraní  nemají.

[ondra.novacisko.cz]

A todle si nechám na samostatnej post, protože je to důležitý :-)
Obrovskej rozdíl mezi WINAPI + DirectInput kontra onepes a multies je v tom, KDO POŽADUJE ZJEDNODUŠENÍ.
U myši 99% aplikací chce pouze vědět, kam se kliklo. Proto se udělalo jednodušší rozhraní pro myš. Původcem zjednodušení je tedy typický klient.

Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.

Jediný klíčový problém je ten, že to byl špatný příklad. Měl ilustrovat řešení v situaci, kdy je třeba změnit rozhraní z jednoho psa na multipsa. Vy jste se pustil do kritiky programátora, který navrhl onepsa.

A neuvažujete ani o tom, že programátor se rozhodl třeba na základě krátkodobého ekonomického výhledu, protože předpokládal nějaký ekonomický zisk (ekonomický zisk mohl být třeba i časový zisk, měl to prostě rychleji napsané). Že následně jeho odhad byl velice pohodnocený (knihovnu myslivce může použít v dalších projektech bez větší námahy, ušetří mu to spoustu času), to už je jiná věc. Pořád by se ale vyplatilo navrhnout další rozhraní, než vynaložit obrovské (časové) náklady na přepis všech míst, kde se původní rozhraní používá.

Konečně, sám jsem si to nedávno vyzkoušel po tom, co jsem v rozhraní obecného pole přejmenoval funkci size() na funkci length(). Uvést produkt do kompilovatelného stavu mi trvalo víkend a ani teď nemohu říct, že je to všude opravené. Mám projekty, které rozhodně nebude možné přeložit, ale ještě jsem se k nim nedostal.

[ondra.novacisko.cz]

Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.

To je nějaký renons ne? Nějaká ujetá úvaha. Serverem nazývám ten kdo má implements, zatímco klientem ten kdo volá metody. Jak jste došel k závěru, že původcem je server (tedy ten kdo implements). Kdo vyžaduje víc psů? Ten kdo to implementuje? Tomu je to jedno, ten musí implementovat tolik rozhraní, kolik potřebuje, aby mohl v systému existovat. Klienti, tedy kusy programu, které volají metody rozhraní typicky od těch metod něco očekávají. Pokud vznikne potřeba mít rozhraní s větším množstvím psů, pak ta potřeba vychází od klientů, ne od serveru!

Zapomeňte už konečně na koncepsi "IS-A". To je pomůcka pro začátečníky, když se učí poprvé dědit. Do OOP ale nepatří. Praxe vás asi ještě nenaučila, že "implements" není dědění, takže implementovat rozhraní myslivce s jedním psem a zároveň rozhraní s vícero psy nelze číst jako že myslivec má jednoho i víc psů dohromady. Nejde to prostě tady aplikovat.

[Reklama]

[BLEK.]

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.

Z hlediska uživatelské přítulnosti GUI je nejhorší, když se sleze spousta návrhářů a začne říkat "já bych do toho dialogu ještě přidal to...", "a já bych tam ještě přidal tamto...", "a já jsem ještě dostal tento nápad, to tam musíme dát...". Pak máš v GUI spoustu nekonzistentních myšlenek a uživatel se v tom nevyzná.

Když máš víc programů na ovládání, sice odlišných, ale každý se svou vlastní vnitřní konzistencí, je to pro uživatele lepší. Prostě si vybere jeden, který má funkce co potřebuje, a ten se naučí a používá.

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

Nejde jen o to, že je to levnější. Jde o to, že ty (ani Bill Gates, ani Steve Ballmer...) nemůžeš z pozice autority určit, který způsob nastavování myši a klávesnice je pro uživatele nejlepší. Prostě to nevíš. Když ti někdo řekne "já mám tento nápad, to uživatelům pomůže", tak nejseš schopen určit, zda je to blbost nebo geniální myšlenka. Proto je nejlepší dát uživatelům svobodu vybrat si ovládání jaké chtějí a nevnucovat jim je autoritativně.

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

Používám Linux a nestabilitu to způsobuje - OpenSuse mi kdysi spadlo hned po instalaci kvůli ovladači grafické karty. A na starém notebooku mi po upgradu kernelu nefunguje něco s pravděpodobností 1/4. (z 12 kernelů od Linuse byly tři rozbité - APM, swapování na FAT a PCMCIA).

Myslím, že ty sjednocené ovladače jsou jedna z nejhorších chyb Linuxu, která přispěla k jeho nepoužitelnosti na desktopu. Příklad: předevčírem jsi nainstaloval ovladač do Widlí, včera ti to spadlo. I BFU bez jakékoli technické znalosti je schopno určit, že to asi spadlo kvůli tomu ovladači, dokáže vlézt do nouzového režimu, ovladač odinstalovat, a může zkusit jinou verzi ovladače nebo jiné zařízení. Naproti tomu na Linuxu, nainstaluješ celý systém naráz se všemi ovladači, PRÁSK! spadne to, nemáš sebemenší potuchy proč (leda, že bys měl sériovou konzoli a uměl dekódovat stacktrace což BFU nemá a neumí).

Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?

Když dopředu nevíš, jaká všechna nastavení klávesnice/myši budou potřeba, tak je těžko to navrhovat modulárně. To je pak opravdu nejlepší říct, že "modul" je "sys" soubor, který vybírá zprávy odněkud a posílá je někam a "exe" soubor, který mu nastavuje parametry.

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

K té klávesnici pro blondýny dodávají speciální ovladač na aktivaci těch klávesových zkratek a možná ještě něco. Nemusíš ho instalovat, a pak se to chová jako obyčejná USB klávesnice.

[Bone Flute X]

K původní otázce:
Ano - většinou.

Důvody jsou syntaktický cukr, typová kontrola, zapouzdření, dekompozice.

První dva důvody jsou jasné. Snad jen k té typové kontrole. Interface (v jazycích jako je Java) jsou hodně šikovné. A používám je právě pro rozšíření typové kontroly. Prostě svážu, co kam smí.

Zapouzdření netuším, jak může být řešeno v procedurálního programování. Ve funkcionálním se možná dají použít uzávěry, ale tomu nerozumím tak dobře.

Hodně mi vyhovuje dekompozice problému na malé logické celky, které si pečlivě navrhnu, rozdělím úlohy, a otestuju. Pak komponuju jednotlivé vztahy objektů, a ty objekty, které jsou špatné, tak přepisuju, nebo vyhodím. Domnívám se, že pokud se problém takto nerozdělí, nelze OOP dobře používat a jen se bastlí. Někde jsem četl, že když má třída více, jak dejme tomu deset metod, je moc velká. Postupem času s tímto tvrzením začínám souhlasit.

OOP považuji za metodiku. Podle mne nemá moc s realitou co společného, ale dá se u ní velice dobře uplatnit logiku. Je to prostě filozofie jak bojovat s entropií.

[Inkvizitor]

Zapouzdření se v FP (např. v Haskellu) dá udělat pomocí modulů.

[JS]

První dva důvody jsou jasné. Snad jen k té typové kontrole. Interface (v jazycích jako je Java) jsou hodně šikovné. A používám je právě pro rozšíření typové kontroly. Prostě svážu, co kam smí.

Zapouzdření netuším, jak může být řešeno v procedurálního programování. Ve funkcionálním se možná dají použít uzávěry, ale tomu nerozumím tak dobře.

Hodně mi vyhovuje dekompozice problému na malé logické celky, které si pečlivě navrhnu, rozdělím úlohy, a otestuju. Pak komponuju jednotlivé vztahy objektů, a ty objekty, které jsou špatné, tak přepisuju, nebo vyhodím. Domnívám se, že pokud se problém takto nerozdělí, nelze OOP dobře používat a jen se bastlí. Někde jsem četl, že když má třída více, jak dejme tomu deset metod, je moc velká. Postupem času s tímto tvrzením začínám souhlasit.

OOP považuji za metodiku. Podle mne nemá moc s realitou co společného, ale dá se u ní velice dobře uplatnit logiku. Je to prostě filozofie jak bojovat s entropií.

Zvlastni. Vsechno, co popisujete, muzete delat i v proceduralnim programovani, a kdyz vidim nektere OOP vynalezy, prijde mi to i snazsi. Vzdyt uznejte sam:

1. Interfacy - kdyz nepouzivate dedicnost, je to k nicemu (tim nechci rict, ze je dedicnost neuzitecna, akorat ze bez ni to OOP jaksi postrada smysl). Ve staticky typovanem jazyce program, ktery narusuje interface, vetsinou stejne nezkompilujete a dynamicky typovanemu na typove kontrole nezalezi. A kazda sranda neco stoji. Podle me je typova kontrola diminishing returns, ale to je jen nazor (pro ktery mam dobre duvody na delsi rozpravu).

2. Na zapouzdreni mate modularni system, ve vetsine lepsich jazyku.

3. Na dekompozici problemu se pouzivaji funkce nebo procedury. Proc si lamat hlavu tim, ktera patri do ktere tridy, kdyz jsou ty tridy stejne jen umelym delenim? Pokud v tom chcete mit poradek, je lepsi vhodna jmenna konvence.

Na nektere typy problemu (GUI) je OOP super (vsude tam, kde se hodne dedi). Ale cpat ho vsude? A tvrdit, ze je to v boji s entropii nejaky pokrok?

[Bone Flute X]

Ale vždyť já netvrdil, že se to v proceduralnim programovani nedá.

1. No, jenže já dědičnost umím využít. Interface používám právě proto, že mi to překladač nedovolí přeložit. Takže to zkuste napsat znova a lépe.
Nebo uveďte příklad, jak by jste v procedurálním programování implementoval obecné rozhraní ICommand, k němu blíže neurčený počet implementací. Přičemž mám továrnu (ta může být funkce), která generuje příkazy, ty se někde sockují, a pak se předají další, třeba funkci, která s nich generuje nějaké výsledky. Jde mi o ten Command. Jako určitě bych to zvládl i v neOOP, ale proč si to komplikovat, ne?

2. Znám moduly v VB (očistec) a v pythonu. Určitě to lze použít. Ale to mám na každou jednu třídu/objekt kačenky vytvořit samostatný modul? Myslím, že v tomto je java pohodlná, že umí třeba i privátní třídy v třídách.

3. Na dekompozici problému se používaji metody a třídy. Proc si lámat hlavu tim, která funkce se používá na kterou strukturu, kdyz je mohu svázat k sobě? Dělat to jen jmennou konvencí mi z toho udělá nepořádek a pak je z toho změť podtržítek.

OOP je v boji proti entropii pokrok, jak by jste chtěl dokázat opak? Proč se většina komplexních systémů píše v Javě, přestože je to nenažraná potvora?

[ondra.novacisko.cz]

Zvlastni. Vsechno, co popisujete, muzete delat i v proceduralnim programovani, a kdyz vidim nektere OOP vynalezy, prijde mi to i snazsi. Vzdyt uznejte sam:

Obávám se, že tohle není argument. Všechny současné jazyky jsou turingovsky kompletní, tzn. že všechny jsou schopny používat OOP techniky bez přímé podpory, protože kód z OOP jazyka lze do jejich jazyka převést.

Tady jde asi o něco jiného a souhlasím s původním příspěvkem. OOP techniky pomáhají hlavně při abstrakci daného problému a to jak při návrhu, tak při jeho údržbě. Dobře rozdělují role a zodpovědnost. Pokud nejsme někde schopni o zodpovědnosti rozhodnout, je program navržen špatně. To se mi osvědčilo už několikrát a vždycky to bylo tím, že jsem dával zodpovědnost té části programu (tomu objektu), který ji neměl dostat.

Výsledkem překlad OOP jazyka je neobjektový strojový kód. O tom, jestli k tomu strojovému kódu dojdeme pomocí OOP jazyka, nebo pomocí jiných technik už tady až tak nehraje roli.

[Inkvizitor]

JS, vzhledem k tomu, že autor tématu začal o C++, bylo by asi fajn být konkrétnější. C++ bez OOP je takové lepší Céčko (jmenné prostory, konstanty, reference, šablony funkcí a pár dalších věcí, které toho ale řeší relativně málo).

1. Interfacy - kdyz nepouzivate dedicnost, je to k nicemu (tim nechci rict, ze je dedicnost neuzitecna, akorat ze bez ni to OOP jaksi postrada smysl). Ve staticky typovanem jazyce program, ktery narusuje interface, vetsinou stejne nezkompilujete a dynamicky typovanemu na typove kontrole nezalezi.

Explicitní interface podle mě přinejmenším napomáhá porozumění kódu. Svým způsobem je to důležitější koncept než dědičnost.

2. Na zapouzdreni mate modularni system, ve vetsine lepsich jazyku.

Docela by mě zajímalo (teď nerýpu a ptám se), které procedurální jazyky tohle umějí, pokud vůbec.

3. Na dekompozici problemu se pouzivaji funkce nebo procedury. Proc si lamat hlavu tim, ktera patri do ktere tridy, kdyz jsou ty tridy stejne jen umelym delenim? Pokud v tom chcete mit poradek, je lepsi vhodna jmenna konvence.

Některé objektové jazyky mají výhodu, že není nutné explicitně odkazovat na this/self. To je u ukecaných jazyků typu Java určitá výhoda (samozřejmě to má i temnou stránku), protože to snižuje šum v kódu. Že to lze řeši i jinak, je samozřejmě pravda. Ne ale v Javě a v C++ jenom obecně problematickými prostředky preprocesoru.

[Inkvizitor]

Boneflute, těch kačenek je možné uvnitř jednoho modulu uzavřít tolik, kolik člověk potřebuje (a v té míře, ve které to dává smysl). S pythonovskými moduly bych třeba ty haskellovské nesrovnával, modul v Pythonu zapouzdření řeší jenom malinko (zapouzdření vnitřních funkcí, nikoliv dat).

[Bone Flute X]

Haskel já neznám. Jen jsem zmínil co znám, to samo o sobě je informace :-)

A naopak, Python zapouzdření řeší, no, svým způsobem. Nemá protected, a přístup k private není zakázaný. Jen je namontován prefixem na třídu, a zapodtržítkovaný. Což je imho taky způsob. Jinak mám za to, že private můžou být i prvky balíčků.

Každopádně neřeším to, zda by to šlo, či ne, ale při představě, že bych tu zapouzdřenost řešil balíčkama - jsem rád, že to nemusím dělat.

[Inkvizitor]

No, mně nešlo o to, zda lze mít prvky balíčků privátní, nebo ne (__all__ a jeho důsledky), ale o to, že Python na rozdíl od Haskellu neumí exportovat typ tak, aby do něj nebylo vidět (v Haskellu se to dělá exportem typu bez exportu jeho konstruktorů z modulu). Je možné skrýt atributy třídou (do jisté míry, jde to s tím prefixem; každopádně tady už jsme v OOP) nebo implementovat daný typ třeba v C, to ano. V Haskellu existuje ještě další možnost - použít monádu.