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

Przekazuj obiekt PDO i wykorzystuj go w klasach służących do interakcji z danymi w bazie; w tzw. modelach.

Najprostszy przykład:

[PHP] pobierz, plaintext 
<?php
class News
{
    protected $pdo;
 
    public function __construct(PDO $pdo)
    {
        $this->pdo = $pdo;
    }
 
    public function getAllNews()
    {
        $statement = $this->pdo->query('SELECT * FROM news');
        return $statement->fetchAll();
    }
 
    // etc
}
?>
[PHP] pobierz, plaintext 

Są oczywiście lepsze rozwiązania

Edit:

Klasa news nie powinna mieć nic wspólnego z prezentacją danych.
Może pobierać, kasować i zmieniać newsy w bazie, ale na przykład nie może wypluć HTML.

Rozwiniesz ?

Możesz przekazywać do klasy jakiś obiekt, który przetrzymuje w sobie więcej rzeczy niż samo PDO.

[PHP] pobierz, plaintext 
<?php
class News
{
   protected $context;
 
   public function __construct(Context $context)
   {
       $this->context = $context;
   }
 
   public function getAllNews()
   {
       // context może przekazać obiekt PDO.
       // Możesz w nim trzymać również inne obiekty związane z Twoim systemem, jak
       // loggery błędów lub translatory
       try {
           $statement = $this->context->getPDO()->query('SELECT * FROM news');
           return $statement->fetchAll(); // model przekazuje czyste dane.
       catch (Exception $e) {
           // logujesz błąd
           $this->context->getLogger()->log($e->getMessage());
       }
       return false; // nie udało się pobrać newsów.
   }
 
   // etc
}
?>
[PHP] pobierz, plaintext 

Ok. Dzieki za pomoc.

Pozdrawiam

Z ostatnich testów i odrobiony teoretyzowania wyszło mi że nie bardzo opłaca się przekazywać context w konstruktorze bo wyobraźmy sobie następującą systuację:

[PHP] pobierz, plaintext 
<?php
    $context = new Context(); // obiekt $context nie zawiera listy obiektów
    $config = New Config($context); // obiekt $config dopisuje sam siebie do obierktu $context;
    $log = New Log($context); // obiekt $context zawiera teraz $config + $log;
    $dbDriver = new Db_Driver($context) // w tym miejscu $context ma juz 3 obiekty;
?>
[PHP] pobierz, plaintext 

I teraz przykłąd użycia $log'u wewnątrz metody $dbDrver'a

[PHP] pobierz, plaintext 
<?php
    (..)
    public function printLoggedErrors()
    {
        $this->log->printErrors(QUERY_ERRORS); //ten przykład zadziała bezproblemowo;
    }
    (..)
?>
[PHP] pobierz, plaintext 

problem pojawia się kiedy chcemy za pomocą $log'u wywołać $dbDriver. Systuacja taka przytrafia się jeśli log ma zapisać cos do bazy danych. Ponieważ $dbDriver został utowrzony po obiekcie $log, log nie moze z niego korzystać.

Rozwiązaniem tego może więc być metoda ustawiająca context:

[PHP] pobierz, plaintext 
<?php
    $context = new Context();
    $config = New Config();
    $log = New Log();
    $dbDriver = new Db_Driver();
    //inicjowanie kontextu:
    $config->setContext($context);
    $log->setContext($context);
    $dbDriver->setContext($context);
?>
[PHP] pobierz, plaintext 

Proszę o komentarz do takiego rozwiązania ponieważ ciągle jeszcze staram się to udoskonalić.

Prędzej

[PHP] pobierz, plaintext 
<?php
$context = new Context();
$context->setDbDriver($dbDriver);
$context->setLogger($logger);
 
// a potem
 
$controller = new News_Controler();
$controller->setContext($context);
 
// albo
 
 
$model = new NewsModel();
$model->setContext($context);
?>
[PHP] pobierz, plaintext 

A nie tak:

[PHP] pobierz, plaintext 
<?php
$context = new Context();
    $context->setDbDriver($dbDriver = new dbDriver);
    $context->setLogger($logger = new Logger);
?>
[PHP] pobierz, plaintext 

?

Czy nie jest wadą, że obiekty $dbDriver i $log będą niewidoczne dla całej apilikacji? Wygodne byłoy przecież w stopce aplikacji wywyołać sobie np:

[PHP] pobierz, plaintext 
<?php
    $log->printErrors();
?>
[PHP] pobierz, plaintext 

a nie:

[PHP] pobierz, plaintext 
<?php
    $someControlerOrModel->log->printErrors();
?>
[PHP] pobierz, plaintext 

Ja za stopkę aplikacji uważam na przykład ostatni filtr kontrolera (coś jak pluginy front controlera w zendzie) i tam tez mam dostęp do kontekstu.

Jest hermetycznie, poza aplikacja nie ma dostępu do żadnych driverów, loggerów etc.

Racja. Twoje rozwiązanie jest bardziej eleganckie.

pozdrawiam.

Dajcie już spokój z tymi kontekstami i kopiowaniem wszystkiego z Javy... Ja do tego wykorzystuje wzorzec Registry.

[PHP] pobierz, plaintext 
<?php
class ApplicationRegistry extends Registry {
    private static $instance;
      private $values = array();
      
