Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: jedna deklaracja 1 klasy dla wszystkich innych
Forum PHP.pl > Forum > PHP > Object-oriented programming
Spawnm
Witam,

mam klasy mysql,session,panel
wszystkie są deklarowane w pliku index.php

$db=new mysql($dbhost,$dbuser,$dbpass,$dbname);
$session=new session();
itp...

i teraz pytanie :
co zrobić aby mysql był dostępny w innych klasach bez ponownej deklaracji / łączenia?
nospor
skorzystac ze wzorcow projektowych, np:
Rejestr
od biedy Singleton
mls
To już zależy tylko od metody jaką utworzony zostanie inny obiekt. Jeśli kolejny obiekt będzie rozszerzeniem obecnego (deklarującego połączenie z bazą danych) to nie trzeba robić nic, by w klasach-dzieciach zmienna istniała (chyba, że będzie to zmienna typu private). Zarówno do singletona jak i rejestru trzeba się w każdej klasie w jakiś sposób odwoływać.
Morkai
Cytat(mls @ 26.03.2009, 00:55:17 ) *
to nie trzeba robić nic

Trzeba zadeklarować zmienną jako statyczną. Najgorsze rozwiązanie z możliwych.

Jak chcesz wykorzystać inny obiekt to po prostu go przekazujesz, nie?

$db=new mysql($dbhost,$dbuser,$dbpass,$dbname);
$session=new session($mysql);
itp...
zzeus
Polecam wzorzec Registry, o którem już wspomniano wcześniej.
Przykład Zend_Registry
Spawnm
Cytat(Morkai @ 26.03.2009, 12:49:45 ) *
Trzeba zadeklarować zmienną jako statyczną. Najgorsze rozwiązanie z możliwych.

Jak chcesz wykorzystać inny obiekt to po prostu go przekazujesz, nie?

$db=new mysql($dbhost,$dbuser,$dbpass,$dbname);
$session=new session($mysql);
itp...


chyba nie
  1. <?php
  2. $db=new mysql($dbhost,$dbuser,$dbpass,$dbname);
  3. $session=new session($mysql);
  4. ?>

tylko
  1. <?php
  2. $db=new mysql($dbhost,$dbuser,$dbpass,$dbname);
  3. $session=new session($db);
  4. ?>

smile.gif
Robiłem tak , ale to jest dobre do małych stron z 1-2 klasami , w większych projektach jest to już trochę słabe rozwiązanie...
Fifi209
Racja bardzo słabe. Ja rozwiązałem ten problem przy swoim projekcie w sposób prosty. Klasa mysql jest u mnie klasą w pełni statyczną. Nie posiada więc konstruktora ani destruktora, za to działa wszystko ładnie. ;d
starach
Cytat(fifi209 @ 26.03.2009, 16:55:17 ) *
Racja bardzo słabe. Ja rozwiązałem ten problem przy swoim projekcie w sposób prosty. Klasa mysql jest u mnie klasą w pełni statyczną. Nie posiada więc konstruktora ani destruktora, za to działa wszystko ładnie. ;d
Robienie sterowników dostępu do danych na obiektach statycznych to masochizm. Zobacz sobie jaka fajna wariacja singletona ( chociaż możliwe że ma to własną nazwę ) jest w ORM o nazwie Doctrine. Wracając do tematu. Pisząc własny framework testowałem bardzo dużo sposobów przekazywania danych. forum.php.pl nawróciło mnie na wzorzec projektowy Context chociaż Registry też ma kilka zalet. Proponowałbym ci dogłębne zbadanie obu wzorców i wybranie tego który najlepiej tobie odpowiada.
Fifi209
Cytat(orglee @ 26.03.2009, 18:02:05 ) *
Robienie sterowników dostępu do danych na obiektach statycznych to masochizm. Zobacz sobie jaka fajna wariacja singletona ( chociaż możliwe że ma to własną nazwę ) jest w ORM o nazwie Doctrine. Wracając do tematu. Pisząc własny framework testowałem bardzo dużo sposobów przekazywania danych. forum.php.pl nawróciło mnie na wzorzec projektowy Context chociaż Registry też ma kilka zalet. Proponowałbym ci dogłębne zbadanie obu wzorców i wybranie tego który najlepiej tobie odpowiada.


