Anonymní profil Nickname – Programujte.com

#8 Kit
Zajisté, tomu rozumím. Ale předtím, než budeš psát třídu, která se ti stará data - ať už bere data z databáze nebo někde z nějakého souboru, musíš vědět pro koho bude tato třída určena - neboli kdo jí bude používat. Pokud se v tvém případě budeme bavit o controlleru Clanek, který uživatel může zobrazit či upravit, tak by bylo dobré mít třídu, která bude pracovat s daným úložištěm (databáze, či něco jiného) a která bude mít metody jako select nebo update.

Dále, co když budu mít controller AdministraceClanku, kde budu potřebovat článek zobrazit, upravit a ještě k tomu smazat. Co to pro mě teď znamená? Pokud bych si zase vytvořil čiště novou třídu, která se mi bude starat o select, update, delete, měl bych duplicitní kód.

#6 Kit
Takže ty ke controlleru Clanek_POST stavíš třídu s SQL dotazy Clanek. Třída Clanek poté obsauje všechny dotazy, které je možné zavolat v Clanek_POST?

Mě trápí ta věc, že před tím, než si vyrobím třídu s SQL dotazy si musím uvědomit pro co to vlastně budu psát. Budu ty SQL psát pro daný kontroller? Pro danou tabulku, kde mi vznikne spousta dotazů? Nevím a s tím potřebuji poradit.

#4 Kit
Děkuji za vyčerpávající odpověď. Pokud tomu rozumím, tak ke každému controlleru máš připojený daný model, který se stará o validaci a zároveň o SQL dotazy na daném controlleru?

#2 Kit
Myslíš, že bys mohl nadhodit jednoduchý kód, ve kterém bys uvedl komentáři, kde co děláš? Špatně se mi to představuje. Děkuji

Ahoj,

chci se zeptat kam vkládáte veškeré SQL dotazy, pokud pracujete s nějakým MVC. Je správný způsob, pokud si pro každý Controller vytvořím samostatnou třídu, která se stará pouze o SQL dotazy, které je možné používat pouze na daném Controlleru? Validace a podobné věci se zase provádí ve zcela jiné třídě. Také mě zajímá, jak takové třídy s SQL dotazama pojmenovat a jestli k nim postavit nějaké rozhraní či ne. Neměl byste někdo  nějaký pěkný příklad či správný postup kam umístit SQL dotazy?

Děkuji za odpověď.

#2 Kit
Díky za radu. Nejprve jsem přemýšlel nad řešením jako Composite, Decorator nebo Iterator, ale tohle se zdá být jako nejlepší řešení. Ještě jednou díky.

Ahoj,

mám dvě třídy, které mohou ukládat soubory (obrázky) do databáze a také na pevný disk do nějaké složky. Chci tyto třídy použít zároveň a ukládat jak do databáze, tak na pevný disk - třeba jako zálohu, to je už jedno. Přikládám hirearchii objektů:

interface Storage {
    public function store();
}

class DatabaseStorage implements Storage {
    public function store() {
        //...
    }
}

class FileStorage implements Storage {
    public function store() {
        //...
    }
}

Tak, a teď chci tyto dvě třídy použít zároveň, takže jsem si vytvořil novou třídu.

class ChainStorage implements Storage {
    private $databsaeStorage;
    private $fileStorage;

    public function __construct(Storage $databaseStorage, Storage $fileStorage) {
        $this->databaseStorage = $databaseStorage;
        $this->fileStorage = $fileStorage;
    }

    public function store() {
        $this->databaseStorage->store();
        $this->fileStorage->store();
    }
}

Nicméně, tento způsob se mi nelíbí. Omezuje mě v tom, že pokud bych chtěl přidat další "Storage", musel bych přidat parametr a to mě znechucuje.

Taktéž nechci použít žádný setter typu "setStorage" nebo jinou metodu typu "addStorage", protože by se mi "znehodnotilo" rozhraní.

V jiných programovacích jazycích bych si jednoduše vytvořit List<Storage> nebo něco v tom smyslu a to předal konstruktoru a poté to v dané metodě store projel cyklem a byl by pokoj, ale jak to udělat tady?

Dostal se někdo do stejné situace, popřípadě, jak jí řešil, či jak byste ji řešili vy?

#6 Kit

Ok, super. Díky za radu :)

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

#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ěď.

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

Jasně, z toho co píšeš mi to dává smysl. Už jsem si to vše poskládal.

Ještě jednou děkuji.

Děkuji za odpověď. 

Ano, také jsem nad tím takto uvažoval a došel jsem ke stejnému závěru, ale pak jsem si řekl:

Co když budu chtít základní třídu dodat jako parametr do konstruktoru? Dám tam První nebo Druhá? Pokud První, musím se ptát pouze ohledně kontraktu třídy První, tedy nemohu použít metodu z ve třídě Druhá. V tomto případě bych se také někde v dalším objektu musel ptát na instanci nebo na existenci metody.

Ale tedy jak si psal, o opačném směru nic neříká, tak je to asi ohledně LSP v pořádku.

Ahoj, jsem relativně seznámen s liskov substitution principle, nicméně stejně mi jedna věc vrtá v hlavě. Tedy, zvažme část kódu:

<?php

class Prvni {
	private $x;
	private $y;

	public function x() { }
	public function y() { }
} 

class Druha extends Prvni { 
	private $z;

	public function z() { }
}

Jedná se v tomto případě o porušení LSP, nebo ne? A pokud bych měl v první třídě identifikátory přístupu protected místo public, bylo by to porušení principu také nebo ne? Dle mého názoru ano, nicméně nejsem si zcela jist. Jaký je tedy váš názor? Děkuji za odpověď.