    private function __construct() {
    }
    
    /**
     * Enter description here...
     * @return ApplicationRegistry
     */
    public static function getInstance() {
      return self::$instance ? self::$instance : self::$instance = new self();
    }
      
    /**
     * Gets PDO Database Access
     * @return PDO
     */
    public static function getPDO() {
      return self::getInstance()->get('pdo');
    }
    
    public static function setPDO($object) {
      if ($object instanceof PDO)
        self::getInstance()->set('pdo', $object);
      else
        throw new Exception('Obiekt musi być instancją klasy PDO.');
    }
      
  }
?>
[PHP] pobierz, plaintext 

Wywołanie:

[PHP] pobierz, plaintext 
<?php
$pdo = ApplicationRegistry::getPDO();
?>
[PHP] pobierz, plaintext 

Rejestr to tylko niechlujność architektów :/

Przeczy hermetyzacji OOP. Po to mam obiekt kontekstu, żeby go przekazywać gdzie chcę, a tam, gdzie nie - to go nie ma.



A nie wiesz, że poniekąd z Javy wywodzą się najlepsze praktyki programistyczne?

Singletony są złe. A poza tym działają wolniej niż context.

@BlackBerry:
A czy przypadkiem nie jest tak, że context powinien być singletonem? Przykład:
http://www.symfony-project.org/api/1_1/sfC...hod_getinstance
Chyba nie powiesz, że Symfony projektowały osoby nie znające się na OOP...

No i w tym momencie masz z poziomu szablonu dostęp do bazy, o! A nie powiesz mi chyba, że to dobrze?


Zrobili to dla wygody tylko.

edit

Wynika to z architektury Mojavi, gdzie aplikacja jest uruchamiana z poziomu kontekstu, a ten trzeba jakoś pozyskać.

Tak się składa, że obiekt bazy danych ma być dostępny w większości przypadków wszędzie i przekazywanie tego uchwytu do każdego obiektu, np. przez konstruktor to dla mnie przerost formy nad treścią. A jak byście nie wiedzieli, kontekst także jest singletonem, czyli co, źle? Ależ skąd. Kontekstu nie używa się tylko po to, żeby zapewnić dostęp dostęp do wspólnych obiektów, które posiadają tylko jedną instancję. Używa go się tam, gdzie zachodzi możliwość uruchomienia skryptu w innym środowisku (kontekście), że tak to ujmę W tym wypadku kontekst wykorzystujecie tylko i wyłącznie do przekazania obiektu bazy danych i ja mówię temu nie. Lepszym rozwiązaniem jest dla mnie w tym wypadku Rejestr, ale jak kto woli...

Dlaczego na miłość Boga kontekst miałby być singletonem Dlaczego mielibyśmy przekazywać coś w konstruktorach ?

[PHP] pobierz, plaintext 
<?php
//creating core objects...
    $config = new Config();
    $log = new Log();
    $dbDriver = new Db_Driver();
    $session = new Session();
    
