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

[Crozin]

@viking: Jeszcze raz, wyjaśnijmy sobie proszę bardzo fundamentalne deklaracje. DI to po prostu nazwa dla pewnego wzorca/schematu kodu - nic więcej. Niejednokrotnie wykorzystuje się go nawet nieświadomie. To co cały czas tutaj opisujesz to różnego rodzaju kontenery/menadżery zależności - to już zupełnie inna kwestia (fakt, że w nazwie mają dependency injection (np. CDI) nie oznacza, że tym są). Te już występują w przeróżnych wariantach, z różnymi opcjami konf. bazującymi na różnych podejściach do samej konf. zależności. Często można je spotkać pod nazwą dependency injection container, ale DI ≠ DIC - i to jest najważniejsze w moim i @destroyerr'a postach.

Te kontenery w swoim wnętrzu bardzo często faktycznie będą obsługiwały coś przy pomocy takiej właśnie tablicy (string => obiekt), ale to jest na ich wewnętrzny użytek. Jako użytkownik takiego kontenera nie powinieneś w ogóle z tego korzystać. Tutaj niestety pojawia się taki problem, że wiele FW wręcz zachęca w swoich dokumentacjach do korzystania z tego, stąd też ich użytkownicy to robią. Co do Java'owych @Inject (z CDI) czy @Autowired (ze Springa)
1. To już są narzędzia konkretnych realizacji kontenerów zależności i należą do ich wewnętrznej konfiguracji. Same w sobie nie mają bezpośredniego związku z tematem wstrzykiwania zależności. To dopiero sam kontener realizuje to zadanie.
2. Te adnotacje są wynikiem wprowadzania do Javy (w sumie do PHP też) coraz szerszego podejścia convention over configuration oraz chęci skrócenia kodu/plików konfiguracyjnych. Przy czym warto tutaj zaznaczyć, że dla np. takiego Springa nadal jest to tylko jeden ze sposobów na określenie "co wstrzyknąć", a nie jego podstawowy/jedyny sposób.
3. W PHP istnieją podobne narzędzia, np. w Symfony mamy dostęp do @Inject (JMSDiExtraBundle) przy czym ich działanie jest jednak nadal trochę odmienne - nie potrafi pracować na interfejsach i zawsze musi mieć podany konkretny serwis do wstrzyknięcia.

Na koniec chciałem tylko podkreślić jedną rzecz. Zarówno ja jak i @destroyerr (myślę, że mogę go tutaj wymieć ;] ) również uważamy że zapis typu:

[PHP] pobierz, plaintext 
$mailer = $this->someContainer->get('my.mailer.service');
$mailer->doSth();
[PHP] pobierz, plaintext 

Jest zły, niweczy większość, jak nie wszystkie z zalet DI, utrudnia testowanie aplikacji oraz może sprawiać jakieś problemy przy przejmowaniu po kimś kodu. Chcieliśmy tylko zwrócić Ci uwagę na to że pow. przykład kodu nie jest przykładem realizacji dependency injection. (IMG:style_emoticons/default/wink.gif)