Co si myslíte o OOP?

[Mirek Prýmek]

Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.

Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

[Reklama]

[JSH]

Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.

Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

Ještě je třeba myslet na další pravidlo :
(T4) Změna zadání rozbordelí jakýkoliv návrh provedený podle jakéhokoliv paradigmatu.

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit. Když to bude nepřehledé už od začátku, tak už to žádná změna nemůže zhoršit.

[operator]

Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.

Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

Zalezi co se snazis modelovat a zda ma byt system flexibilni a rozsiritelny a na jake urovni. I tomu musis prizpusobit navrh. Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.

[Mirek Prýmek]

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.

A proto je to nejčastější způsob!

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.

A úplně ideálně ani třídy ne

[operator]

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.

A proto je to nejčastější způsob!

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.

A úplně ideálně ani třídy ne

Třída je typ.

[Reklama]

[BoneFlute]

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.

A proto je to nejčastější způsob!

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.

A úplně ideálně ani třídy ne

Třída je typ.

V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)

[BoneFlute]

Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.

Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:

(T2) zadaní se vždycky změní, nejpozději do půl roku

a třetím:

(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí

čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):

(OTOOOP) Cokoliv může [v čase analýzy]  dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.

Ještě je třeba myslet na další pravidlo :
(T4) Změna zadání rozbordelí jakýkoliv návrh provedený podle jakéhokoliv paradigmatu.

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit. Když to bude nepřehledé už od začátku, tak už to žádná změna nemůže zhoršit.

Mě teda přijde, ale možná z toho ještě vyrostu, že na něco takového je dobrej kompromis funkcionální programování. Napsat funkci umí každej. Nejde to moc zvrtat. Kruhový závislosti jsem tam taky nějak moc neviděl. A když vznikne nějaký patvar, nebo se posune zadání, tak se prostě staré funkce nechají vyhnít. Zatím my přišlo, že se to dá snáz ukočírovat.

[BoneFlute]

Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.

Hele, a ono to v tom Pythonu vadí? V čem vadí, že ten cukr je děravý? Někdo ti brání vytvořit si vlastní řešení nějakého vzoru pro Python? Třeba takové Mixiny můžeš udělat celkem v pohodě, a nepotřebuješ žádnou dědičnost. Ale možná mi unikla ta tvá pointa.

Taky bych rozlišoval věci, kdy Python ti nabízí jen základní konstrukce pro vytvoření programu (+ ten tebou zavrhovaný cukr). Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota. Myslíš si, že skutečnost, že Python má syntaktický cukr pro vytvoření objektu (přestože je to jen zabalenej dict) nějak škodí? V čem?

[Kit]

Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota.

Dodnes jsem přesvědčen, že gettery a settery nejsou v Javě součástí syntaxe právě proto, aby se nepoužívaly.

[hawran diskuse]

Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota.

Dodnes jsem přesvědčen, že gettery a settery nejsou v Javě součástí syntaxe právě proto, aby se nepoužívaly.

Už jsem se bál, že je snad vůbec nezmíníš.

[Mirek Prýmek]

[Kit]

Já to tušil, že vám udělám radost

[operator]

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.

A proto je to nejčastější způsob!

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.

A úplně ideálně ani třídy ne

Třída je typ.

V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)

Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.

[operator]

Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.

A proto je to nejčastější způsob!

Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.

A úplně ideálně ani třídy ne

Třída je typ.

V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)

Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.

Je na tom postavena zakladni typova kontrola, pouziva to chtej nechtej kazdy:

Kód: [Vybrat]

>>> class A():
...     pass
...
>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> type(a).__name__
'A'
>>> 1 + a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'A'

[BoneFlute]

V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)

Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.

Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.

pouziva to chtej nechtej kazdy:

Zas nepřeháněj. Možná někdo někdy.