Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Własny framework
Forum PHP.pl > Forum > PHP > Object-oriented programming
DiH
Witam,

Starając się poznać lepiej OOP postanowiłem napisać coś, co dużymi słowami możnaby nazwać framworkiem. Chciałbym zatem zasięgnąć waszej rady, w którą stronę pójść budując go, tj. na jakim typie architektury (którego z frameworków) się wzorować, a także czy ten zalążek który do tej pory napisałem wygląda sensownie. Jeżeli nie, to gdzie leży pies pogrzebany i gdzie szukać prawidłowych wzorców. Wszelkie komentarze, porady i linki mile widziane. Kod: http://ideone.com/p7Fao
Zyx
Przede wszystkim zacząłbym od przeczytania, czym jest framework, zanim zaczniesz używać tej nazwy w stosunku do swojego kodu:

http://pl.wikipedia.org/wiki/Framework

Następnie poleciłbym Ci poczytać o czymś takim, jak PSR-0 odnośnie nazewnictwa i ładowania klas, później taki oto artykulik:

http://www.zyxist.com/pokaz.php/harryemu_juz_podziekujemy

A później to:

http://www.zyxist.com/pokaz.php/propozycja...d_projektowania

Znajdziesz tam odpowiedzi na dużą część swoich pytań odnośnie projektu.

Ostatnia moja rada brzmi: myśl. Dlaczego DBManage dziedziczy po DDF_PDOException?
DiH
Dzięki za rady, na pewno poczytam.

Nurtuje mnie jednak jedna ważna rzecz - czy używać Dependency Injection w tej formie, czy nie? Już przy tych ledwie paru klasach widzę, że dużo zachodu jest przy stworzeniu obiektu dla każdej z nich. A co, gdy będę potrzebował załadować ich więcej? Za każdym razem setService i tworzenie obiektu w Closure? Do tego dochodzi pytanie, czy oprócz używania __set lub przekazywania przez __construct istnieje jakiś jeden sensowny sposób przekazania nowej instacji klasy obiektu z którego ma korzystać?

Np. klasa User, która ma mieć możliwość korzystania z bazy. Najpierw muszę utworzyć instancję DBManage podając mu obiekt/tablicę z configiem, a dopiero potem tak spreparowany obiekt przekazać do klasy User (lub innej, która miałaby tego wykonać).

Po zastanowieniu, wydaje mi się, że w ogóle powinienem zrezygnować z tego typu zabiegów i nie "wstrzykiwać" obiektów klas do innych klas, a tylko operować na obiektach pojedyńczej klasy. Tylko po co wtedy DI?

Z góry dzięki za odpowiedź na ten mętlik.
Zyx
To fakt, ręczne wstrzykiwanie zależności bywa męczące. Ale od tego są właśnie mechanizmy, które potrafią to zrobić automatycznie na podstawie znajomości wymagań konkretnych obiektów.
zend
o_O ja bym radził poczytać jeszcze troche o php przed pisaniem frameworka
  1. $bin->setService('objectFromArray', function ($c) {
  2. return new $c->objectizer_class();
  3. });


create_function - okropne rozwiązanie jeśli chodzi o późniejsze debugowanie
rzymek01
Zyx,
apropo wpisu dotyczącego magicznych metod i argumentu, że IDE nie podpowiada składni

w niektórych miejscach przyjemniej (i szybciej) jest ustawić gettery i settery niż pisać kilka funkcji typu get* i set*,
a że korzystam z netbeansa, który czyta PHPDOCa to ładnie sobie to dokumentuję i nie mam problemu z brakiem podpowiedzi zmiennych z magicznych metod
melkorm
Cytat
a że korzystam z netbeansa, który czyta PHPDOCa to ładnie sobie to dokumentuję i nie mam problemu z brakiem podpowiedzi zmiennych z magicznych metod



To jak już z niego korzystasz to sobie wygeneruj set'y i get'y w nim wink.gif
rzymek01
ale po co?
kod wygląda mniej czytelnie (o dziwo),
szczerze się przyznam, że nie wiem na jakiej zasadzie miałoby generować te metody, ale domyslam się, że późniejsza modyfikacja będzie się wiązała z ręcznym dodawaniem/usuwaniem kodu,
zresztą nie lubię korzystać z żadnych generatorów kodu
darko
~DiH imo szybciej i efektywniej nauczysz się nie pisząc od zera cały framework a poznając istniejące rozwiązania, których jest do wyboru, do koloru. Wartością dodaną w tym przypadku będzie to, że od razu podejrzysz, jak poradzono sobie z często napotykanymi problemami różnego typu i jakie rozwiązania funkcjonują w danym obszarze. Samo pisanie od zera frameworka to sztuka dla sztuki, chyba że masz pewność, że tak się po prostu szybciej nauczysz. Jednak wiedz jedno: frameworków na rynku jest bardzo dużo, od darmowych, po całą gamę komercyjnych rozwiązań, wszystko lub prawie wszystko w nich jest już gotowe. To niemal jak książka kucharska dla Ciebie smile.gif
Owocnej nauki.
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.