Statyczne klasy vs Dependency Injection Opcje

[Inscure]

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ć ;]

Ten post edytował Inscure 6.05.2011, 19:56:36

[wookieb]

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

Powód edycji: [wookieb]:

[Zyx]

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.

[Bags_Bunny]

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ć?

[Inscure]

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.

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

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

[Bags_Bunny]

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.

[Inscure]

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).

[smentek]

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" )?

[Crozin]

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

Ten post edytował Crozin 12.05.2011, 18:55:17

[pejott]

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

Szczególnie polecam 2 wynik.

[smentek]

@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...

[Inscure]

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

[sarxos]

Zamiast DIC może być tez Factory.