Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [OOP] [PHP5] Router
Forum PHP.pl > Forum > PHP > Object-oriented programming
Dipter
Witam, zacząłem pisać do swojej aplikacji Router, który zajmowałby się operacją na URL, ale pojawił się jeden kłopot. Otóż wcześniej nie miałem problemu do napisania jakiegokolwiek Routingu(?), ponieważ stosowałem jeden separator w linkach przeze mnie wyznaczony "/" - (strona.pl/kontroler/akcja/parametr1/2/3/etc.... No i nie było żadnego problemu, ale wymyśliłem sobie by wprowadzić kilka takich separatorów, np. "/", ",", "-", etc., lecz tutaj pojawiają się schody jak coś takiego wykonać i podzielić na segmenty. Z góry dzięki za podpowiedzi, a jeszcze bardziej przykłady, pozdrawiam.

@EDIT
Doszedłem do rozwiązania sam, moderatora proszę o zamknięcie tematu, chyba, że ktoś będzie potrzebował z tym pomocy, pozdrawiam smile.gif
jwest
A ja bym cię poprosił o przedstawienie rozwiązania jeśli możesz winksmiley.jpg
Dipter
Tak więc w argument klasy wstawiłem tablice z różnymi separatorami, załóżmy, że array('/', ',', '-', '_');
W innym argumencie klasy miałem pustą wartość na miejsce z wcześniej podanym URLem. Następnie metodą eksplodowałem URL poprzez foreach(), tzn.? Może przedstawię na kodzie:

  1. <?php
  2. class Router {
  3.  
  4. private $__URL;
  5.  
  6. private $__Separators = array('/', ',', '-', '_');
  7.  
  8. private $__Segments = array();
  9.  
  10. public function __construct($URL) {
  11. $this->__URL = $URL;
  12. }
  13.  
  14. public function explodeURL() {
  15. foreach($this->__Separators as $Key => $Value) {
  16. $this->__URL = str_replace($Value, '|', $this->__URL);
  17. }
  18. foreach(explode('|', $this->__URL) as $Key => $Value) {
  19. $this->__Segments[] = $Value;
  20. }
  21. }
  22.  
  23. public function getParam($ID) {
  24. return $this->__Segments[$ID];
  25. }
  26.  
  27. }
  28. ?>


Zamieniłem w URLu wszystkie te wcześniej podane separatory na jeden, czyli "|", a później eksplodowałem URL z separatora "|", z czego powstała tablica ;P Dalej chyba tłumaczyć nie muszę. Sposób wydaję się być trochę zagmatwany, ale skuteczny. Jeśli byłyby problemy, to pisać. Oczywiście mój kod jest bardziej rozbudowany to tylko przykład.
Crozin
1. preg_split.
2. O co chodzi z milionem "_" przed prywatnymi właściwościami.
Dipter
1.Dzięki, zaraz obczaje smile.gif
2.Jakieś takie upodobania sobie przybrałem, żeby przed zmiennymi prywatnymi dawać 2x "_", przy publicznych dopisywać na początku "g_", a przy chronionych nic tongue.gif Nie wiem, może by kod był czytelniejszy?
Mephistofeles
Dziwny sposób. Zainstaluj jakieś IDE z ikonkami przy hermetyzacji.
Zyx
Trochę przekomplikowane, zwłaszcza w przypadku pól publicznych. Nie wystarczy Ci po prostu wiedzieć, które są publiczne, a które nie? Ja daję tylko jedno podkreślenie przed polami prywatnymi i chronionymi, jako zwykłą konwencję.
Dipter
Właściwie dotąd nie było żadnego problemu jeśli chodzi o takie rzeczy, nie wiem, jest mi tak wygodnie tongue.gif
mike
A po kiego grzyba Wam jakie prefiksy? To w PHP private nie oznacza prywatne a public przestało oznaczać publiczny?
Dipter
Każdy robi jak mu wygodnie i jak chce, tego się nie zmieni, poza tym, to chyba nie był główny temat mojego problemu smile.gif Więc dyskusję nt. prefiksów i innych tego typu rzeczy zakańczam, przynajmniej w tym wątku, pozdrawiam. ;P
Crozin
Cytat
Każdy robi jak mu wygodnie i jak chce
Przez to PHP ma chyba najbardziej #%$#%^#$^ biblioteki - bo każdy robi jak chce, zamiast trzymać się konwencji.
Zyx
Sorry, ale dawanie podkreśleń przed elementami prywatnymi/chronionymi jest całkiem powszechnie stosowaną konwencją, i co więcej, w PHP może mieć istotne znaczenie praktyczne. Jeśli w klasie jest magiczna metoda __get() i próbujemy dostać się do chronionego pola spoza wnętrza klasy, takie żądanie trafia właśnie do magicznej metody.

Ponadto jest też taka sprawa, że czasami wewnętrzne rzeczy jakiejś klasy trzeba zadeklarować jako publiczne, mimo iż użytkownik nie powinien z nich korzystać. Wstawienie podkreślenia to prosty sposób na powiedzenie: "używasz na własne ryzyko. Ja to API mogę w każdej chwili zmienić, a wtedy nie miej do mnie pretensji". I chyba to jest nawet właściwszy powód, by używać podkreśleń, bo protected wcale nie musi oznaczać, że użytkownik końcowy nie ma tego używać i vice versa.
Crozin
"_" przed niepublicznymi właściwościami to naleciałość z PHP4. Nie twierdzę, że się tego nie stosuje, bo tak nie jest, ale raczej nie widzę większego sensu w stosowaniu tego. Publicznych właściwości używa się dosyć rzadko, chyba najrzadziej z całej trójki. A używanie __get() w jakimkolwiek innym celu niż zachowanie wstecznej kompatybilności powinno być karalne.

Cytat
trzeba zadeklarować jako publiczne, mimo iż użytkownik nie powinien z nich korzystać
W jakiej sytuacji(ach) spotkałeś się z koniecznością zrobienia czegoś takiego?
Cytat
Wstawienie podkreślenia to prosty sposób na powiedzenie: "używasz na własne ryzyko. Ja to API mogę w każdej chwili zmienić, a wtedy nie miej do mnie pretensji".
Raczej wystarczyłby odpowiedni komentarz w dokumentacji. Jeżeli ktoś nie sprawdza co coś robi przed użyciem tego to już jego problem.
Zyx
Spotykam się z takim użyciem stosunkowo często (tzn. częściej z relacją w drugą stronę) - tego typu schemat działania jest podstawą działania frameworków, gdzie framework definiuje Ci środowisko i ogólne zasady działania, a Ty wypełniasz tylko przeznaczone do tego miejsca własnymi rzeczami, zależnie od Twoich potrzeb. Możemy rozważać sobie system formularzy, w którym każdy formularz definiowany jest jako klasa (skoro akcje można, to formularze też). Bazowa klasa abstrakcyjna definiuje logikę oraz metody typu onInit(), onRender, w których możesz zapisać sobie ogólną strukturę, reguły poprawności itd. Metody tego typu zazwyczaj powinny być chronione, ponieważ nie ma potrzeby, by programista wywoływał je ręcznie. Logika klasy formularza sama sobie poradzi z wywoływaniem ich w optymalny sposób i wtedy, gdy są potrzebne. Jednak nie zaprzeczysz, że mimo słówka protected, obie te metody nie są sprawą wewnętrzną klasy. Użytkownik końcowy powinien, a nawet musi je nadpisać własną treścią. Analogiczna sytuacja może zachodzić w drugą stronę, gdy mamy jakieś dwie niespokrewnione klasy współpracujące ze sobą poprzez jakiś wewnętrzny i nieistotny dla użytkownika końcowego mechanizm. Aby go udostępnić, trzeba wypuścić jakieś metody publiczne.

A zresztą, równie dobrze można się czepiać, że do nazw klas abstrakcyjnych dorzuca się słówko "Abstract", a do interfejsów - "Interface". Też Ci mogę odpowiedzieć: przecież widać w kodzie, co to za klasa, ale jednak twórcy takich pakietów, jak Zend Framework czy Symfony 2 uznali, że poprawi to czytelność kodu.
Dipter
Cytat
Przez to PHP ma chyba najbardziej #%$#%^#$^ biblioteki - bo każdy robi jak chce, zamiast trzymać się konwencji.

Rozumie Cię, lecz co do robienia rzeczy tak jak każdy chce, miałem na myśli tylko te podkreślenia. Według mnie nie ma się co czepiać o coś takiego, bo to raczej nie przeszkadza, ani w kodzie, ani w czytelności. Co do tych "#%$#%^#$^ bibliotek". Myślę, że jakieś "duperele", które bardziej dodają kodu czytelności, nie stanowią żadnego problemu. Tak więc nie wiem czy jest sens ciągnięcia tego tematu, bo tak czy siak, każdy będzie miał swoje zdanie, jak w wielu innych sprawach. Poza tym, ten wątek mija się z celem tematu, jak już wcześniej wspominałem.
Crozin
@Zyx: Ciężko się tutaj spierać - zbyt subiektywny temat, trochę wręcz "religijny". Faktycznie masz rację, że czasami zachodzi potrzeba użycia metod publicznych do nie do końca publicznych celów. Mi osobiście byłoby bardzo na rękę gdyby znak podkreślenia był używany wyłącznie w nazwach stałych.

@Dipter: To strasznie przeszkadza, jeżeli korzystasz z kilku bibliotek i Raz_masz_tak, czasamiMaszTak, InnymRazemOTak, _tutajTakieCoś a na koniec dowalą Ci takimczymś - aha, no i jeszcze sam język __teżCośDokłada.

Cytat
każdy będzie miał swoje zdanie, jak w wielu innych sprawach
A tak właśnie być nie powinno w tych kwestiach.
Dipter
Nie powinno, ale raczej będzie. Wiadomo, że mogłoby udać się zmienić zdanie i styl pisania, osobą, które dla Ciebie wykonują różne rzeczy, lub z nimi razem programujesz, nie wspominając o jakimś gronie, osób, które po prostu pracują jak ty. Świata niestety nie zmienisz. Mi to ogólnie nie przeszkadza, może dlatego, że nie jestem doświadczonym i starym programistą, który już mieszał w kodach "od dziecka".
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-2024 Invision Power Services, Inc.