    //creating context...
    $context = new Core_Context();
    $context->setConfig($config);
    $context->setLog($log);
    $context->setDbDriver($dbDriver);
    $context->setSession($session);
    
    //setting context...
    $log->setContext($context);
    $dbDriver->setContext($context);
    $session->setContext($context);
?>
[PHP] pobierz, plaintext 

Kto Ci powiedział, że obiekt kontekstu ma być wszędzie?

To ja napiszę tak i się powtórzę - singletony PRZECZĄ hermetyzacji. Idealna aplikacja powinna wyglądać tak, że ją odpalasz jakimś obiektem aplikacji i koniec, wszystko się dzieje wewnątrz, a ty nie masz do niczego dostępu, zarazem zachowując pełną kontrolę.

Niech szlak trafi ZF za rozpropagowanie tego cholernego wzorca. Zrobili zbiór klas, które działają tak luźno, że nie sposób nie korzystać z rejestru.

Nie po to w architekturze oprogramowania wymyśla się nieprzepuszczalne warstwy (czyli nie mówię tylko o MVC), żeby jakiś rejestr odstawił wszystko do lamusa. Weźmy na przykład aplikacje GUI, które trzymają się MVC - gdyby we frameworkach wspomagających tworzenie takiego oprogramowania warstwy by rzeczywiście na siebie nie zachodziły to by było super - a tak nadal się zdarza, że żółtodziub siada do klawy i zasysa dane bezpośrednio w akcji np. Button.onClick (co zasadniczo jest widokiem, a raczej szablonem jeżeli przerzucić to na myślenie WWW).

Rejestr to taki kontekst dla leniwych.

troche odgrzewam temat, ale przyznam, że cos mnie gryzie
jak poinien wygladac element, ktory jest trzymany jako $context?

[PHP] pobierz, plaintext 
<?php
$this->context->getPDO()->query('SELECT * FROM news');
?>
[PHP] pobierz, plaintext 

bo z tego co rozumiem, $context to klasa, ktora zawieta min jakies odwolnie do PDO.
czy nie lepiej przed wywolaniem instancji naszej klasy News() wywoalac instacje od PDO() i pozniej przekazac uchwyt do News() ?
Sory, jesli cos pomieszalem, ale to moje poczatki w oop

Tak też można, jeżeli nie chcesz by News miał dostęp do czegokolwiek innego niż PDO to możesz o tak:

[PHP] pobierz, plaintext 
<?php
class Model
{
    private $context;
    
    public function initialize(Context $context)
    {
        $this->context = $context;
    }
 
