![]() |
![]() |
![]() ![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 87 Pomógł: 3 Dołączył: 15.08.2009 Ostrzeżenie: (0%) ![]() ![]() |
Witam, tworzę zalążek aplikacji, która będzie obsługiwać inne aplikacje.
Stanąłem nad jednym zagadnieniem, możliwe że moje ubytki wiedzy wiążą się z małym niedoinformowaniem. Otóż. Tworzę sobie loader całej aplikacji. Plik index.php wygląda miej więcej tak że wywołuje klasę EngineInit, a w niej funkcję EngineStart. W klasie EngineInit, w func EngineStart ładuję odpowiednie klasy, które własnie tworzę. Dopowiednio jest to obsługa sesji, obsługa debugowania aplikacji, obsługa aplikacji, obsługa baz danch i inne Problem polega na tym że chcę kożystać z tych obiektów tak:
Problem polega na tym że chcę użyć np. obiektu $conf w $db lub w $session i np. $db w $session.. Global nie działa (IMG:style_emoticons/default/ohno-smiley.gif) Ma ktoś pomysł jak to rozwiązać? Proszę o naprowadzenie (IMG:style_emoticons/default/smile.gif) |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 2 178 Pomógł: 596 Dołączył: 25.09.2009 Skąd: Piwniczna-Zdrój Ostrzeżenie: (0%) ![]() ![]() |
Koledze nie o to chodzi, czy i gdzie wykorzystać singleton. Jeśli nawet wykorzysta ten wzorzec, to nadal jego problem nie będzie rozwiązany.
@zielu001: Z Twojego opisu wynika, że klasa EngineInit jest niejako klasą główną, a metoda EngineStart ma zainicjować konfigurację, bazę danych i sesje, z których później będziesz korzystał. Jednak w kodzie, który nam pokazałeś tworzysz tylko zmienne lokalne, działające w obrębie metody EngineStart. Nie będziesz miał zatem możliwości posługiwania się nimi później. Dlatego klasa mogłaby/powinna wyglądać nieco inaczej:
Teraz przejdźmy do meritum. Jeśli obiekt klasy DatabaseLoader (i tutaj nieważne, czy jest to singleton, czy nie), czy też klasy SessionLoader musi skorzystać z danych zawartych w obiekcie klasy ConfigurationInit, to trzeba te informacje przekazać. Jak to zrobić? Otóż można posłużyć się "mechanizmem" DI (dependency injection, wstrzykiwanie zależności). Metoda EngineStart wyglądałaby zatem trochę inaczej:
Teraz konstruktory klas DataBaseLoader i SessionLoader mogą skorzystać z informacji, jakie "posiada" obiekt klasy ConfigurationInit. Gwoli dopełnienia formalności uzupełnijmy dla przykładu klasę DataBaseLoader:
Innym "mechanizmem" jest Dependency Non-Injection (uzależnianie bez wstrzykiwania). Mechanizm ten polega na zainicjowaniu "na sztywno" obiektu klasy, z której potrzebujemy skorzystać. Tak mogłaby wyglądać klasa DataBaseLoader wykorzystująca Dependency Non-Injection
O tym, który z przedstawionych mechanizmów wybrać musisz zdecydować sam. Dependency Injection daje nam sporą elastyczność, ponieważ przekazywane obiekty nie muszą być obiektami dokładnie jednej klasy, choć muszą spełniać założenia pewnych wzorców, które nazywamy interfejsami. Dependency Non-Injection samo w sobie nie zapewnia nam żadnej elastyczności i wymusza na nas korzystnie z dokładnie takiej, a nie innej klasy (czasami jednak właśnie tego potrzebujemy). Wszystkie napisane wyżej klasy, to tylko przykłady. W rzeczywistości konstruktor klasy obsługującej połączenie z bazą danych nie potrzebuje wszystkich danych konfiguracyjnych, a tylko niektórych (tzn. nazwa/adres serwera, nazwa i hasło użytkownika bazy danych, czy kodowanie połączenia). Wystarczyłoby zatem przekazać konstruktorowi klasy DataBaseLoader tablicę zawierającą wymagane dane, a nie cały obiekt klasy ConfigurtionInit. EDIT1: Poprawiłem parę literówek, ale chyba jeszcze jakieś są. EDIT2: Problem i jego rozwiązanie z dziedziczeniem nie mają nic wspólnego. Ten post edytował mortus 28.03.2012, 16:31:14 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 21:11 |