Konstruktor v OOP – PHP – Fórum – Programujte.com

Ahoj, nenašel jsem lepší místo pro publikování, tak jsem otázku směroval sem.

Vždy jsem si přes konstruktor předával závislosti v podobě rozhraní, nicméně, k čemu jinému je konstruktor v OOP?

Někde jsem viděl, že by parametr v konstruktoru měl reprezentovat daný objekt. Tedy v případě třídy Folder, by parametr v konstruktoru měl být daný název složky, aby poté tato třída reprezentovala danou složku.

Nebo v případě třídy, která se jmenuje Web, by opět v konstruktoru měl být parametr na daný web, třeba google.com a tak dále.

Zdá se mi to jako dobrý nápad, nicméně když budu chtít v konstruktoru předávat závislosti a poté ještě tyto parametry, bude počet parametrů docela velký.

Za další, pokud se budeme bavit o parametrech v metodách, které mají rozhraní, bude lepší, pokud tyto metody budou mít co nejméně parametrů? Tedy kupříkladu u třídy Folder, by bylo vhodné, pokud by měla metodu jménem read bez parametrů, protože složku, kterou reprezentuje již bylo zadáno v konstruktoru.

Mé otázky teda zní:

1. Míchat závisloti s obyčejnými skalárnimi typy v konstruktoru, je na tom něco špatného?

2. Psát metody pro rozhraní co nejtenčí (co nejméně parametrů, třeba i žádný) a vše potřebné si předávat v konstruktoru?

Děkuji

#1 Facedown
Konstruktor v OOP slouží k vytvoření konzistentního objektu. Pokud má víc než 3 parametry, asi není něco v pořádku a bylo by dobré třídu rozdělit. Do konstruktoru pak místo skalárů předáš objekty nebo kolekce.

Rozhraní by mělo být pokud možno tenké, tedy s minimem metod. Raději více tenkých rozhraní než jedno tlusté. Pokud možno bez zbytečných getterů a setterů, protože ty počet metod často neúměrně zvyšují. Počet parametrů metod by měl být v rozumných mezích (0..3)

#2 Kit
Díky za odpověď, nicméně nejsem z ní moc moudrý.

Zvažme, že máme tuto třídu:

class Folder implements IFolder {
	private $path;

	public function __construct($path) {
		$this->path = $path;
	}

	public function read() {

	}
}

Má v kontruktoru cestu k dané složce, což zaručuje jedinečnost objektu a víme, že daná třída Folder reprezentuje danou složku, kterou předáme v $path. Také zaručuje němenost objektu, což je výhoda. Nicméně, jak jsem již psal výše, trápí mě ten skalární typ v konstruktoru. Podle tebe bych si na to měl vytvořit nový objekt a místo skalárního typu předávat ten daný objekt? Mimo popsané výhody výše taky daná metoda nemá žádné parametry. Je to dobře nebo špatně? Mělo bychom vytvářet metody v rozhraní, které mají co nejméně možných parametrů a vše potřebné, třeba i skalární typ si předat v konstruktoru?

Díky za odpověď.

Ja Kita chapu tak, ze kdyz mas obri objekt, tak ho mas rozdelit na mensi casti, ktere k sobe patri. Uz kvuli srozumitelnosti. Treba, mas objekt web, ktery v sobe obsahuje struktury pro mail, formulare a pod, tak by to slo rozdelit kazde zvlast a do objektu web jen pridat. Nebo opacne, k objektu formular pridat metody z objektu web.
Ja mam treba objekt sql  (resi sql, at uz pdo ci mysql), file (resi praci se soubory, upravu url a pod, upload,...), image (resi transformace obrazku, delani nahledu). Zatim jsem se uspesne vyhybal slozitejsim konstrukcim. Ale taky delam php spis jako konicka, obcas neco i v praci, mensiho.

#4 peter
Samozřejmě, to já vím a na to jsem se ani neptal, ale i přesto ti děkuji za ochotu.

Ptal jsem se na to, jestli je správné vytvářet konstruktory se sklaráními typy jako parametr. Díky těmto skalárním typům v konsturktoru poté nepotřebuji parametr v metodě. Ptám se tedy, jestli si místo těchto skalárních typů v konstruktoru vytvořit objekt a ten předat v konstruktoru a metoda by poté měla minimální počet parametrů. Nebo na to objekt nevytvářet a předat skalární typ v metodě a ne v konstruktoru.

class Folder implements IFolder {
	private $path;

	public function __construct($path) {
		$this->path = $path;
	}

	public function read() {

	}
}

// A nebo radši použít toto?

class Folder implements IFolder {
	public function read($path) {
		
	}
}

V případě, že bych používal tento skalární typ, tak bych asi použil radši druhou verzi. Nicméně, pokud bych si místo $path vytvořil nový objekt, tak bych ho předal v konstruktoru, a poté volal metodu read bez parametrů a zamlouvalo by se mi poté více první řešení s objektem. Tedy, vytvořit si vždy objekt, abych si ho mohl předat v konstruktoru a ostatní metody již nemuseli mít parametry, nebo objekt nevytvářet a předat hodnotu v parametru nějaké metody, v tomto případě read?

Děkuji za ochotu.

#3 Facedown
V daném případě bude skalár $path nejspíš v pořádku a nevidím v tom problém.

Jiná situace by však nastala, pokud bys potřeboval zajistit, aby $path byla skutečná platná cesta. Aby v případě neexistující cesty vyhodila výjimku nebo (alternativně) byla cesta vytvořena a teprve v případě neúspěchu byla vyhozena výjimka. V těchto případech by se hodilo mít $path jako objekt třídy Path, který bys předal konstruktoru třídy Folder.

Podobně by to mohlo být i s URL.

BTW: Nepoužívej na začátku názvu interface předponu "I-". To se dělá snad jen v C#, kde se vyhýbají OOP jak jen to jde. IFolder je tedy špatně. Má to být nějaká vlastnost, kterou má implementace splnit. Když tam máš metodu read(), tak třeba Readable. Pokud to má být objekt, kterým půjde procházet, tak např. Iterable.

#6 Kit

Ok, super. Díky za radu :)