    protected function getPDO()
    {
        return $this->context->getPDO();
    }
}
 
 
class News extends Model
{
     public function getAllNewsByPage($page)
     {
         $pdo = $this->getPDO();
         // tutaj robisz selecty etc.
     }
}
?>
[PHP] pobierz, plaintext 

Kolego, nie bulwersuj się tak... nikt tu nie pisał, że kontekst ma być widoczny wszędzie, a dobrze by było aby uchwyt do bazy był. Co do idealnej aplikacji, to jeszcze taka nie powstała, więc zejdź na ziemię, bo popadasz w pewien wir, jak każdy, który dopiero co zachłysnął się wzorcami projektowymi. Aplikacja ma przede wszystkim działać i nie powinna być przekombinowana. Nie opowiadaj też o aplikacjach typowo desktopowych, bo mówimy o innym zastosowaniu. MVC nie powstał dla www! Nie da się w pełni zaimplementować wzorca MVC na potrzeby strony www! Na tą okoliczność powstał Model 2 i używajmy odpowiedniego nazewnictwa.



Znowu popadamy w obsesję? Wiadomym jest, że jeśli szablon jest wykonany w PHP to mamy dostęp do rożnych rzeczy, do których mieć byśmy nie chcieli, prawda? Przecież nic nie stoi na przeszkodzie, żebym utworzył np. nową instancję np. front controlla (o ile nie korzysta z singletona, których używania nie popierasz!). Co mnie przed tym powstrzyma? A co z innymi zmiennymi globalnymi i samym global? Jak się zabezpieczysz na tą okolicznosc, że coś nadpisze? Może w ogóle zrezygnować z szablonów w PHP i zrobić coś ala BBCode? Powtarzam, nie ma idealnej aplikacji. KOMPROMIS KOMPROMIS KOMPROMIS.

Kolego

Doświadczenie i styczność z dobrze zaprojektowanym kodem, nie zachłyśnięcie. Aplikacja przekombinowana być nie musi, ale to co pod Nią leży jak najbardziej - w tym tkwi siła. I nie zgadzam się, że uchwyt powinien być widoczny wszędzie - perzystencja powinna być izolowana od pewnych części aplikacji inaczej będą problemy.

Przecież Model 2 to wariacja MVC, ale wciąż MVC tak samo HMVC, MVC-pull/push etc. Więc też nie szastaj nomenklaturą.

Ja nie piszę o programiście idiocie kolego, tylko takim, który nie do końca wie co jest dla Niego dobre.

oraz

Da się napisać FC o jakim piszesz bez Singletona.

GLOBALi... nie używaj albo się potem męcz.

Przeczytałeś to w ogóle??

Jedno nie wyklucza drugiego. Jak mam kontrolę nad całym kodem, to mam pisać z globalami bo tak wygodniej?
Wiem, że czasami się nie da i właśnie to jest przyczyną wielu straconych godzin k***ienia na klawiaturą

Pozdrawiam, Alan

Dołączę się do tematu. Jak napisać obsługę DB tak aby nie korzystać z singletona i registry ? Jak złapać uchwyt? Czy po prostu zrobić tak aby router wywołując daną klasę przekazywał do niej uchwyt ?

Możesz też zrobić tak (rozwiązanie raczej nieeleganckie, ale jedno z możliwych )

[PHP] pobierz, plaintext 
<?php
class News {
 
public function __construct()
{
  global $pdo;
  $this->pdo = $pdo;
}
public function GetAll()
{
 return $this->pdo->query("SELECT * FROM `news` ORDER BY `id_news` DESC");
 
}
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam.

Przeczytaj cały wątek i potem swój kod.

Ale o co tu sie spieramy, czy to jest dobre, że np. w szablonie możemy zrobić coś takiego...

[PHP] pobierz, plaintext 
<div id="foo">
 
<?php Registry::getInstance()->Get('DB')->Execute( ... ); ?>
 
</div>
[PHP] pobierz, plaintext 

Skoro ma to być możliwe to po co te warstwy, jak widok grzebie w bazie.



To po co pisać obiektowe frameworki, skoro można napisać prawie wszystko strukturalnie. PHP4 wita.

ok, ale jakie elemnty sa godne umieszczenia tam? moze jakas funkcja od bbcode, czy cos innego?
nie wiem, co tam jeszcze moze sie nadawac (stad sie wzielo to moje pytanie powyzej)

To co Ci będzie potrzebne ?
Skąd mamy wiedzieć co tam umieścić skoro nie wiemy co chcesz osiągnąć ?

fakt... troche nie sprecyzowalem...
juz nie bede drazyc tego watku, bo robie offtop

Ot, i najlepiej jeszcze podciągnijcie pod to walkę o wolność tybetu i ochronę pingwinów w okresie godowym.

Owszem, dobre praktyki dobrymi praktykami, ale autor tematu zapytał się, jak lepiej opracować połączenie z bazą danych. A wy jak w niemal każdym wątku na forum zaczynacie walkę w stylu Singleton <> Registery <> Context <> FooBar. Ludzie - to wszystko jest tworzone po to, aby ułatwiać życie, a nie komplikować. Podstawową zasadą każdego programu/skryptu jest to, ze ma działać dobrze i wydajnie. Jak ktoś to potrafi osiągnąć w inny sposób to nie znaczy, że ten sposób jest z zły. W PHP przecież i tak jest sporo niespójności w samym języku, więc samobiczowanie się tak ciągle i tak wcale nie sprawi, że wszystko będzie super .

I co do mnie prywatnie, tak wracając do tematu, to do połączeń z bazą danych używam swojej klasy, która po prostu dziedziczy po PDO i ustawiam ją w rejestrze. Uważam, że nie ma potrzeby pałować się z jakimiś elokwencjami w przekazywaniu wszędzie tej instancji - na poziomie modelu/kontrolera i tak będzie ona potrzebna niemal wszędzie, więc ciągłe dopisywanie tego samego jest bez sensu - po to stworzone pewne konstrukcje, żeby zadania automatyzować.

@wrzasq Zgadzam się z tobą. Co byś nei zrobił zawsze zostanie niedosyt ale żeby nie było niedomówień:

Jeśli masz jeden obiekt główny po którym dziedziczą inne to ustwaiasz kontekst za pomocą odziedziczonej metody initialize(Context $context); Rejestr ma swoje zalety tak jak i singleton ale jak dla mnie to singleton jest czymś nienormalnym i źle mi się to w głowie układa. Raz miałem serwer z jakąś dziwną wersją PHP i przez tego singletona musiałem klientowi przepisać spory kawałek kodu bo nie chciał działać. Poza tym singleton kojarzy mi się z jakimś "szarlataństwem" programistycznym. To jakaś sztuczka

Pozdrawiam.

Troszkę się zastanawiałem nad tą dyskusją i najpierw doszedłem do wniosku że rejestru faktycznie nie należy używać, mimo iż sam go stosuję.
Z drugiej jednak strony rejestr ( a dokładniej Registry + Abstract Factory, w moim przypadku ) ma jedną niepodważalną zaletę.

Czytelność...

[PHP] pobierz, plaintext 
<?php
// Załaduj plik klasy, utwórz nowy obiekt i nie zapisuj w rejestrze tylko zwróć
$ob = Instance::Get('library.template.cache.data.package.collection', '', Instance::RETURN_INSTANCE);
// Pobierz obiekt z rejestru, ładując plik klasy jeśli nie ma go w rejestrze
$ob = Instance::Get('library.template.cache.data.package.collection');
 
// A mógłbym mieć tak
$ob = new Template_Cache_Data_Package_Collection();
?>
[PHP] pobierz, plaintext 

Moim skromnym zdaniem o wiele czytelniejszy jest mój sposób.
Brak konieczności używania __autoload() / include / require czy przestrzeni nazw.
Oczywiście istnieje cały czas ryzyko nadpisania obiektu w rejestrze przez nieuwagę, ale jest to cena z jaką mogę żyć...
Poza tym zawsze można dodać mechanizm blokowania nadpisania niektórych obiektów. Wczytywanych powiedzmy z pliku konfiguracyjnego.

Wpadłem również na inny pomysł. Dodam do klasy Instance wykrywanie prefiksów - ARI_ oraz ARR_ - do nazw klas. W pierwszym przypadku będzie to informacja żeby Instance zawsze zwracała nową klasę - Always Return Instance. Natomiast w drugim tylko referencję - Always Return Reference. I problem nadpisywania mam niejako z głowy.

Chociaż oczywiście jak to ktoś miał tutaj w sygnaturce "Jeśli ktoś wynajdzie idioto-odporny system, ktoś inny zawsze wynajdzie lepszego idiotę" - Czy jakoś tak - ale tą zasadę można odnieść również do wzorca Context jak i pozostałych. Czyli innymi słowy nie ma rzeczy doskonałych.

[PHP] pobierz, plaintext 
<?php
// Załaduj plik klasy, utwórz nowy obiekt i nie zapisuj w rejestrze tylko zwróć
$ob = Instance::Get('library.template.cache.data.package.collection', '', Instance::RETURN_INSTANCE);
// Pobierz obiekt z rejestru, ładując plik klasy jeśli nie ma go w rejestrze
$ob = Instance::Get('library.template.cache.data.package.collection');
?>
[PHP] pobierz, plaintext 

Yh, i walsnie podpowiadanie skladni (metod, itd) poszlo sie je*****c. Jak dla mnie to MEGA wada. Ja moze pamietam z 5% nazw metod, do tego czesto miewaja dlugie nazwy.
U siebie mam kontekst z glownymi danymi (GET, POST, sesja i inne), do tego kilka singletonow (fabryki ktore musze skonfigurowac raz, a potem tworza mi konkretne obiekty)

Tak coś właśnie czułem że ktoś będzie miał uraz do tego.

Zwróć uwagę na to że ta ścieżka to są katalogi, przedzielone kropkami. Z czego ostatni jest plikiem wczytywanym lub zarówno katalogiem i plikiem wczytywanym. Czyli data.package.collection może być Data/Package/Collection.php albo Data/Package/Collection/Collection.php dzięki temu zamiast wpisywać data.package.package żeby dostać obiekt reprezentujący element kolekcji wpisuję data.package.

Chyba zapamiętasz rozmieszczenie katalogów, patrząc chwilę na drzewo katalogów projektu w edytorze.
Reszta to tylko kwestia szybkości pisania na klawiaturze. A sądząc po tym forum przeciętna prędkość pisania jego użytkowników to dwie klawiatury na rok ^^.

edit>
Co do metod to też miałbym z tym problemy. Jednak składnia PHPDocumentator'a rozwiązuje ten problem.
Używa jej w mechanizmie podpowiadania składni np. Zend Studio czy PHP Eclipse. A założę się że nie są to wszystkie kombajny które to obsługują.
Jedynym tego mankamentem jest konieczność korzystania z minimum 4 linijkowej deklaracji zmiennych klasowych.

edit>>
Może niech któryś przeciwnik Rejestru wrzuci tutaj przykładową klasę, a ja ją chętnie napiszę po swojemu.
Tak naprawdę sam nie jestem do końca przekonany co do słuszności mojego rozwiązania i chętnie bym je sprawdził nieco dokładniej.

Rozmieszczenie to nie problem, szczegolnie ze nazwa klasy == katalog.

Ale! Nie bede pamietal nazw tysiaca metod jakie zdefiniowalem: http://a1.s3.p.quickshareit.com/files/picture2e92b0.png

a u ciebie trace informacje jakiej klasy to obiekt, wiec nie moge skorzystac z podpowiadania metod.

Heh. Edytowałem post przy użyciu szybkiej edycji i nie zauważyłem że odpowiedziałeś wcześniej.



edit>
Dodatkowo ZS ma jeszcze inny rodzaj podpowiadania składni

[PHP] pobierz, plaintext 
<?php
$ob = Instance etc.
/* @var $ob Moj_Przefajny_Obiekt */
$ob->typeHintingJakTaLala()
?>
[PHP] pobierz, plaintext 

No my tu gadu gadu a tutaj już po 4. Dobranoc.
P.S. Chętnie przepiszę jakąś twoją klasę na swój styl. Ciekawość mnie zżera czy nie próbuję wyważyć otwartych drzwi.

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?

@orgle: ZS ma, eclipse nie ma, mi wystarczy jak napisze phpdoc'e od metody - nie chce mi sie dodatkowo dla kazdej zmiennej pisac /* @var */.

@markac

Eh, ja w generatorze mapy (skanuje pliki php i zapisuje w ktorym jest ktora klasa, a aplikacja korzysta potez z samej mapy) mam sprawdzenie czy aby nazwy klas sie nie powtarzaja (ile to godzin kurwowania - czemu tych zmian nie widac; a mialem skopiowane klasy pod nowy modul, ale im nazw nie zmienilem, i nie te klasy sie zalaczaly co mialy )

O kurcze, to ja cały czas piszę w Eclipse i korzystam z czegoś czego on nie ma?
Eclipse również podpowiada składnię w ten sposób.

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.

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.

Przecież ja piszę o statycznych metodach... Co Ci burzy? Jaka intuicyjność? Podawanie ścieżek i nazw po kropce, które w twoim wypadku zajmują cały ekran jest intuicyjne? Pamiętać strukturę katalogów też jest intuicyjne? Zresztą, nikogo na siłe nie będę przekonywał Widać, że programujesz w notatniku, wiec nie widzisz zalet uzupełniania kodu

Uhh ależ mi dopiekłeś. Programuje w notatniku na windowsie 3.11. Chyba pójdę sobie w kącik, cichutko popłakać.
edit>
Co ja gadam. Przecież ja piszę kod na glinianej tabliczce rysikiem. Potem wysyłam do przedszkola, żeby dzieci mi zrobiły kolorowanie składni.
<edit

Pisałem już to w tym temacie co najmniej 2 razy. Dajcie mi kawałek kodu. Przepiszę go po swojemu i każdy będzie mógł sobie porównać co mu jest wygodniej stosować. Cały czas szukam wygodniejszych i wydajniejszych sposobów pisania kodu. Macie okazje przekonać sceptyka. Jeśli wam na tym nie zależy to po co się wdajecie ze mną w dyskusję... Olać mnie po prostu i nie odpisywać.

Chociaż myślałem że forum.php.pl jest miejscem gdzie różne poglądy ścierają się ze sobą i nanoszą. Tworząc nowe i lepsze poglądy oraz rozwiązania.

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.

I tu sie mylisz. Gdyż z tego, co miałem do czynienia z językami programowania, to obiekty oddzielano właśnie poprzez kropki. Takie rozwiązanie jest stosowane choćby w Pythonie. W Javie chyba jest tak samo. A że PHP stosuje kropkę do łączenia stringów i do obiektów można się odwoływać przez "strzałki", to niektórzy programiści robią takie obejścia... :S

Osobiście nie popieram takich rozwiązań w PHP ("kropkowanie").

Tak ale tam jest to rozwiązanie wbudowane a nie parser napisany przez użytkownika. To zasadnicza różnica myślę

Zresztą chodziło mi o ideę pobierania z rejestru obiektów za pomocą stringu a nie sam sposób zapisu. Trochę to... no wiecie... nie pokazałbym tego "na salonach"

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

Klasyczny problem


@Black-Berry, @markac zasadniczo ma rację. Do tego co ty opisujesz używa się interfejsów.

@markac Ja nie mam pojęcia o programowaniu obiektowym?? Skoro tak to ty nie umiesz czytać bo napisałem ze jesli ktoś chce sobie zautomatyzować to dziedziczy po Core_Object a nie po DB!! I DB i twój przykładowy kot może być obiektem dziedziczącym po Core_Object i nie mów mi że to nie logiczne bo kot jest zwierzęciem a nie obiektem jądra.

Pisałeś o Core_Context, a w kontekście może znajdować się dostęp do obiektu DB. Kontekst się deleguje, nie dziedziczy po nim.

Tak, sory literówka. Dalej pisałem o Core_Object. Chodzi oczywiście o Core_Object. Przyznaję źle napisałem.

@mike


Ehhh, rzeczywiscie dziala, nie wiem kiedy to dodali, ale nigdy mi nie dzialalo.