Witam, mam dwa pytania gdyż natrafiłem na te pojęcia
- testowanie jednostkowe
- dependency injection

Jak ja to widzę
- testowanie jednostkowe - to po prostu sprawdzenie czy dany fragmentu kodu (klasy) działa, zwraca co należy i czy POTRZEBNE do tego są rzeczy takie jakie SimpleTest/PHPUnit czy mogę po prostu sprawdzać samemu co zwraca metoda np poprzez uzywania var_dumpa, i jak coś się nie zgadza bo zwróciło coś czego nie powinna to wtedy szukam błędu oraz teraz kwestia tworzenia porządnego kodu, który można testować, kod mam tworzyć tak, że można go testować samodzielnie, bez dokładania mu dziesiątek innych obiektów, może jakaś ciekawa stronka, która opisuje to porządnie (po angielsku może być)

- dependency injection - chodzi w tym o to, że żadna klasa nie tworzy sama w sobie nowych obiektów klas, tylko ma je przekazywane przez parametr lub sięgają po obiekty z 'kontenera' zalezności?

np

[PHP] pobierz, plaintext 
$DI = new DI();
$DI->db = new DB( $loginInformation );
 
 
$application = new Application( $DI->db );
lub ewentualnie w konstruktorze klasy Application robię
$this->db = $DI->db; //$DI przekazuję w parametrze lub ew. robię z tego singletona z dostępem do instancji poprzez statyczną metodę getInstance 
[PHP] pobierz, plaintext 

?


Przepraszam za wszystkie głupoty, które tutaj napisałem, ale na tym polega nauka

Testy: niby można by przygotować sobie jakieś testy bez wykorzystania narzędzi takich jak PHPUnit, ale na dobrą sprawę będzie to cholernie niewygodne, wydłuży i tak już sporą ilość czasu jaką trzeba poświęcić na testy, a ostatecznie skończy się "wymyślaniem koła od nowa" i przepisywaniem fragmentów tych tego typu narzędzi. Zresztą dochodzi się do absurdalnej sytuacji, gdzie będziesz musiał pewnie pisać testy do zestawu narzędzi do przeprowadzania testów. Odnośnie strony: dokumentacja samego PHPUnita robi za całkiem przyzwoity "wstęp do TDD".

Odnośnie DI: to tylko nazwa dla pewnych konstrukcji w kodzie, ale tak: generalnie chodzi o to by zewnętrzne zależności dla danego obiektu były mu przekazywane jako argumenty konstruktora (te które są bezwzględnie wymagane) bądź poprzez dedykowaną metodę (opcjonalne zależności). Na tym kończy się DI jako takie. Kontener zależności (DIC) to już zupełnie inne zagadnienie i służy on pewnej automatyzacji procesu tworzenia mocno rozbudowanych struktur obiektów.
- bezpośrednie używanie kontenera zależności jest złą praktyką - tworzy ukryte zależności, które mają być przez DI wyeliminowane,
- używanie metod statycznych również jest złą metodą - j/w,
- obiekty mogą wewnątrz swoich metod tworzyć inne obiekty - nie wszystko musi pochodzić z zewnątrz,
- przeczytaj sobie: http://symfony.com/doc/current/book/service_container.html - jest to może fragment dokumentacji Symfony, ale porusza on problem DI/DIC dosyć ogólnie.

Dzięki wielkie, poczytałem co napisano w tej dokumentacji SF i wnioski wysnułem takie, że DIC jest po to by operować na jednej INSTANCJI jakiejś klasy, czyli taka praktyka, by omijać metody statyczne np mając klasę do wysyłania wiadomości email, potrzebna nam tak naprawdę będzie tylko jedna instancja (by ominąć ciągłą konfigurację za każdym razem jak tworzymy obiekt tej klasy w innych klasach) co ułatwia sprawę globalizacji, gdyż jeśli chcemy zmienić dla przykładu użytkownika SMTP obrębie całej aplikacji, to nie musimy szukać wszystkich obiektów tego "mailera", często w aplikacjach widziałem klasę Application i tam były podefiniowane własności

class Application {
protected $db;
protected $mailer;
protected $input; //post i get
protected $costam;

//metody tworzące i gettery

}


Było to jak nazwa wskazuje, serce aplikacji i tam też były metody, które tworzyły instancję klas (db, mailer, input, costam [initializeDb, initializeMailer]), czy można takie coś nazwać DIC?

1. DIC może tworzyć wiele instancji tego samego serwisu (patrz: scope) przy czym faktycznie, domyślnie żywotność serwisu zdefiniowana jest przez sam kontener.
2. DIC w żaden sposób nie jest praktyką na ominięcie metod statycznych, które notabene są z reguły wysoce niepożądane.
3. Masz rację, w przypadku takiego Mailera będziemy potrzebować zapewne tylko jednej instancji takiej usługi - stąd też takie jest domyślne zachowanie kontenera (patrz pkt. 1).
4. Taka klasa Application to przykład tzw. Service Locator i również jest przykładem złego kodu. Ba!, nieraz nazywana jest wręcz anty-wzorcem. W Wiki jest krótkie podsumowanie wad takiego rozwiązania. Jest to przeciwieństwo DIC-a.
5. Klasa "serce aplikacji" już z definicji wskazuje, że jest to coś złego, taka klasa bóg.