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

[Kit]

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.

Však tou další komponentou je user, který je v parametru metody. Přece nebudu psát modelUser.save(user), když to není třeba. Navíc ten model ani neví, co je "User", takže to slovo do názvu ani nepatří.

[Reklama]

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

Však tou další komponentou je user, který je v parametru metody. Přece nebudu psát modelUser.save(user), když to není třeba. Navíc ten model ani neví, co je "User", takže to slovo do názvu ani nepatří.

To, že přemejšlíš jak správně nazvat věci je samozřejmě chválihodné, ale tady řešíš úplně jinej problém. Tou další komponentou k modelu je view a controller/presenter, žádnej User.

[Kit]

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.

Však tou další komponentou je user, který je v parametru metody. Přece nebudu psát modelUser.save(user), když to není třeba. Navíc ten model ani neví, co je "User", takže to slovo do názvu ani nepatří.

To, že přemejšlíš jak správně nazvat věci je samozřejmě chválihodné, ale tady řešíš úplně jinej problém. Tou další komponentou k modelu je view a controller/presenter, žádnej User.

Nene, tohle mám v metodě controlleru. Ve view je něco podobného s opačným směrem toku dat.

[BoneFlute]

Nene, tohle mám v metodě controlleru. Ve view je něco podobného s opačným směrem toku dat.

OK. A proč je tedy model (asi s významem persistence) víc model, než model uživatele? Já bych to pojmenoval:

Kód: [Vybrat]

$persistence->save($entry);
a po ftákách. User a Model je v tomto kontextu maďarština. Používat tu výraz model mi tu nedává smysl právě proto, že se tu neopíráš o ty další dvě komponenty.

[Youda]

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

Ano.
A ucelem tohoto getteru je umoznit cteni atributu a nedovolit jeho zapis (protoze neexistuje setter). Atribut samotny je samozrejme private.
Treba Hibernate entity bean vubec nema settery, jenom getter na steni a dilci privatni atributy odpovidajici sloucum tabulky/view.
Data Hibernate naplni pres reflection API, user muze cist pres gettery a nemuze vlastni entity bean modifikovat.
Teda pokud by hodne chtel, muze taky pres reflection, ale to urcite neudela chybou nebo prehlednutim.

Dalsi duvod pro gettery je jejich funkce jako access api pro externi knihovny.

Treba JSF XHTML stranka pristupuje na backing bean pomoci EL "#{sessionBean.username}", ktery je na ManagedBean "SessionBean" inpmlementovan jako getter/setter
public String getUsername() - (pro boolean hodnoty public boolean isUsername())
public void setUsername(String username)


Spring XML konfigurak - DTTO
JBoss Drools language - DTTO.

---Ten pocit, kdyz v radiu hlasi, ze na D1 jede chlap v protismeru, zatimco v protismeru jedou uplne vsichni

[Reklama]

[Kit]

Nene, tohle mám v metodě controlleru. Ve view je něco podobného s opačným směrem toku dat.

OK. A proč je tedy model (asi s významem persistence) víc model, než model uživatele? Já bych to pojmenoval:

Kód: [Vybrat]

$persistence->save($entry);
a po ftákách. User a Model je v tomto kontextu maďarština. Používat tu výraz model mi tu nedává smysl právě proto, že se tu neopíráš o ty další dvě komponenty.

Však to mám, model uživatele:

Kód: [Vybrat]

$model->save($user);Je to jen rozděleno do dvou slov, aby se to lépe udržovalo a také abych nemusel modifikovat model s každou novou entitou. Ten model je vícevrstvý, což tě možná zmátlo. Zmíněný příkaz je složením dvou vrstev a zavoláním metody. Říká se tomu dependency injection, pokud bys to nevěděl.

Nepoužívám nicneříkající slova "persistence" nebo "entry". Ani by to nevyjadřovalo, co to vlastně dělá, protože model není persistence a user už vůbec není entry.

[Kit]

A ucelem tohoto getteru je umoznit cteni atributu a nedovolit jeho zapis (protoze neexistuje setter). Atribut samotny je samozrejme private.

Daleko jednodušší je udělat ho public read-only. Výsledek je stejný, jen je to jednodušší.

Ovšem ani teno přístup nepoužívám, protože se mi nechce dolovat data z objektu po jednom čísilku. Navíc je to zbytečně drahé.

[BoneFlute]

Nene, tohle mám v metodě controlleru. Ve view je něco podobného s opačným směrem toku dat.

OK. A proč je tedy model (asi s významem persistence) víc model, než model uživatele? Já bych to pojmenoval:

Kód: [Vybrat]

$persistence->save($entry);
a po ftákách. User a Model je v tomto kontextu maďarština. Používat tu výraz model mi tu nedává smysl právě proto, že se tu neopíráš o ty další dvě komponenty.

Však to mám, model uživatele:

Kód: [Vybrat]

$model->save($user);Je to jen rozděleno do dvou slov, aby se to lépe udržovalo a také abych nemusel modifikovat model s každou novou entitou. Ten model je vícevrstvý, což tě možná zmátlo. Zmíněný příkaz je složením dvou vrstev a zavoláním metody. Říká se tomu dependency injection, pokud bys to nevěděl.

Nepoužívám nicneříkající slova "persistence" nebo "entry". Ani by to nevyjadřovalo, co to vlastně dělá, protože model není persistence a user už vůbec není entry.

Aha. Spánembohem.

[Youda]

