Těžké OOP problémy

[Zdeněk Vais]

Dobrý den,
rád bych se zeptal, jestli jste se setkali s nějakým obtížným nebo tricky problémem z OOP. Například nějaký design, který není zrovna intuitivní, nebo se v něm snadno dá udělat chyba apod.

Děkuji.

[Reklama]

[Daniel Novotný]

Nejvíc frustrující pro mě bylo, když jsem přišel ke kódu, kde programátoři prostě bezmyšlenkovitě (nebo s minimem myšlení) vršili OOP abstrakce na sebe, protože "prostě mohli", slepě používali dědičnost protože "takhle se to prostě dělá" a prase aby se v tom potom vyznalo.

[Idris]

jestli jste se setkali s nějakým obtížným nebo tricky problémem z OOP

Dědičnost je obecně “tricky,” páč se zneužívá ke sdílení kódu apod. Praxe ukazuje, že nadmíru užitečné jsou “defaultní” metody v rozhraních, obtížné to asi není, ale rozhodně neintuitivní.

[Kit]

Obecným problémem bývá nadužívání dědičnosti, nevhodné užití návrhových vzorů, chybně provedená injekce závislostí, třídy, které toho umí příliš mnoho a nic pořádně, nadužívání přístupových metod k atributům, příliš mnoho atributů, chybná dekompozice. Kde je nějaký atribut "protected", tam jsou problémy.

[Zdeněk Vais]

Možná jsem měl blíže specifikovat otázku. Nejde mi o obecné problémy s OOP, ty jsou známé ... ale spíš ukázku toho něčeho, pro co je těžké navhrnout objektovou strukturu správně, a nebo jak se postupnými logickými kroky a přidáváním funkcionality, dostaneme někam, kam nechceme a podobně.

[Reklama]

[Kit]

Podívej se na zásady SOLID. Všechny jsou porušovány naprosto běžně. Stačí si tedy každé pravidlo znegovat a dostaneš nejčastější problémy.

[Zdeněk Vais]

Podívej se na zásady SOLID. Všechny jsou porušovány naprosto běžně. Stačí si tedy každé pravidlo znegovat a dostaneš nejčastější problémy.

Ano, GRASP i SOLID znám. A porušení těchto pouček nehledám. Co mě zajímá je příklad něčeho, kde samotné třídy mohou splňovat SOLID, ale celkový design je špatně. Chtěl bych konkétní příklad něčeho, co se těžko navrhuje, a nebo tam snadno dojde k nějakému problému. Jak dorazím domů, sám se pokusím vytvořit nějaký takový příklad.

[Johnny]

A co třeba impedanční nesoulad relačního modelu a objektů? Ale to je spíš problém relačních databází než OOP...

[listoper]

No myslim, ze budes napred muset definovat co je to OOP, protoze uz tu bylo nekolik diskuzi kde bylo videt, ze o tom ma kazdy trochu jinou predstavu.

Pokud mluvime o mainstream OOP (Java a podobne) tak podle me:
1. persistence
2. UI
3. Cokoli co ma horizontalne skalovat

[kimec]

Dobrý den,
rád bych se zeptal, jestli jste se setkali s nějakým obtížným nebo tricky problémem z OOP. Například nějaký design, který není zrovna intuitivní, nebo se v něm snadno dá udělat chyba apod.

Děkuji.

Jasne, staci si zobrat zakladnu vec ako OOP v kombinacii s viac vlaknovym programovanim.

Ako zarucit, ze predmetny OOP kod neporusuje formalny Memory Model jazyka a neobsahuje data races, t.j. ze je data race free?

Potazmo ako zvolit dostatocnu a zaroven najlacnejsiu formu synchronizacie pri danom OOP navrhu (pamatove bariery vs. CAS vs. mutex)? Ako zabezpecit a preverit, ze predmetny navrh pouziva danu synchronizaciu spravne?

[Ondřej Surý]

Jasne, staci si zobrat zakladnu vec ako OOP v kombinacii s viac vlaknovym programovanim.

Ako zarucit, ze predmetny OOP kod neporusuje formalny Memory Model jazyka a neobsahuje data races, t.j. ze je data race free?

Potazmo ako zvolit dostatocnu a zaroven najlacnejsiu formu synchronizacie pri danom OOP navrhu (pamatove bariery vs. CAS vs. mutex)? Ako zabezpecit a preverit, ze predmetny navrh pouziva danu synchronizaciu spravne?

Ale tak to zase není limitováno na OOP, a setkáte se s tím i při programování např. v čistém C.  Naopak v C++ to mnohdy může být jednodušší kvůli věcem jako shared_ptr, které dělá reference counting za vás.  (Ale nejsem C++ programátor, tak netuším, jestli v tom není nějaká zrada...)

[oss]

Nic take nejestvuje, kedze tu mame teoriu vypocitelnosti.
vsteko co vies namodelovat cez FP vies namodelovat aj cez OOP, su to len dva pohlady na to istu vec.

[Jiří Havel]

Ale tak to zase není limitováno na OOP, a setkáte se s tím i při programování např. v čistém C.  Naopak v C++ to mnohdy může být jednodušší kvůli věcem jako shared_ptr, které dělá reference counting za vás.  (Ale nejsem C++ programátor, tak netuším, jestli v tom není nějaká zrada...)

shared_ptr ve více vláknech není úplně intuitivní pro někoho, kdo neví do detailů jak to uvnitř funguje. Z nějakého důvodu dost lidí předpokládá, že je ten ukazatel atomický a pak se škaredě spálí. Vlákna jsou holt zlo.

[Zdeněk Vais]

Nic take nejestvuje, kedze tu mame teoriu vypocitelnosti.
vsteko co vies namodelovat cez FP vies namodelovat aj cez OOP, su to len dva pohlady na to istu vec.

No já jsem myslel spíš nějaký konkrétní modelovací problém. Na co jsem například narazil nedávno bylo postupné přidávání funkcionality tímto způsobem:

1) Máme uživatelská data (řekněme nějakou třídu nebo více tříd)
2) Potřebujeme z nich udělat commandy, které budou vykonány ve správném pořadí - k tomu vytvoříme Scheduler (nebo chcete-li Factory)
3) Commandy bude spouštět Executor, který zároveň zpracovává výjmky a informuje o progressu
4) Potřebujeme přidat odhady, jak dlouho daný proces bude trvat a kolik času zbývá, když už to běží - přidá se řekněme nějaký Estimator
5) Chceme uživateli měnit uživatelská data v průběhu běhu commandu, což má vliv na exekuci i time estimaty

V podstatě to není zas tak těžký úkol, ale na co jsem narazil je, že postupným přidáváním této funkcionality, ač třídy jakš-takš splňovali např. SOLID, tak tam vznikly vazby všechno se vším - zárodek Ball of mud.

Jiným příkladem může být například rozsáhlý systém, který staví model pro Marketing, Sales, Ordering a Support. Všechny tyto oddělení pracují se zákazníkem, ale není žádané, aby tato třída byla v systému pouze jednou, protože bude obsahovat příliš odlišnou funkcionalitu, bude mít příliš závislostí, bude mít tendenci růst apod.

[gill]

Na rootu vycházel seriál o frontách úloh.