Masochizm ? Czemu tak uważasz ?
Ja porobiłem takie metody aby było mi jak najbardziej wygodnie, przed wykonaniem jakiejkolwiek metody czy to select czy update sprawdzam czy mam połączenie z mysql, jeżeli nie to rzucam wyjątkiem. ;p
starach
To pokaż chociaż prototypy metod.
Fifi209
http://rafb.net/p/qkKxdy33.html

Musiałem dać na rafb bo nie było tutaj wcięć.

(stara wersja mojej klasy, gdzieś wydłubałem. Uuu tak patrzę na to nawet wyjątków nie rzucałem i te metody prawie nie rozbudowane)
starach
Przede wszystkim nie obsłużysz w ten sposób dwóch rożnych baz albo tej samej z różnymi uprawnieniami. Następnie zwracasz select z tablicy asocjacyjnej. Dobre to było przy PHP 4. No i głównym zarzutem jest to że w każdej metodzie musisz sprawdzać czy masz połączenie. To jest po prostu nie do zaakceptowania.

Spawnm odpowiem tutaj.
http://www.symfony-project.org/api/1_2/sfContext
Fifi209
Cytat(orglee @ 26.03.2009, 20:39:14 ) *
Przede wszystkim nie obsłużysz w ten sposób dwóch rożnych baz albo tej samej z różnymi uprawnieniami. Następnie zwracasz select z tablicy asocjacyjnej. Dobre to było przy PHP 4. No i głównym zarzutem jest to że w każdej metodzie musisz sprawdzać czy masz połączenie. To jest po prostu nie do zaakceptowania.

Spawnm odpowiem tutaj.
http://www.symfony-project.org/api/1_2/sfContext


Jakbym się uparł to może i bym obsłużył 10 baz. Lecz nie jest mi to potrzebne. Korzystam z mysql, czasem z musu z postgresql.
mls
Cytat(Morkai @ 26.03.2009, 13:49:45 ) *
Trzeba zadeklarować zmienną jako statyczną. Najgorsze rozwiązanie z możliwych.

Jak chcesz wykorzystać inny obiekt to po prostu go przekazujesz, nie?


No chyba nie do końca zrozumiałeś moją wypowiedź. Miałem na myśli coś takiego:
  1. <?php
  2. class test1
  3. {
  4.    protected $db;
  5.  
  6.    public function __construct ()
  7.    {
  8.        $this->db = new pdo(...); // czy cokolwiek innego do bazy danych
  9.    }
  10. }
  11.  
  12. class test2 extends test1
  13. {
  14.    public function test()
  15.    {
  16.        print_r($this->db);
  17.    }
  18. }
  19.  
  20. $test = new test2();
  21. $test2->test();
  22. ?>
Morkai
Cytat(fifi209 @ 26.03.2009, 15:55:17 ) *
Racja bardzo słabe.

Oczywiście nikt w świecie PHP nie słyszał o dependency injection.
mike
Cytat(Morkai @ 30.03.2009, 23:45:38 ) *
Oczywiście nikt w świecie PHP nie słyszał o dependency injection.
Nie wymagaj zbyt wiele biggrin.gif
Springa nie zbudujesz w PHP, ale uważaj bo zdziwić się możesz: Lion PHP Framework (IoC based PHP framework).
destroyerr
Oczywiście, że ktoś słyszał o di w php. Na przykład tak jak mike podał wyżej, jest też kilka projektów di w php (Crafty, PicoContainer i jeszcze jakiś). Zend Framework ma gdzieś w wersji rozwojowej (czy jak to tam jest) Zend_Di.
No i najważniejsze, Symfony w wersji 2 też będzie mieć, choć na chwilę obecną już jest tworzony, tylko jako osobny komponent. Więcej informacji, jest tam też link do prywatnego bloga, gdzie DI jest opisywany, więc polecam zapoznać się z tymi materiałami.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.