Hej. Jakiś czas temu zrozumiałem, że oprócz wiedzy i praktycznie wszelakich z tym związanych możliwościach, to nie tylko to, co programista znać powinien. Są też zasady, (jak standard w3c) których dobrze jest przestrzegać - i tak oto trafiłem na zasady SOLID - aż wstyd się przyznać, że wcześniej ich nie znałem.

Podpowiedzcie mi, na moich chociażby przykładach, jak powinno najlepiej się podchodzić do tematu.

1. Jeśli mamy Single Responsibility. Rozumiem to tak, że każdy obiekt powinien być tak robity, by poszczególne jego składowe, można było wykorzystywać w różnych sytuacjach. By nie tworzyć funkcji typu GetAll(). Czyli jeśli mam np. klasę Faktury. To dobrze, jest ją rozbić na składowe, które są odpowiedzialne za różne rzeczy. Np.

[PHP] pobierz, plaintext 
$invoice = new Invoice->SearchInvoice(array('cos' => 'fv/8.2016'))->GetInvoiceId();
$invoice = new Invoice->InsertInvoice(array('cos'=> 'ddd'))->GetInvoiceUrl();
[PHP] pobierz, plaintext 

czy lepiej to jeszcze bardziej rozbijać, np.:

[PHP] pobierz, plaintext 
$invoice = new Invoice->Search(array('type' => 'invoice', 'cos' => 'fv11'))->GetId();
[PHP] pobierz, plaintext 

W pierwszym przypadku mam funkcję dedykowaną do szukania faktury SearchInvoice(). W zależności na jakich stronach wyszukuję faktury to piszę zawsze SearchInvoice() i wiem, że ta metoda zwraca faktury. A w drugim przypadku, jest metoda Search() którą mogę wykorzystać do szukania Faktur, ale też do szukania postów, do szukania użytkowników i szukania czegoś jeszcze. W drugim przypadku powstaje duża funkcja, w której jest dużo switch`ów, ale wykorzystywam ją w każdej stronie i nie muszę się zastanawiać co ona robi, a w pierwszym przypadku znowu większa ilość funkcji. Co jest lepsze prawidłowe?

2. Open Closed.

Mamy sytuację, że pobieram fakturę. Czyli lepiej jest tworzyć funkcję np. GetInvoicesById(1) , GetInvoicesTrashed(true, array('11', '22')) i tworzy się w tedy duża ilość funkcji, czyli lepszym będzie funkcja jak wyżej, czyli zawsze jako parametr dawać array (lub object) i wtedy nie trzeba dawać defaultowych wartości np.

[PHP] pobierz, plaintext 
function funkcja($zmienna = 1, $limit = 10, $offset = 0, $returnId = true) { } 
[PHP] pobierz, plaintext 

czy lepiej zawsze się przyzwyczaić i dawać:

[PHP] pobierz, plaintext 
function funkcja($params)
{
if(!empty($params['limit'])) { $params['limit'] = 10; }
if(!empty($params['offset'])) { $params['offset'] = 0; }
//itd..
[PHP] pobierz, plaintext 

3. Co to jest encja tak właściwie? Object czyli zbiór metod, funkcje czyli można powiedzieć metody, a encje? to jakaś wartość funkcji, np:

[PHP] pobierz, plaintext 
class jakas {
 private encja1 = '11';
 private encjejakas = '22';
 //itd...
}
[PHP] pobierz, plaintext 

4. To już pytanie o Laravela. Jak się powinno fachowo generować podstrony i wykonywać routing. Załóżmy narazie prosty przykład, gdzie jest:

[PHP] pobierz, plaintext 
Route::get('/{page}', function ($page, App\User $user, App\Cache $cache, App\Post $post) {
 
$PageDataType = new Post->SearchPost(array('slug' => $page'))->GetType();
switch($PageDataType)
{
case 'post':
$return = new Post->SearchPost(array('slug' => $page'))->GetAll();
break;
}
 
 
return view('pages.'.$page, ['data' => $return]);
 
}
 
// i w templatce np. wyswietlamy dane itd.
[PHP] pobierz, plaintext 

Używam laravel 5.1 :-)


Z góry dziękuję za wszelkie wskazówki ;-)



Nikt nic?

Dużo masz pytań, postaram się odpowiedzieć na 1 żeby zachęcić resztę społeczności

Single Responsibility


W Twoim przykładzie, żadna z odpowiedzi nie jest dobra.

[PHP] pobierz, plaintext 
$invoice = new Invoice->SearchInvoice(array('cos' => 'fv/8.2016'))->GetInvoiceId();
$invoice = new Invoice->InsertInvoice(array('cos'=> 'ddd'))->GetInvoiceUrl();
[PHP] pobierz, plaintext 

Czyli dla każdej tabeli/modelu musimy tworzyć osobne metody insert, serach itp. chociaż wyglądają tak samo - jedyna zmiana to będzie nazwa tabeli i ew. pól które chcemy zaznaczać, dodawać - odpada.

[PHP] pobierz, plaintext 
$invoice = new Invoice->Search(array('type' => 'invoice', 'cos' => 'fv11'))->GetId();
[PHP] pobierz, plaintext 

Drugi sposób jest już bardziej w porządku, zakładajac, że metody search, insert itp. są w jakiejś nadrzędnej klasie np. "Model".


Tutaj jest problem, nie powinno być switcha, tylko ta nadrzędna klasa powinna korzystać z właściwości tej podrzędnej np.

[PHP] pobierz, plaintext 
<?php
 
class DataSource {
 
	public function insert($tableName, $data) {
		echo "$tableName\n";
		foreach($data as $key => $value)
			echo "$key\t$value\n";
	}
 
}
 
 
interface SimpleTableInterface {
 
	public function getTableName();
 
}
 
class SimpleTable {
 
	private $database;
	protected $tableName = null;
 
	public function __construct(DataSource $database) {
		$this->database = $database;
		$this->tableName = $this->getTableName();
	}
 
	public function insert($data) {
		return $this->database->insert($this->tableName, $data);
	}
 
}
 
class InvoiceTable extends SimpleTable implements SimpleTableInterface {
 
	public function getTableName() {
		return 'invoces';
	}
 
}
 
$database = new DataSource();
$invoces = new InvoiceTable($database);
$invoces->insert([
	'number' => 'FA-TEST-123'
]);
 
?>
[PHP] pobierz, plaintext 

Metoda getTableName w klasie InvoiceTable komunikuje się z klasą SimpleTable za pomocą interfejsu SimpleTableInterface, po to aby klasa SimpleTable wiedziała na jakiej tabeli wykonywać określone zadania.

I teraz jeżeli np.
- zmienimy rodzaj bazy danych edytujemy tylko klasę DataSource nie ruszając innych rzeczy.
- chcemy pobierać faktury po numerze zamiast po ID to edytujemy klasę InvoiceTable dodawająć metode np. getByNumber.
- jakaś tam kolejna tabela np. Users przed insert musi hashować hasło - możemy to dodać tylko w tej klasie bez żadnego switch`a.

Nie jest to może idealny przykład i jestem pewny, że powyższy kod dało by się rozpisać o wiele lepiej - myślę jednak, że do zrozumienia "Single Responsibility" Ci wystarczy.