Pracując na projektem pisanym obiektowo, natknęliśmy się na problem korzystania z metod jednej klasy w drugiej.

Dyskutując na ten temat, odrzuciliśmy tworzenie obiektu innych klas wewnątrz danej klasy, czyli:

[PHP] pobierz, plaintext 
class User
{
  function __construct($sessionName)
  {
    $this->storage = new SessionStorage($sessionName);
  }
 
  // ...
}
 
$user = new User('SESSION_ID');
[PHP] pobierz, plaintext 

Zostały dwa sposoby, podane w nazwie tematu.
Małe wyjaśnienie odnośnie klas statycznych: jak pewnie większość się domyśla, chodzi o pisanie metod statycznych i korzystanie z nich w innej klasie w sposób następujący: Klasa::metoda();
W związku z tym zwracam się do Was z prośbą o wyrażenie opinii, z czego byście wy skorzystali i dlaczego.

Ja osobiście jestem za Dependency Injection znanego z Symfony, ale trzeba jakoś innych przekonać ;]

DI bo:
- taką aplikację łatwiej testować
- aplikacja może być kompletnie odseparowana od innych w obrębie jednego skryptu
- dzięki DI lepiej zarządzasz pamięcią w aplikacji
I to wystarczy

Pokaż ludziom dowolną książkę o Javie. DI jest tam znane od wieków i powstały już pewnie ze dwie tony opracowań o jego wyższości nad statycznymi metodami oraz singletonami.

Po raz kolejny spotykam się z brakiem zrozumienia semantyki słowa klasa. "Klasa", w której wszystko jest statyczne nie jest klasą, tylko przestrzenią nazw. Chyba jedyną różnicą miedzy tego typu zbiornikiem, a typową przestrzenią nazw jest możliwość dziedziczenia, choć i to da się zasymulować w przypadku zwyczajnych przestrzeni nazw.

Co więcej, jakie wg. Ciebie "klasa" statyczna ma zalety względem tworzenia obiektów w innych obiektach? Ja nie widzę żadnych.

DI daje wspaniałą, niemalże nieograniczoną, elastyczność. Po co sobie na siłę życie komplikować?

Jakbym zaczął pisać o przestrzeni nazw to nie każdy by kojarzył o co mi chodzi, a ja to odniosłem tylko do kodu zawartego miedzy class Nazwa {}

Odpowiadając na pytanie: przecież DI to nie jest tworzenie obiektu w obiekcie, tylko wstrzykiwanie już utworzonego obiektu. A jeśli chodziło Ci o przykładowy kod, który podałem, to podkreśliłem nawet, że tą opcję odrzuciliśmy na samym początku

Chodziło mi o przykładowy kod. A konkretnie o to, że z Twojej wypowiedzi mniej więcej wynika, że korzystanie z "klas" statycznych jest lepsze od kodu, który odrzuciliście. Ciekaw jestem dlaczego tak uważasz.

Teraz rozumiem Tak jak wstępnie napisałem, ja jestem za DI. Jako że sam nie podejmuje decyzji, powinienem uwzględniać propozycje innych.
Byłem za odrzuceniem obu sposobów (statyczność i podkreślony), ale tylko odnośnie drugiego nie było sprzeciwów (nikt nie proponował jego użycia).

1. Myślałem, że to metody są statyczne, czy istnieje coś takiego jak klasa statyczna?
2. Czy prawdą jest że "klasa w której wszystko jest statyczne" to nie klasa?
3. Czy rzeczywiście "klasa w której wszystko jest statyczne" to to samo co przestrzeń nazw?
4. Co ma DI do metod statycznych?
5. Jezeli nie tworzycie obiektów w "danej klasie" to gdzie je tworzycie (pytam nie o teorię jak można to rozwiązać, tylko o wasz "konkretny projekt pisany obiektowo" )?

Oczywiście DI. Dlaczego? Bo jak przykładowo przyjdzie w przyszłości zmienić jakiś fragment systemu to przy korzystaniu z DI co najwyżej ktoś się popłacze, ale nikt się nie powiesi... Wcześniej padły już sensowne argumenty.

@smentek:
1. Istnieją, ale nie w PHP.
2. Technicznie rzecz biorąc klasa to klasa, ale jakby na to jakoś logiczne spojrzeć to tak - klasa z samymi metodami statycznymi to nie klasa.
3. Technicznie nie, ale pod wieloma względami obie te rzeczy są bardzo podobne i mają niemal takie samo zastosowanie.
4. W sumie może z takowych korzystać...
5. "Na zewnątrz" prawdopodobnie w DIC-u

Szczególnie polecam 2 wynik.

@crozin
5. "Na zewnątrz" prawdopodobnie w DIC-u

Masz na myśli IoC który wewnętrzne zamienia ustawienia zapisywane w dajmy na to xml'u i generując z nich klasy? A przepraszam "klasy statyczne" czyli jednak nie klasy. Logicznie rozumując...

eee tam, chodzi o kod miedzy class{} i chyba już o tym pisałem? ;]

Zamiast DIC może być tez Factory.