Ocena kodu OOP - rozwiazania, Prosze o uwagi do implementacji koszyka wg zadanego interfejsu Opcje

[Lechus]

Szanowni profesjonaliści,

Proszę, w wolnej chwili, o przejrzenie kodu i udzielenie cennych wskazówek jak ten kod można ulepszyć.

Kod na Githubie

Plik READ ME.txt - tu jest opis co miało być zaimplementowane.
Instrukcja implementacji interfejsu

[matix]

No witaj,

Na szybko, co zauważyłem (wieczorem dokładniej się przyjrzę;-)

1. vendor/ do .gitignore
2. wielki + za testy
3. w wielu miejscach brak trzymania się standardów PSR
4. podkreślenia zmiennych prywatnych/protected już nie są w modzie. nie powinno się ich używać.

Architektura też nie powala. Ja bym do tego podszedł inaczej.
Zyjemy w czasach, gdzie podejście DependencyInjection to norma. Dlaczego z tego nie skorzystać.

Zrobiłbym jeden CartManager, który przyjmowałby np. w konstruktorze UserInterface $user. Za pomocą tej oto klasy, dodawałbym, usuwał rzeczy z koszyka:

[PHP] pobierz, plaintext 
* add(CartItemInterface $cartItem)
* remove(CartItemInterface $cartItem)
[PHP] pobierz, plaintext 

Oczywiście metoda zwracająca elementy koszyka, też byłaby wskazana:

[PHP] pobierz, plaintext 
/** @return \CartItemInterface[] $items */
* getCartItems() 
[PHP] pobierz, plaintext 

Zwróć uwagę na komentarz ;-) Dostajemy tablicę CartItemInterface. Co za tym idzie, mamy klasę, która implementuje ten interfejs, posiadająca atrybuty:

[PHP] pobierz, plaintext 
protected ProductInterface $product;
protected int $quantity = 1;
[PHP] pobierz, plaintext 

Typehinty tylko obrazowo.

Metoda Add w cartManagerze sprawdzałaby czy produkt jest już w tablicy, jeżeli tak, to tylko zwiększa quantity. W przeciwnym przypadku, dodaje nowy element do tablicy.

Oczywiście teraz klasa implementująca CartItemInterface miałaby magiczną metodę getCalculatedPrice(), gdzie miałbyś już zaszytą całą logikę wyliczania ceny. Cała klasa mogłaby się nazywać CartItemModifiedPrice, powiedzmy.

M.

Ten post edytował matix 18.04.2014, 11:07:42