OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Řešení dotazu:
25.2.2015 16:48
rADOn | skóre: 44
| blog: bloK
| Praha
Pokud je atribut privat a je k němu napsán public getter a public setter, v konečném důsledku se ten atribut chová jako public.Je tu jeden rozdil – pokud se neco zmeni a ty chces ten atribut ziskat jinym zpusobem, treba ho spocitat z jinych, vytahnout z cache nebo cokoliv, musis opravit potencialne hodne kodu. Pokud jazyk nema zpusob jak zahakovat cteni/nastavovani atributu, tak je psani get/set metod rozumny zpusob jak byt predem pripraven. Kdyz jsou to "nezavisle veci" tak je to samozrejme zbytecne, ale treba v prikladu ktery uvadis jsou jmeno a prijimeni na sobe zavisle. Takze si bud udelas setter ktery nastavi oboji, nebo udelas dva settery ale opatris je vzajemnym zamykanim… v kazdem pripade budes chtit aby samotny atribut byl private aby ti na nej nikdo nesahal.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
class Car
{
private $VIN,
$color,
$owner;
private function convertColorToRgb($hexColor)
{
/* funkce která zajistí convert */
return $rgb;
}
protected function getData()
{
return array("VIN" => $VIN, "color" => $color, "owner" => $owner);
}
protected function setVIN($vin)
{
$this->VIN = $vin;
}
protected function setColor($color)
{
$this->color = $this->convertColorToRgb($color);
}
protected function setOwner($owner)
{
$this->owner = $owner;
}
}
class CarLoader extends Car
{
public function loadCar($vin)
{
$this->setVIN($vin);
$data = $this->getDatabaseData($vin)
$this->setColor($data['color']);
$this->setOwner($data['owner']);
}
private function getDatabaseData($vin)
{
/* funkce která načte auto z databáze a uloží hodnoty do lokálních proměnných $color a $owner */
return array("color" => $color, "owner" => $owner);
}
}
class CarToXml extends Car
{
public function getXml()
{
$data = $this->getData();
/* funkce která z dat v proměnné $data udělá xml */
$return $xml;
}
}
class Car {
private $vin;
private $color;
private $owner;
private $db;
function __construct($db, $vin) {
$this->db = $db;
$this->vin = $vin;
$data = $this->findCar($vin);
$this->color = self::convertColorToRgb($data['color']);
$this->owner = $data['owner'];
}
private function findCar($vin) {
/* funkce která načte auto z databáze a uloží hodnoty do lokálních proměnných $color a $owner */
return $select->fetch(); //array("color" => $color, "owner" => $owner);
}
private static function convertColorToRgb($hexColor) {
/* funkce která zajistí convert */
return $rgb;
}
function __toString() {
/* funkce která z dat v proměnných $vin, $color a $owner udělá $xml */
return $xml;
}
}
Color, která by sama o sobě zajišťovala konzistentní uložení barvy, tak by klidně Car mohlo mít barvu jako veřejný atribut, pokud nejsou na barvu nějaké další omezující podmínky.convertColorToRgb nemá v třídě Car co pohledávat, vzhledem k tomu, že se stará o konverzi barev. Taky se mi na ní nelíbí, že je statická, ale přitom zamíchaná mezi nestatické.findCar mi tam taky moc nesedí, čekal bych, že bude vracet instanci Car a že bude statická nebo úplně mimo třídu Car.Color::convertToRgb(), protože s třídou Car nesouvisí. Statická metoda přitom mezi nestatickými ničemu nevadí.findCar() si zaslouží přejmenovat na find().Nevidím důvod, proč by barva měla mít vlastní getter/setter. Není potřebný, není to Active Record.Je otázka, k čemu teda vlastně vůbec ta třída informaci o barvě má. Dejme tomu, že budu chtít načíst auto, zobrazit jeho barvu, případně ji změnit a zase ho uložit. Jak to uděláš bez getterů/setterů?
Statická metoda přitom mezi nestatickými ničemu nevadí.No je to otázka stylu. Mně to přijde podobné, jako míchat private a public metody. Technicky vzato to ničemu nevadí, ale přehlednost to opravdu nezvyšuje...
Nevím, tu si vymyslel Mercuriuz. Třeba proto, aby ji prezentoval na webu?Nevidím důvod, proč by barva měla mít vlastní getter/setter. Není potřebný, není to Active Record.Je otázka, k čemu teda vlastně vůbec ta třída informaci o barvě má.
Dejme tomu, že budu chtít načíst auto, zobrazit jeho barvu, případně ji změnit a zase ho uložit. Jak to uděláš bez getterů/setterů?Načtení auta a zobrazení barvy už tady máme. Zápis nové barvy bude v metodě
Color::update()
Je zvykem psát nejprve public a pak privat metody. Hodláš mě buzerovat za to, že jsem tady přehodil pořadí?Statická metoda přitom mezi nestatickými ničemu nevadí.No je to otázka stylu. Mně to přijde podobné, jako míchat private a public metody. Technicky vzato to ničemu nevadí, ale přehlednost to opravdu nezvyšuje...
Načtení auta a zobrazení barvy už tady máme.Jestli tím myslíš to view co dostává záznam z DB, tak to zní jako docela hnus
Zápis nové barvy bude v metodě Color::update()
Což je setter
Je zvykem psát nejprve public a pak privat metody. Hodláš mě buzerovat za to, že jsem tady přehodil pořadí?Ne, to určitě ne, je to detail. Mně je jedno, jaký konvence kdo dodržuje, dokud je to konzistentní a čitelný.
Nevím, jestli se to dá označit jako setter, když to zapisuje do databáze. Setter by přece neměl mít postranní efekty.Zápis nové barvy bude v metoděCož je setterColor::update()
Color IMHO vůbec neměla vědět, je ok
Jinak ale objekty nemusí vůbec být ukládány do databáze, to je v podstatě specielní případ. Takže jak nastavíš tu barvu bez databáze a bez setteru?
Setter by přece neměl mít postranní efekty.BTW i vytvoření objektu je side effect.
Můj view vždy dostane přímý výstup z PDO, do objektu třídy Car se nic neukládá. Tady je to trochu odlišně a zpětně to už předělat nemohu.Načtení auta a zobrazení barvy už tady máme.Jestli tím myslíš to view co dostává záznam z DB, tak to zní jako docela hnus
Car drží jako atribut, je $vin. Nemá ani databázi - tu vždy dostane od modelu.
Mám tu třídu refaktorovat a poslat ji sem znovu?
Třída Car je servisní vrstvou k databázi.To znamená, že ji používáš na co?
Mám tu třídu refaktorovat a poslat ji sem znovu?No jestli to pomůže objsanit, k čemu ta třída je...
class Car implements Insertable, Findable, Updatable, Deletable {
private $data;
function __construct(array $data) {
$this->data = clone (object) $data;
}
function find(PDO $db) {
$select = $db->prepare("SELECT * FROM car WHERE vin=?");
$select->execute(array($this->data->vin));
return $select->fetch(PDO::FETCH_OBJ);
}
/* Podobně i
function insert ...
function update ...
function delete ...
*/
}
Zbytek je práce modelu, view a controlleru.
car - a jméno sloupečku s primárním klíčem (předpokládám) - vin. Jestli neobsahuje žádné vlastní chování, tak je v podstatě zbytečná.
Zbytek je práce modelu, view a controlleru.Takže tam máš ještě nějakou modelovou třídu Car?
Ne, to si dělám srandu, spíš ORM framework to chce...
View o PDO nemá ani potuchy. Jak jsi na to přišel?"View (který mám v jiné třídě) dostane záznam přímo z DB přes messengera" ?
Jak jsi přišel na to, že všechno je propojené se vším? To bych se do svých limitních 65 řádek/třídu nevešel.Takže i ten model má 65 řádek? Moc si neumim představit, jak v 65 řádcích napsat něco užitečnýho aniž by se to muselo rozdělit na bambilion tříd...
K čemu mi bude ORM framework, když mám své domény? Konfigurace ORM je mnohem složitější a hůř udržovatelná.ORM je k tomu, že nemusíš (tolik) řešit databázi v rámci aplikace. Psát hromadu SQL queries pro každej objekt, kterej má bejt persistovanej do DB je zbytečná práce. Náročnost konfigurace ORM záleží na ORM vrstvě, existují i zeroconf ORM (např.).
No a? Jak to souvisí s PDO?View o PDO nemá ani potuchy. Jak jsi na to přišel?"View (který mám v jiné třídě) dostane záznam přímo z DB přes messengera" ?
Když si na to zvykneš, tak už si ani nevzpomeneš na doby, kdy jsi je psal delší.Jak jsi přišel na to, že všechno je propojené se vším? To bych se do svých limitních 65 řádek/třídu nevešel.Takže i ten model má 65 řádek? Moc si neumim představit, jak v 65 řádcích napsat něco užitečnýho aniž by se to muselo rozdělit na bambilion tříd...
Pro každou doménu mám obvykle 1-5 SQL dotazů. To se mi nezdá zas tak moc a dobře se to spravuje. Navíc se mi nechce do modelu tahat nějaké konfigurační parametry pro ORM. Nějak to nakonfigurovat musíš, aby věděl, jaké máš tabulky a sloupce v nich. Můj model nic takového nepotřebuje, struktura databáze ho nezajímá. Všechno deleguje na domény.K čemu mi bude ORM framework, když mám své domény? Konfigurace ORM je mnohem složitější a hůř udržovatelná.ORM je k tomu, že nemusíš (tolik) řešit databázi v rámci aplikace. Psát hromadu SQL queries pro každej objekt, kterej má bejt persistovanej do DB je zbytečná práce. Náročnost konfigurace ORM záleží na ORM vrstvě, existují i zeroconf ORM (např.).
No a? Jak to souvisí s PDO?No jestli jsem to správně pochopil, tak do view posíláš, co vyleze z PDO. Což je přinejmenším zvláštní - na jednu stranu krituješ gettery/settry, že porušují zapouzdření, ale na druhou stranu ti nevadí posílat do view holý data z PDO, který zapouzředný nejsou vůbec nijak.
Když si na to zvykneš, tak už si ani nevzpomeneš na doby, kdy jsi je psal delší.Hlavně nevidim důvod, proč si na to zvykat. Ten tvůj model fakt má <65 řádek?
Pro každou doménu mám obvykle 1-5 SQL dotazů. To se mi nezdá zas tak moc a dobře se to spravuje.Například budeš muset 1-5 dotazů upravit při každé změně dotyčné 'domény', tj. přidání/odebrání položky apod. Což neříkám, že je nějaká tragédie, ale dělat by se mi to stejně nechtělo...
Navíc se mi nechce do modelu tahat nějaké konfigurační parametry pro ORM. Nějak to nakonfigurovat musíš, aby věděl, jaké máš tabulky a sloupce v nich.Jak říkám, záleží to na ORM vrstvě. Některý mají šílenou konfiguraci. Jiný mají konfiguraci, která je IMHO příjemnější než psát N*5 dotazů. Ten zeroconf ORM, co jsem linkoval, skutečně žádnou konfiguraci nemá, protože schéma generuje automaticky z modelových objektů přes reflexi. Takže když přidám atribut do modelové třídy, ORM vrstva automaticky přidá sloupek do příslušné tabulky, a podobně.
Je to messenger, který zapouzdření nepotřebuje a nepotřebuje ani gettery. Výstup z libovolného getteru také nebývá zapouzřený.No a? Jak to souvisí s PDO?No jestli jsem to správně pochopil, tak do view posíláš, co vyleze z PDO. Což je přinejmenším zvláštní - na jednu stranu krituješ gettery/settry, že porušují zapouzdření, ale na druhou stranu ti nevadí posílat do view holý data z PDO, který zapouzředný nejsou vůbec nijak.
36.Když si na to zvykneš, tak už si ani nevzpomeneš na doby, kdy jsi je psal delší.Hlavně nevidim důvod, proč si na to zvykat. Ten tvůj model fakt má <65 řádek?
Totéž bych musel udělat i v případě ORM. Prašť jako bouchni. Obvykle stačí modifikovat pouze ten SQL dotaz a nic víc. Doména se přizpůsobí reflexí.Pro každou doménu mám obvykle 1-5 SQL dotazů. To se mi nezdá zas tak moc a dobře se to spravuje.Například budeš muset 1-5 dotazů upravit při každé změně dotyčné 'domény', tj. přidání/odebrání položky apod. Což neříkám, že je nějaká tragédie, ale dělat by se mi to stejně nechtělo...
To jako to ORM modifikuje strukturu tabulek v databázi? No nazdar. Další důvod pro to nepoužívat ORM. Proč se všichni toho SQL tak bojí, že potřebují ORM?Navíc se mi nechce do modelu tahat nějaké konfigurační parametry pro ORM. Nějak to nakonfigurovat musíš, aby věděl, jaké máš tabulky a sloupce v nich.Jak říkám, záleží to na ORM vrstvě. Některý mají šílenou konfiguraci. Jiný mají konfiguraci, která je IMHO příjemnější než psát N*5 dotazů. Ten zeroconf ORM, co jsem linkoval, skutečně žádnou konfiguraci nemá, protože schéma generuje automaticky z modelových objektů přes reflexi. Takže když přidám atribut do modelové třídy, ORM vrstva automaticky přidá sloupek do příslušné tabulky, a podobně.
Je to messenger, který zapouzdření nepotřebuje a nepotřebuje ani gettery.Já nemluvil o messengeru ale o těch datech, který "messenguje", ty zapouzdřený asi nebudou, jestli to správně chápu. Další věc je, že když ti ty data neprochází přes model, tak nemáš moc možnost je nějak zpracovat/tranformovat/apod...
To jako to ORM modifikuje strukturu tabulek v databázi? No nazdar.Ano, tohle ORM upravuje schéma podle potřeby, v čem je problém?
Proč se všichni toho SQL tak bojí, že potřebují ORM?Nevim jak ostatní, já osobně se SQL nebojím, spíš jde o to, že mě nebaví, vnímám to jako zdržení. Vždyť je to jen způsob, jak uložit data. IMHO méně babrání se s databází = více času pro aplikační logiku. Pro ilustraci třída
Car napsaná pro RedBean ORM:
class Car implements RedBean_SimpleModel {
const table = 'car';
public static function find($vin) {
// Minimalistický SQL snippet:
return R::findOne(self::name, 'vin = ?', array($vin));
}
// CRUD funkce netřeba psát, stačí použít
// R::store($car) pro update, R::trash($car) pro delete apod.
// ...
// zde může být logika modelu Car
// ...
}
Máš zapouzdřená data, která získáš getterem? Asi ne, tak nekritizuj můj messenger. Data prochází přes model, ale nevidím důvod, proč by je měl model jakkoli zpracovat/tranformovat/apod. To není jeho účelem. Má se starat pouze o správu externích datových zdrojů a to dělá.Je to messenger, který zapouzdření nepotřebuje a nepotřebuje ani gettery.Já nemluvil o messengeru ale o těch datech, který "messenguje", ty zapouzdřený asi nebudou, jestli to správně chápu. Další věc je, že když ti ty data neprochází přes model, tak nemáš moc možnost je nějak zpracovat/tranformovat/apod...
Problém je v tom, že zpravidla nechci nebo ani nesmím modifikovat strukturu databáze, protože je na ni napojena další aplikace, kterou bych takovým činem mohl nabořit.To jako to ORM modifikuje strukturu tabulek v databázi? No nazdar.Ano, tohle ORM upravuje schéma podle potřeby, v čem je problém?
Vnímám to přesně obráceně. Proč bych se měl babrat s aplikační logikou v PHP, když mi to udělá databáze jedním dotazem a ještě se přitom sama postará o kolize?Proč se všichni toho SQL tak bojí, že potřebují ORM?Nevim jak ostatní, já osobně se SQL nebojím, spíš jde o to, že mě nebaví, vnímám to jako zdržení. Vždyť je to jen způsob, jak uložit data. IMHO méně babrání se s databází = více času pro aplikační logiku.
Pro ilustraci třídaTo jsme na tom stejně s ORM i bez něj. Navíc ti tam chybí ta databáze, asi ji máš globální. To bych nesnesl.Carnapsaná pro RedBean ORM: To máme nějakých 6 řádek kódu nebo kolik
Tvůj přístup je ale zjevně jiný, soustředíš se hlavně na data v DB spíš než na OOP apod... Tím určitě nechci říct, že to je špatně, jestli ti to vyhovuje, tak prosim, ale není to úplně pozice, ze které by měl někdo vynášet obecné soudy o getterech/setterech a zapouzdření, zejména, když sám zapouzdření moc nepoužíváTam, kde máš dvojici getter+setter, mám plnohodnotnou třídu. Zapouzdření používám i tam, kde ty ho nemáš. Práce s daty v DB je pohodlnější než v PHP. Je také spolehlivější a výkonnější.
Máš zapouzdřená data, která získáš getterem? Asi ne, tak nekritizuj můj messenger.Data získaná getterem typicky zapouzdřená jsou, protože to jsou buď primitivní hodnoty, nebo něco složitějšího, a pak je to zapouzdřeno v objektu nějaké třídy (třeba ta
Color apod.).
Tvůj Messenger jsem nekritizoval, jen jsem napsal, že posílá nezapouzdřená data, to ale nemusí být špatně.
Data prochází přes model, ale nevidím důvod, proč by je měl model jakkoli zpracovat/tranformovat/apod. To není jeho účelem. Má se starat pouze o správu externích datových zdrojů a to dělá.V MVC je model jádro aplikace, obsahuje veškerou aplikační logiku a zpracovávat data je jeho účelem.
Problém je v tom, že zpravidla nechci nebo ani nesmím modifikovat strukturu databáze, protože je na ni napojena další aplikace, kterou bych takovým činem mohl nabořit.Ok, tak to potom jo, ale já jsem tímhle omezen nebyl. Nicméně ten framework umožňuje uzamčení schématu, což v produkčním prostředí je stejně potřeba udělat, protože jinak by šel výkon do kytek. Takže do schméatu nezasahuje, pokud to nedovolíš.
Proč bych se měl babrat s aplikační logikou v PHP, když mi to udělá databáze jedním dotazem a ještě se přitom sama postará o kolize?Protože v SQL máš jen velmi omezené možnosti aplikační logiky. V některých případech to může stačit (to, co popisuješ, vypadá jako dosti tenká vrstva nad DB). V mém případě jsem potřeboval s daty dělat různý věci, vč. třeba grafových operací, SQL by mi nestačilo ani náhodou... Jinak o schopnosti databází (rychlost hledání, detekce kolizí, apod.) pochopitelně nepřijdu ani s ORM, to by jinak nemělo smysl vůbec db používat
To jsme na tom stejně s ORM i bez něj. Navíc ti tam chybí ta databáze, asi ji máš globální. To bych nesnesl.U tebe vidím těch řádků o dost více, zejména pokud by se měly doimplementovat ty ostatní CRUD funkce. Jestli je databáze globální záleží u tohohle ORM podle způsobu použití, v nejjednodušším případně se používá jedna globální DB a statické funkce, je ale možné používat objektové API a/nebo více DB. Ta aplikace, co jsem řešil, používá DB dvě.
Tam, kde máš dvojici getter+setter, mám plnohodnotnou třídu. Zapouzdření používám i tam, kde ty ho nemáš.Zatím jsem v tom tvém návrhu nenašel jediný příklad zapouzdření. Například o té třídě
Car výše se asi těžko dát říct, že data o autě zapouzdřuje, když s těmi daty pracuješ někde jinde úplně mimo rozhraní té třídy Car. Vždyť ta třída ani vlastně pořádně neví, jaký data drží, takže tam o nějakém zapouzdření moc nemůže být řeč...
Znovu připomínám, že to nemusí být nutně špatně, naopak je klidně možné, že to tak je lepší.
V MVC je model jádro aplikace, obsahuje veškerou aplikační logiku a zpracovávat data je jeho účelem.Používám MVCS, ve kterém servisní vrstva (obsluha domén) dělá aplikační logiku a částečně přebírá původní funkci modelu. Pokud by to bylo pro ni moc práce, přidal bych další mezivrstvu. Model je ve své podstatě zakonzervován a už se nemění.
U tebe vidím těch řádků o dost více, zejména pokud by se měly doimplementovat ty ostatní CRUD funkce. Jestli je databáze globální záleží u tohohle ORM podle způsobu použití, v nejjednodušším případně se používá jedna globální DB a statické funkce, je ale možné používat objektové API a/nebo více DB. Ta aplikace, co jsem řešil, používá DB dvě.Ty řádky jsem tam expandoval ze své obsluhy databáze, aby to neztratilo logiku. Ve skutečnosti těch řádek mám stejně.
Zatím jsem v tom tvém návrhu nenašel jediný příklad zapouzdření. Například o té tříděTo byl účel. Reflexe se občas hodí - z toho messengeru přímo generuji atributy do DOMu. Pokud do SELECTu v doméně přidám jeden sloupec, ihned se mi objeví ve výstupním stromu. Úplně stejně bych generoval JSON. Možná tě mate hvězdička v mém SELECTu. Ve skutečnosti tam mám definici sloupců ve stejné struktuře, kterou potřebuji ve view, včetně správných názvů atributů. Formátování výstupních dat, jejich seskupování a případnou lokalizaci řeší výstupní šablona ve view.Carvýše se asi těžko dát říct, že data o autě zapouzdřuje, když s těmi daty pracuješ někde jinde úplně mimo rozhraní té třídyCar. Vždyť ta třída ani vlastně pořádně neví, jaký data drží, takže tam o nějakém zapouzdření moc nemůže být řeč... Znovu připomínám, že to nemusí být nutně špatně, naopak je klidně možné, že to tak je lepší.
Myslíš si snad, že takových aplikací je méně než 90 % celého webu?Ano
Můžeš se třeba zamyslet, jak by se bez aplikační logiky realizovala tahle diskuse... (Protip: moc to nejde).
Je otázkou, zda je lepší rekurzívně mazat podstromy nebo uvolněné větve nechat zakořenit.Ábíčko umí afaik oboje. V každém případě ale na tyhle věci je potřeba obslužný kód, který už řadím do aplikační logiky...
Vždyť ta třída (Car) ani vlastně pořádně neví, jaký data drží, takže tam o nějakém zapouzdření moc nemůže být řeč...
Ale ví. Drží $vin toho auta a nejen to. Drží i nová data pro insert() či update().
$data, tzn. nějaký data, možná ví o $vin, ale jinak o těch datech nic netuší. Anebo tuší, ale pak jsi neříkal pravdu ohledně toho počtu řádků...
Njn, to ale pak není OOP návrh. Třída Car tam je pak k čemu?Existuje ještě jedno pravidlo: OOP se s relačními databázemi nemá rádo. Vždy mezi nimi musí být kus procedurálního kódu. Někdo použije ORM framework, někdo si napíše vlastní wrapper na 50 řádcích. Třída Car se tedy na jednu stranu chová objektově (viz polymorfní metody find, insert, update) a na druhou stranu (směrem k DB) relačně. Některé aspekty zvládne PDO a něco musí udělat wrapper. Nemůže si dovolit chovat moc objektově (viz Active Record), protože udržování cache je náročné. Proto jsem povinnost držet data ponechal primárně na databázi a sekundárně v controlleru či view. Balíky dat si mezi sebou posílají přes messengery. Vzhledem k tomu, že to jsou kopie, může si s nimi příjemce dělat co chce a není nutné je nijak zapouzdřovat.
Existuje ještě jedno pravidlo: OOP se s relačními databázemi nemá rádo.Tak to souhlas, oni any ty beans v RedBeanPHP nejsou zapouzdřený, když se odečte automatické generování schématu, modely a další fíčury, tak je to dost podobný těm tvým balíkům s reflexí... Technicky vzato by se ty beans daly zapouzdřit důslednějc, ale imho to nemá moc cenu... Beztak pedantické schovávání všeho do
private už dost vychází z módy
Člověk se vystavuje riziku, že tu třídu někdo použije!
Nad tím by se měl každý zamyslet...
Ale to ten tvůj citát moc nepodpoří.
Pokud getter nazvu getColor(), stěží ho mohu použít k získání jména majitele auta.
Tebe za trolla nepovažuji.
toString(), nebo co má ten interface dělat?
toString() blokováno pro jiný účel nebo potřeboval jiný typ návratové hodnoty, např. nějaký token? Hmm, pak bys to asi nazval getToken() nebo asToken(). Tak tedy dvojici [klíč=>hodnota].
Jinak interface nic nedělá, pouze popisuje vlastnosti rozhraní.
Interface sice sám o sobě nic nedělá, ale popisuje nějaké chování. Jinak ale moc nechápu, kam tím vším směřuješ, to, že se metoda pojmenuje pokudmožno smysluplně je snad samozřejmé, ne?
getColor(), který by měl být společný pro třídy Car i Owner na třídu Owner nepasuje. Podobně by nepasoval společný název metody getName().
Mířím k polymorfismu, který se v případě getterů/setterů nedá dost dobře použít.
Colorable s metodami setColor() a getColor(), například...
$model->find() mám společnou pro hledání objektu v databázi. Svým způsobem je také getter, jen má jako atribut objekt, podle kterého se hledá. Přitom model netuší, ve které tabulce, resp. doméně bude ta data hledat. To mu dodá ten objekt.
Místo $model->findCar($id) a $model->findOwner($id) mám tedy $model->find($car) nebo $model->find($owner). Výstup nacpu do DOMu nebo do JSONu dle potřeby a nemusím se zajímat o to, co jsem vlastně z databáze vytáhl. Polymorfismus a reflexe se postará o zbytek.
Gettery/settery nejsou určený na tahání dat z DB.... protože jsou k ničemu.
Dával jsem tu příklad setteru, máš možnost vysvětlit, proč je k ničemu a jak mám bez něj nastavit alpha hodnotu pixelu v pixmapě...
pixmap.pixel(0, 0).setAlpha(128);
Opravdu nevidim, proč by měl bejt ten setter špatně. Nepřipadá mi k ničemu. Jasně, alpha by se u barvy mohla nastavovat v konstruktoru, ale tady už je vytvořená.
pixmap.pixel(0, 0).Alpha = 128;
alpha je private (navíc nemusí vůbec existovat jako samostatný atribut, barva může být uložena v jednom integeru apod.), 2) tímhle způsobem bys mohl nastavit neplatnou barvu:
pixmap.pixel(0, 0).Alpha = 9001;
A jsme mimo povolený rozsah 0-255.
pixmap.setPixel(x, y, color);
Příkladem použití může být třeba algoritmus vykreslující přímku do té pixmapy.
Bereš to jako příklad, nebo mě donutíš najít příklad setteru v nějakém kódu online?
Myslel jsem si, že poznáš setter napsaný v jiné syntaxi.Myslel jsem si, že to není setter, protože jsem se ptal, čím ty blbé settery, které jsou tak k ničemu, nahradit. Nenapadlo mě, že navrhneš nahrazení setteru setterem.
Lepší by však bylo tu konstantu zapouzdřit do Alpha, aby se platnost alfy mohla ověřit už při kompilaci.1) Platnost se neověří při kompilaci, protože hodnota je dynamická.
echo.
Tiskni
Sdílej:
