OOP jazyk - problém klasického stříhu

[BoneFlute]

Z podobných důvodů si mnozí oblíbili FP a nemám jim to za zlé. Struktury pro data používají také a říkají jim monády.

Ne, tomu fakt monády neříkáme. Struktury pro data používáme, a říkáme tomu struktury.

Pouštíš se na tenkej led :-P

[Reklama]

[BoneFlute]

Opravdu mě jenom zajímá, co je špatně na tom save().

Vytknul bych tomu dvě věci:
1/ To, čemu patří nějaká metoda by mělo dávat nějak významově logiku. Je logické aby bylo Máslo.cut() ale třeba Máslo.vložSeDoLedničky() mi přijde divné.
Podobně, objekt uživatele má spousta vlastností. Například může mět práva někam přistupovat. Ale nepřijde mi čitelné, aby sám od sebe uměl vzniknout, nebo se uložit. Tak ještě serialize a unserialize - potud ok, ale něco komplexnějšího?
2/ Má-li objekt User metodu save(), tak lze celkem dobře předpokládat, že je to nějaký side-effekt. Což mě samo o sobě děsí. Když uložím toho uživatele, kam se mi uloží? Mohu to nějak ovlivnit? Třeba nějakým globální přepínačem?! Nebo setterem, kterým přepíšu to úložiště? A co když ho chci uložit na dvě místa? Co když budu chtít před ukládáním udělat nějakou validaci? A jen někdy. A po uložení třeba poslat mail? Taky jen někdy. Nebo různé maily v různých situacích.

Suma sumárum - metoda User.save() má jednu jedinou výhodu - je to krátké a stručné. Jinak mám zkušenost (viz víš), že v případě komplexnějšího systému se to celé zašmodrchává. Ne, že by to nešlo, ale je to děsně nečitelné ve smyslu:

Kód: [Vybrat]

if ACL.check(user):
    user.setPersistence(adminUserPersistence)
    user.save()
    user.setMailer(adminUserMailer)
    user.send()
else:
    user.setPersistence(guestUserPersistence)
    user.save()
    user.setMailer(guestUserMailer)
    user.send()
    user.setMailer(adminUserMailer)
    user.setMailerContent(adminUserMail.txt)
    user.send()
A jakmile je to nečitelné, tak pak jaksi padá ta jediná výhoda.

[Kit]

(Teoreticky by mohlo, ale docela by mě zajímalo, zda o tom víš, nebo máš jen zažranou svou představu o vztahu getter a interní atribut.)

Tuto zažranou představu má hlavně většina tvůrců aplikací, které jsem kdy viděl. Existují i světlé výjimky, ale gettery bývají zpravidla jen "return this.atribut".

[Kit]

Suma sumárum - metoda User.save() má jednu jedinou výhodu - je to krátké a stručné.

A co bys řekl na metodu model.save(user)? Tohle se mi docela osvědčilo.

[BoneFlute]

Suma sumárum - metoda User.save() má jednu jedinou výhodu - je to krátké a stručné.

A co bys řekl na metodu model.save(user)? Tohle se mi docela osvědčilo.

Jedinou výhradu bych měl k tomu názvu model (zrovna u tebe!). I user je model.

Ale jinak ano, takto to dělám a mám s tím dobré zkušenosti.

user reprezentuje objekt uživatele. model reprezentuje objekt nějakého procesu. Třeba zaregistrování uživatele do systému.

[Reklama]

[BoneFlute]

(Teoreticky by mohlo, ale docela by mě zajímalo, zda o tom víš, nebo máš jen zažranou svou představu o vztahu getter a interní atribut.)

Tuto zažranou představu má hlavně většina tvůrců aplikací, které jsem kdy viděl.

Takovej je život.

... ale gettery bývají zpravidla jen "return this.atribut".

Což nemusí být špatně. Existuje celá kategorie objektů, u kterých je to zcela korektní a naopak, udělat to jinak by bylo chybou.

