Je PHP nutné k uplatnění?

[Kolemjdoucí]

Ještě mi poraď, jak mám nazývat ty mizerné jednořádkové gettery/settery, které jen suplují viditelnost public, ale jinak nejsou schopny ověřit ani validitu parametru?

Pokud to nedělá co to dělat má, pak je to zmetek.

[Reklama]

[Kit]

Pokud to nedělá co to dělat má, pak je to zmetek.

Dobrá. Budu to tedy nazývat getterový/setterový zmetek, abych to nějak odlišil od ostatních zmetků.

Stále si však myslím, že často je výhodnější místo jednoho anemického objektu se třemi atributy, třemi gettery a třemi settery použít tři plnohodnotné objekty - každý se svým rozhraním, konstruktorem a sadou metod.

[Kolemjdoucí]

Stále si však myslím, že často je výhodnější místo jednoho anemického objektu se třemi atributy, třemi gettery a třemi settery použít tři plnohodnotné objekty - každý se svým rozhraním, konstruktorem a sadou metod.

Objekt se třemi private atributy a k tomu 6 metod pouze převádějící viditelnost mezi private a public, je naho*no, to se shodneme. Náhrada záleží na situaci.

[meh]

To je velké nepochopení. Getter/setter != povinnost umožnit přímý přístup k členské proměnné. Je na libovůli a odpovědnosti programátora co tam napíše, je to normální metoda.
Že tam někdo píše hlouposti ještě neznamená že je to hloupost samo o sobě.

Fajn, až uvidím getter/setter podle těchto pravidel, budu nadšen.

Ještě mi poraď, jak mám nazývat ty mizerné jednořádkové gettery/settery, které jen suplují viditelnost public, ale jinak nejsou schopny ověřit ani validitu parametru?

ze by enterprise?

[perceptron]

Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů?

spring framework. skvela inspiracia pre citanie

Stále si však myslím, že často je výhodnější místo jednoho anemického objektu se třemi atributy, třemi gettery a třemi
settery použít tři plnohodnotné objekty - každý se svým rozhraním, konstruktorem a sadou metod.

eh? mate priklad?

lebo sa bojim, ze v boji voci getterom a setterom vygenerujete cosi, co evokuje ejb 2.1, kde hello world zaberal dva interfejsy, dve implementacie, two turtle doves and a partridge in a pair tree

ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)

a dolezita vec: gettre a settre maju dalsiu vyhodu, stoji na nej tooling (napr. reflexia, javabeans, mapovanie jsonov, mapovanie databaz)

[Reklama]

[kozzi]

ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)

zrovna k tomu se settery a gettery moc nehodi  , ne ze by daji se pouzit ale jsou lepsi zpusoby jak toto resit

[Kit]

ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)

zrovna k tomu se settery a gettery moc nehodi  , ne ze by daji se pouzit ale jsou lepsi zpusoby jak toto resit

Máš na mysli obalové třídy?

[perceptron]

samozrejme, validacia sa da riesit externe.

kit, takze z prikladu pre Pravejsie OOP nic? :-) miesto toho novy termit?

[Kit]

Bacha, aby sis neublížil. Jak vypadá tvůj viditelný příklad dobrého návrhu OO projektů?

spring framework. skvela inspiracia pre citanie

To je tvůj framework? A jede v PHP?

[Kit]

samozrejme, validacia sa da riesit externe.

Externí validace? To myslíš vážně?

[to_je_jedno]

nechcete si jit rozslapavat babovicky jinam?

[perceptron]

Externí validace? To myslíš vážně?

javax.validation

[Kit]

Externí validace? To myslíš vážně?

javax.validation

Takže ji voláš z konstruktoru validovaného objektu? To pak není externí validace, ale interní.

[kozzi]

ku getterom a setterom: to, ze niekto nevidi dovod pisat do settera validacie napr. pre zaporne parametre, je problem vyvojara, ktory to mozno nepovazuje za potrebne (opat, autogenerovanie bez zmyslu)

zrovna k tomu se settery a gettery moc nehodi  , ne ze by daji se pouzit ale jsou lepsi zpusoby jak toto resit

Máš na mysli obalové třídy?

JJ, v pripade nekterych jazyku existuji i specialny vlastni typy s vlastnimi rozsahy hodnot atd.

[Kit]

Máš na mysli obalové třídy?

JJ, v pripade nekterych jazyku existuji i specialny vlastni typy s vlastnimi rozsahy hodnot atd.

Zjistil jsem, že ty obalové třídy skutečně má smysl dělat. Logika objektu (refaktorovaného z pouhého atributu) je hezky zapouzdřena a dá se dobře recyklovat. Kupodivu se tím aplikace o něco málo zkrátí a stane se robustnější. Také se dá mnohem lépe použít polymorfismus, takže odpadne spousta rozhodovacích bloků a program se o něco zrychlí.