PDO i współpraca z własnymi klasami Opcje

[Jawor]

Witam

Mam pytanie odnośnie współpracy PDO z własnymi klasami.

Ktory sposob powinno sie uzywac:

1. Polaczenie z baza poza klasa (wlasna) i przekazywanie do niej obiektu typu PDO. Wszystkie zapytania, operacje na danych z bazy odbywaja sie we wlasnej klasie.

2. Wszystkie operacje zwiazane z baza odbywaja sie poza wlasna klasa (zapytania, pobieranie danych), a do mojej klasy przekazuje juz np. pobrane z bazy dane.


Do tej pory caly czas pisalem strukturalnie, ale postanowilem to zmienic i oto pierwszy dylemat jaki napotkalem na swojej drodze (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował Jawor 9.11.2008, 16:27:35

[markac]

Sorry orglee, ale ja już wolę __autoload. W systemie nie powinny wystąpić klasy o tych samych nazwach i dlatego ryzyko kolidowania klas spada do minimum. Przykład:

Andrew: 03-Nov-2006 12:26

[PHP] pobierz, plaintext 
<?php
    function __autoload($class_name)
    {
        //class directories
        $directorys = array(
            'classes/',
            'classes/otherclasses/',
            'classes2/',
            'module1/classes/'
        );
       
        //for each directory
        foreach($directorys as $directory)
        {
            //see if the file exsists
            if(file_exists($directory.$class_name . '.php'))
            {
                require_once($directory.$class_name . '.php');
                //only require the class once, so quit after to save effort (if you got more, then name them something else
                return;
            }           
        }
    }
?>
[PHP] pobierz, plaintext 

Mamy w ten sposób także uzupełnianie kodu w Eclipse, oczywiście jeśli zastosujemy odpowiednie tagi dokumentujące same klasy. Co do Registry, chyba Ty to napisałeś, że istnieje możliwość nadpisania? Mylisz się. W takich przypadkach nie stosuje się get() i set(), a odpowiednio nazwane metody, np. getPDO(), getSession(). Mamy w ten sposób załatwione także uzupełnianie kodu i wykluczenie możliwości nadpisania kodu. Samo zastosowanie get i set jest to po prostu lenistwem, niedoświadczeniem i posiadaniem złych nawyków, o dziwo, dotyczy tylko programistów PHP?

Ten post edytował markac 3.12.2008, 09:27:06

[starach]

Sorry orglee, ale ja już wolę __autoload. W systemie nie powinny wystąpić klasy o tych samych nazwach i dlatego ryzyko kolidowania klas spada do minimum.

Nie ma możliwości że wystąpią.

[PHP] pobierz, plaintext 
<?php
$ob = Instance::Get('library.template.cache.data.package.collection');
?>
[PHP] pobierz, plaintext 

Kod załaduje plik w katalogu "[projekt_root]/library/Template/Cache/Data/Package/Collection.php" ( wielkość liter nieprzypadkowa ) i utworzy obiekt klasy Template_Cache_Data_Package_Collection lub zwróci go z rejestru jeśli był już utworzony wcześniej.
W zmiennych klasowych stosuję nazewnictwo rozróżniające czy dana zmienne jest obiektem czy prymitywem ( $this->counter - obiekt $this->_counter = integer / float / double / etc. ). Mimo to nie wyobrażam sobie żeby nie napisać PHPDoc'owego @var celem lepszej czytelności i przejrzystości.

Co do Registry, chyba Ty to napisałeś, że istnieje możliwość nadpisania? Mylisz się. W takich przypadkach nie stosuje się get() i set(), a odpowiednio nazwane metody, np. getPDO(), getSession(). Mamy w ten sposób załatwione także uzupełnianie kodu i wykluczenie możliwości nadpisania kodu. Samo zastosowanie get i set jest to po prostu lenistwem, niedoświadczeniem i posiadaniem złych nawyków, o dziwo, dotyczy tylko programistów PHP?

Stosowanie setterów i getterów dla poszczególnych obiektów moim zdaniem nie jest wygodnym rozwiązaniem bo kompletnie burzy intuicyjność frameworka. Jest to coś czego nienawidzę na przykład w Joomli. Różnica między zaproponowanym przez ciebie rozwiązaniem i Jomlowym jest taka, że Joomla ma statyczne gettery w swoim rejestrze. Nazywam to singleton overflow. (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Ten post edytował orglee 3.12.2008, 16:56:43

[Black-Berry]

Stosowanie setterów i getterów dla poszczególnych obiektów moim zdaniem nie jest wygodnym rozwiązaniem bo kompletnie burzy intuicyjność frameworka. Jest to coś czego nienawidzę na przykład w Joomli. Różnica między zaproponowanym przez ciebie rozwiązaniem i Jomlowym jest taka, że Joomla ma statyczne gettery w swoim rejestrze. Nazywam to singleton overflow. (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Sory trochę zgubiłem się w temacie ale czy stosowanie getterów i setterów jest takie niezbędne do rozwiązania kontekstowego? Przecież wszystko można oprzeć o jakieś dziedziczenie. Gdzieś już tutaj pisałem o tym razem z przykładowym kodem. Każdy obiekt dziedziczący po obiekcie klasy Core_Context automatycznie może ustawiać sobie obiekty wymagane. Jeśli już chcemy wszystko zautomatyzować to poprostu każdy obiekt w naszym frameworku traktujemy jako Core_Object i po krzyku. Takie coś:

[PHP] pobierz, plaintext 
<?php
$ob = Instance::Get('library.template.cache.data.package.collection');
?>
[PHP] pobierz, plaintext 

Może i jest pomysłowe ale czy istnieje w jakimkolwiek poważnym oprogramowaniu? Wiem, że PHP można różnie traktować ale wydaje mi się że uniwersalne rozwiązania są najlepsze. Nawet jeśli nikt nie ma pracować w przyszłosci na Twoim kodzie tylko ty sam to trzeba dążyć do czegoś co akceptuje większość społeczności programistycznej nie tylko ta z PHP. (Sam mam jeszcze masę nietrafionych rozwiązań w swoim frameworku ale systematycznie je poprawiam. Nie piszę tutaj żeby komuś coś wytykać)

Pozdrawiam.

[markac]

Sory trochę zgubiłem się w temacie ale czy stosowanie getterów i setterów jest takie niezbędne do rozwiązania kontekstowego? Przecież wszystko można oprzeć o jakieś dziedziczenie. Gdzieś już tutaj pisałem o tym razem z przykładowym kodem. Każdy obiekt dziedziczący po obiekcie klasy Core_Context automatycznie może ustawiać sobie obiekty wymagane. Jeśli już chcemy wszystko zautomatyzować to poprostu każdy obiekt w naszym frameworku traktujemy jako Core_Object i po krzyku. Takie coś:

Nie obrażając nikogo, ale nie masz pojęcia o programowaniu obiektowym... Co ma np. wspólnego klasa DB (np. PDO) z klasą powiedzmy Kota? Używając dziedziczenia (Kot dziedziczy po DB), dajesz do zrozumienia, że klasa kota jest klasą rozszerzającą mozliwosci klasy DB, co jest nieprawdą.
Do tego pozwalasz używać klasę Kota tak, jakby to była klasa DB... I teraz prosty przykład:

[PHP] pobierz, plaintext 
<?php
if ($kot instanceof $db)
  echo "to jest klasa db";
?>
[PHP] pobierz, plaintext 

Trochę to dziwne? Rozumiem, że kot może być klasą pochodną klasy Zwierzak, a ten z kolei klasy Ssak, ale nie WTC na miłość boską, chociaz nikt Ci tego nie zabroni (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Przepraszam za takie łopatologiczne przykłady, ale nie umiem tłumaczyć. Najlepiej zacząć rozpisywać to w UML, wtedy ujrzysz, że to nie ma sensu. Każdy początkujący programista próbuje wyprowadzać z klasy np. MySQL następne klasy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Ten post edytował markac 4.12.2008, 18:54:05