[Kit]

A co bys řekl na metodu model.save(user)? Tohle se mi docela osvědčilo.

Jedinou výhradu bych měl k tomu názvu model (zrovna u tebe!). I user je model.

Ale jinak ano, takto to dělám a mám s tím dobré zkušenosti.

user reprezentuje objekt uživatele. model reprezentuje objekt nějakého procesu. Třeba zaregistrování uživatele do systému.

V tom modelu není jen user, ale spravuje všechny datové zdroje včetně databází. User je komponentou toho modelu.

[Anonym]

Držet se Kitovského pravidla, že getter je špatný, znamená, domyšleno do důsledku, programovat hodně inzenzivně pure OOP. A podle mě je pure OOP pěkná pitomost, která vede k problémům. Můj závěr je takový, že pure OOP třídu udělám až v momentě, kdy potřebuju zabalit nějakou funkcionalitu, která pure OOP vůbec být nemusí. Něco co je pěkně v jednom pytlíčku jako je třeba HashTable. Když potřebuju udělat pěkný pytlíček funkcí s daty, udělám to čistě OOP.

[dustin]

A proč to nazývat nekonkrétním slovem "model"? Všechno je model...

[Kiwi]

Držet se Kitovského pravidla, že getter je špatný, znamená, domyšleno do důsledku, programovat hodně inzenzivně pure OOP. A podle mě je pure OOP pěkná pitomost, která vede k problémům. Můj závěr je takový, že pure OOP třídu udělám až v momentě, kdy potřebuju zabalit nějakou funkcionalitu, která pure OOP vůbec být nemusí. Něco co je pěkně v jednom pytlíčku jako je třeba HashTable. Když potřebuju udělat pěkný pytlíček funkcí s daty, udělám to čistě OOP.

A to "nečisté" OOP by mělo vypadat zhruba jak?

[Onestone]

Držet se Kitovského pravidla, že getter je špatný, znamená, domyšleno do důsledku, programovat hodně inzenzivně pure OOP. A podle mě je pure OOP pěkná pitomost, která vede k problémům. Můj závěr je takový, že pure OOP třídu udělám až v momentě, kdy potřebuju zabalit nějakou funkcionalitu, která pure OOP vůbec být nemusí. Něco co je pěkně v jednom pytlíčku jako je třeba HashTable. Když potřebuju udělat pěkný pytlíček funkcí s daty, udělám to čistě OOP.

Pure OOP není pitomost, když ho člověk plně chápe a umí používat.

[BoneFlute]

A proč to nazývat nekonkrétním slovem "model"? Všechno je model...

Tak nějak.

Nazývat něco Modelem má smysl jen v kontextu k dalším dvoum (třem) komponentám. Samo o sobě nikoliv.

[Anonym]

Držet se Kitovského pravidla, že getter je špatný, znamená, domyšleno do důsledku, programovat hodně inzenzivně pure OOP. A podle mě je pure OOP pěkná pitomost, která vede k problémům. Můj závěr je takový, že pure OOP třídu udělám až v momentě, kdy potřebuju zabalit nějakou funkcionalitu, která pure OOP vůbec být nemusí. Něco co je pěkně v jednom pytlíčku jako je třeba HashTable. Když potřebuju udělat pěkný pytlíček funkcí s daty, udělám to čistě OOP.

A to "nečisté" OOP by mělo vypadat zhruba jak?

Tak, aby se to Kitovi nelíbilo 

[BoneFlute]

V tom modelu není jen user, ale spravuje všechny datové zdroje včetně databází. User je komponentou toho modelu.

V takovém případě pro to je zažité jiné názvosloví (persistence, context, ...). Každopádně to jak to popisuješ se mi nelíbí. A jak tě znám, tak dále to s tebou nebudu řešit.

[Kit]

A proč to nazývat nekonkrétním slovem "model"? Všechno je model...

Jak je mám tedy obecně nazvat? Nevím, který model v té proměnné v danou chvíli bude.