A ucelem tohoto getteru je umoznit cteni atributu a nedovolit jeho zapis (protoze neexistuje setter). Atribut samotny je samozrejme private.

Daleko jednodušší je udělat ho public read-only. Výsledek je stejný, jen je to jednodušší.

Ovšem ani teno přístup nepoužívám, protože se mi nechce dolovat data z objektu po jednom čísilku. Navíc je to zbytečně drahé.

No a v napr v jazyce Java se public read only atribut implementuje jako privatni/protected atribut s getterem a bez setteru - to je presne to, co popisuju vyse.
Este je tu moznost mit atribut public final, ten ale nejde modifikovat po zkonstruovani objektu.

A kdyz se ti nechce data dolovat z objektu po jednom cisilku, jak se teda dostanes k tomu jednomu cisilku, kdyz ho potrebujes? Ja se priznam, ze to jinak neumim, nez ze prectu hodnotu toho jednoho cisilka.

[Kit]

No a v napr v jazyce Java se public read only atribut implementuje jako privatni/protected atribut s getterem a bez setteru - to je presne to, co popisuju vyse.
Este je tu moznost mit atribut public final, ten ale nejde modifikovat po zkonstruovani objektu.

A kdyz se ti nechce data dolovat z objektu po jednom cisilku, jak se teda dostanes k tomu jednomu cisilku, kdyz ho potrebujes? Ja se priznam, ze to jinak neumim, nez ze prectu hodnotu toho jednoho cisilka.

Měl jsem na mysli ten public final v Javě, který se používá u vzoru Messenger. Vůbec nevadí, že nejde modifikovat.

Data z objektu získávám buď ve formě kolekce, anebo v serializovaném tvaru. Obojí má dobrou podporu v používaných jazycích, tedy nejen v PHP, ale i v Javě.

[Youda]

No a v napr v jazyce Java se public read only atribut implementuje jako privatni/protected atribut s getterem a bez setteru - to je presne to, co popisuju vyse.
Este je tu moznost mit atribut public final, ten ale nejde modifikovat po zkonstruovani objektu.

A kdyz se ti nechce data dolovat z objektu po jednom cisilku, jak se teda dostanes k tomu jednomu cisilku, kdyz ho potrebujes? Ja se priznam, ze to jinak neumim, nez ze prectu hodnotu toho jednoho cisilka.

Měl jsem na mysli ten public final v Javě, který se používá u vzoru Messenger. Vůbec nevadí, že nejde modifikovat.

Data z objektu získávám buď ve formě kolekce, anebo v serializovaném tvaru. Obojí má dobrou podporu v používaných jazycích, tedy nejen v PHP, ale i v Javě.

Rozumim tedy spravne, ze nechces z Java POJO beanu cist atribut getterem, protoze pristup pres getter na fixni adresu primitivniho typu (obdoba pristupu k ceckovemu structu, akorat ze na halde) je prilis drahy a preferujes collections, kde se primitivni typ musi nejprve transformovat na objekt ulozitelny do kolekce, vytvorit kolekci, vlozit do kolekce a pak jej v kolekci vyhledat bud pres Btree napr. v pripade HashMapy, nebo uplne stejnym fixnim accessem do pole objektu v pripace ArrayListu?
Kolik vykonu se hrubym odhadem da timto pristupem usetrit?

[Kit]

Rozumim tedy spravne, ze nechces z Java POJO beanu cist atribut getterem, protoze pristup pres getter na fixni adresu primitivniho typu (obdoba pristupu k ceckovemu structu, akorat ze na halde) je prilis drahy a preferujes collections, kde se primitivni typ musi nejprve transformovat na objekt ulozitelny do kolekce, vytvorit kolekci, vlozit do kolekce a pak jej v kolekci vyhledat bud pres Btree napr. v pripade HashMapy, nebo uplne stejnym fixnim accessem do pole objektu v pripace ArrayListu?
Kolik vykonu se hrubym odhadem da timto pristupem usetrit?

Nepoužívám POJO. Vždycky si uvědomím, co bych následně chtěl udělat s těmi daty získanými getterem a udělám to rovnou v objektu. Třídy mi tak vychází krátké a jednoduché, protože jejich logika je uvnitř. Nemusím tak řešit gettery a settery, protože ty metody mají k atributům plný přístup.

Pokud budu z toho chtít udělat kolekci, udělám to v objektu. Pokud potřebuji třeba JSON, tak tu kolekci jen serializuji (to už dělám vně objektu, protože je to tak v PHP navrženo). Pokud budu chtít string, použiji metodu __toString().

Pokud nepotřebuješ pracovat se všemi atributy objektu společně, tak by neměly být v jednom objektu.

[Ondrej Nemecek]

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.

User a Model je v tomto kontextu maďarština. Používat tu výraz model mi tu nedává smysl právě proto, že se tu neopíráš o ty další dvě komponenty.

Já nevím, mě se zdá název Model pro persistenenci docela běžný. Například v javovských Ebeans dědí entita z Model, nikoli z Persistence (pokud se použije Active Record - ebeans umí data mapper  i active record a uživatel si může vybrat). Lehký java ORM framework ActiveJDBC - taky Model. V PHP je Properl ORM - taky Model.

[.]

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.

Asi by bylo lepší napsat

Kód: [Vybrat]

datastore.save(user)

[Kit]

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

Asi by bylo lepší napsat

Kód: [Vybrat]

datastore.save(user)

Proč zrovna datastore, když má na starosti například i autentizaci, mejlování, logování a další záležitosti?