Je PHP nutné k uplatnění?

[Radek Miček]

• držení dat
• nastavení dat
• získávání dat

To jsou 3 komponenty, které mohou existovat nezávisle na sobě.

Mohou, ale nemám pocit, že by to porušovalo SRP, stále tam jde o držení dat.

Mj. v mém příkladě žádný setter ani getter není (alespoň ne z pohledu uživatele jazyka, z pohledu bajtkódu ano).

[Reklama]

[Kit]

• držení dat
• nastavení dat
• získávání dat

To jsou 3 komponenty, které mohou existovat nezávisle na sobě.

Mohou, ale nemám pocit, že by to porušovalo SRP, stále tam jde o držení dat.

Nejen držení dat, ale i jejich modifikace a zjišťování stavu. Můžeš mít 3 důvody, proč modifikovat třídu.

Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.

Kdyby se SRP mělo dodržovat striktně, třída by mohla mít v sobě jeden atribut, jeden getter, jeden setter nebo jednu metodu. To by byl samozřejmě nesmysl. SRP není striktní dogma, ale pomůcka při rozhodování, jak uspořádat kód programu. Pokud má běžná třída 2-4 souvisejících atributů a k nim 5-10 nepříliš složitých metod, které s nimi pracují, obvykle SRP neporušuje.

[Radek Miček]

Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.

To je nesmysl. Zapouzdření by bylo např. porušeno, kdybych zvenku přistupoval k privátním fieldům objektu přímo.

Nejen držení dat, ale i jejich modifikace a zjišťování stavu. Můžeš mít 3 důvody, proč modifikovat třídu.

Mám jen jeden důvod, a to když se změní data, jenž chci držet. U anemické třídy přeci neměním getter nebo setter nezávisle, aniž by se změnila data, jenž ta třída má držet.

[Kit]

Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.

To je nesmysl. Zapouzdření by bylo např. porušeno, kdybych zvenku přistupoval k privátním fieldům objektu přímo.

V reálu to vypadá stejně a také funkčnost je prakticky stejná. V C# se to liší velikostí písmene, v PHP se to neliší vůbec. Je otevřené další rozhraní zvenku do objektu, zapouzdření je porušeno. Přimhouříme oko a prohlásíme, že porušeno není.

Nejen držení dat, ale i jejich modifikace a zjišťování stavu. Můžeš mít 3 důvody, proč modifikovat třídu.

Mám jen jeden důvod, a to když se změní data, jenž chci držet. U anemické třídy přeci neměním getter nebo setter nezávisle, aniž by se změnila data, jenž ta třída má držet.

Anemické třídy raději obhajovat nebudeme, že?

• Změním typ atributu. Musím změnit getter i setter
• Změním typ vstupní hodnoty. Musím změnit setter
• Změním typ výstupní hodnoty. Musím změnit getter

Tři různé požadavky, tři změny. SRP se v principu nekoná, ale opět přimhouříme oko a řekneme, že to SRP vyhovuje.

[Radek Miček]

V reálu to vypadá stejně a také funkčnost je prakticky stejná. V C# se to liší velikostí písmene, v PHP se to neliší vůbec. Je otevřené další rozhraní zvenku do objektu, zapouzdření je porušeno. Přimhouříme oko a prohlásíme, že porušeno není.

Ne, není potřeba přivírat oči, je to naprosto korektní. Podívejte se, jak je zapouzdření formalizováno - nejjednodušší je to na modulech, těžší pak na objektech, a uvidíte, že se nic neporušilo. Ve zkratce: před vnějším světem se schová (zapouzdří) část objektu (v odkazovaných materiálech pomocí existenciálních typů) a vnější svět přistupuje pouze k neschovaným částem, přičemž gettery ani settery to nijak nenarušují.

• Změním typ atributu. Musím změnit getter i setter
• Změním typ vstupní hodnoty. Musím změnit setter
• Změním typ výstupní hodnoty. Musím změnit getter

Tři různé požadavky, tři změny. SRP se v principu nekoná, ale opět přimhouříme oko a řekneme, že to SRP vyhovuje.

Ta třída má jen jednu odpovědnost a to držení dat. Gettery a settery slouží k tomu, abychom v té třídě ta data mohli držet. Mj. můžete si představit třeba automaticky implementované vlastnosti v F# nebo C#, kde ten typ je pouze na jednom místě.

Anemické třídy raději obhajovat nebudeme, že?

Ale ano. Ve funckionálních jazycích, i moderních OO jazycích jako je Scala a F# se to normálně používá a je to užitečné (viz třeba můj příklad). Navíc o přidání podpory pro anemické třídy uvažoval i C# - př.:

abstract class Expr;
record class X() : Expr;
record class Const(double Value) : Expr;
record class Add(Expr Left, Expr Right) : Expr;
record class Mult(Expr Left, Expr Right) : Expr;
record class Neg(Expr Value) : Expr;

[Reklama]

[perceptron]

Scala není PHP. Na znovunepoužitelnost si nehraji. Spousta se toho nakecá, ale když se nějaká třída má použít znovu, použitelná není.

aby sme neblabolili o tom, ze vy mate vlastnu definiciu oop, vlastnu definiciu srp a vlastnu definiciu zapuzdrenosti, ktora vam sedi do kramu...

co s tymi unit testami? napr. ste v stave vo vasej architekture mocknut kod pre vkladanie do databazy? (pytal  som sa viackrat)

prave na unit testoch sa ukaze prisposobitelnost a znovupouzitelnost classov (a napr. anemicky model je jednym z prikladov, ked to mockovat viete radostne)

Gettery a settery navíc porušují zapouzdření objektu, takže by se ani z tohoto důvodu neměly používat.

jo, ked uz kolega umne spomenul scalu: co takto immutable classy, data pchane cez konstruktor?