Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Uzupełnianie metod rodzica
Forum PHP.pl > Forum > PHP > Object-oriented programming
markonix
Mam cudzą aplikację, oparta jest o MVC.
Do dwóch metod w kontrolerze chciałem dodać małą akcję (statystyki).

Aby uniknąć edytowania kodu aplikacji zacząłem pisać klasę rozszerzającą te dwie metody.
Klasę by wystarczyło zaicludować w pliku głównym (brak autoloadera) i tyle.
W funkcji zawarłem mój kod + ::parent(funkcja).
No ale chwila.. To nie działa w tą stronę..
Metoda pokazStroneX wywoływana jest na obiekcie rodzica, a nie dziecka tak więc to co napisałem nie ma prawa działać.
Działałoby gdyby metoda była wywoływana na obiekcie klasy rozszerzającej, ale to znów by wymagało ingerencji w kod aplikacji.

Tutaj się zastanawiam jak uniknąć ingerowania w kod kontrolera jeżeli w systemie tym, nie ma żadnego systemu pluginów czy API?
Są jakieś metody? Jakieś koncepcje?
skowron-line
Szczerze mówiąc to nie bardzo zrozumiałem o co chodzi, może pokaż jakiś kawałek kodu lub to co napisałeś, powiedz jaki jest typ dostępu do metod do których chcesz się odwołać.
pejott
Hehe, coś o czym mówisz jest błahostką np. w Symfony2. Kontrollery masz zdefiniowane jako "services" w pliku konfiguracyjnym.
Zmieniasz tylko parametr zawierający nazwę klasy i gotowe. Większość bundli udostępnia też zmianę klasy w pliku konfiguracyjnym samej aplikacji.

Pozdrawiam.
markonix
skowron-line, proszę:

  1. class rodzic {
  2. function metodaX() {
  3. echo 'bu';
  4. }
  5. }
  6.  
  7. // Koniec kodu aplikacji właściwej
  8.  
  9. class rozszerzajaca extends rodzic {
  10. function metodaX() {
  11. // akcja niezależnego licznika
  12. parent::metodaX();
  13. }
  14. }
  15.  
  16. $rozszerzajaca = new rozszerzajaca;


Aplikacja działa na obiekcie rodzic.
Aby wywołała mi się moja metodaX jestem zmuszony w ingerencje kodu (wywołanie metody metodaX na obiekcie $rozszerzajaca czego po prostu chciałbym uniknąć, aby to było elastyczne rozszerzenie aplikacji). Zresztą modyfikacja pliku głównego już w sumie była by gorsza od modyfikacji ręcznej tej metody. Po prostu czy mogę "ładnie" jakoś uzupełnić aplikacje, gdy nie ma ona przewidzianej pluginizacji, zawsze miałem przekonanie że dziedziczenie na to pozwoli, dziś chciałem tego użyć i myśl "przecież to tak nie działa, nie w tę stronę".
wookieb
Cytat(pejott @ 18.06.2011, 08:56:54 ) *
Hehe, coś o czym mówisz jest błahostką np. w Symfony2. Kontrollery masz zdefiniowane jako "services" w pliku konfiguracyjnym.
Zmieniasz tylko parametr zawierający nazwę klasy i gotowe. Większość bundli udostępnia też zmianę klasy w pliku konfiguracyjnym samej aplikacji.

Pozdrawiam.

Jaki to ma związek z tematem?
Crozin
Twój problem wynika z tego, że gdzieś tam w aplikacji w końcu robione jest mniej-więcej coś takiego:
  1. $obj = new Rodzic();
  2. $obj->metodaX();
Ty musiałbyś jakoś doprowadzić do tego by tworzony był obiekt typu Dziecko, zamiast Rodzic. Bez tego nic Ci po dziedziczeniu. Być może w jakimś pliku konfiguracyjnym jest możliwość określenia jaki obiekt dla danego typu żądania ma być tworzony?

Być może system obsługuje jakiś system zdarzeń i jest możliwość podpięcia własnego kodu? Wtedy wystarczyłoby dodać jakiś warunek sprawdzający czy zdarzenie zostało wywołane w kontekście Rodzic::metodaX() i dodać swój kod.

Generalnie jeżeli system nie został przygotowany do możliwości jego nieinwazyjnego rozszerzenia to wiele nie zrobisz. W ostateczności (jeżeli koszt mieszania w oryginalnym kodzie będzie rzeczywiście za wysoki) możesz pokusić się o lekturę tej strony i zawartych w niej sugestii: http://stackoverflow.com/questions/137006/...ethods-or-class - ale takich zabiegów trzeba używać naprawdę z głową.
markonix
Cytat(Crozin @ 18.06.2011, 15:20:45 ) *
Generalnie jeżeli system nie został przygotowany do możliwości jego nieinwazyjnego rozszerzenia to wiele nie zrobisz. W ostateczności (jeżeli koszt mieszania w oryginalnym kodzie będzie rzeczywiście za wysoki) możesz pokusić się o lekturę tej strony i zawartych w niej sugestii: http://stackoverflow.com/questions/137006/...ethods-or-class - ale takich zabiegów trzeba używać naprawdę z głową.


Nie ma żadnych kosztów, bardziej to problem koncepcyjny, aniżeli coś czego nie da się przeskoczyć.
Argumentem dlaczego tak chce robić jest głównie zabezpieczenie moich poprawek przez upgrade'm oprogramowania.

Cytat(Crozin @ 18.06.2011, 15:20:45 ) *
Być może system obsługuje jakiś system zdarzeń i jest możliwość podpięcia własnego kodu? Wtedy wystarczyłoby dodać jakiś warunek sprawdzający czy zdarzenie zostało wywołane w kontekście Rodzic::metodaX() i dodać swój kod.


Najbliższe temu jest inny pomysł aby tylko w pliku głównym (tym co łączy M,V i C) dołączyć jakby drugi kontroler.
Akcje, które chce zliczać, są wywołane urlem (klasa/funkcja/argumenty).
Mógłbym przetworzyć url ponownie w moim kontrolerze i gdy zostanie wywołana funkcja, którą chciałem rozszerzać to po prostu wywołam skrypt licznika.
Rozwiązanie te wymaga wgrania jednego pliku i jednego prostego include w pliku głównym za głównym kontrolerem.

everth
Cytat
by uniknąć edytowania kodu aplikacji zacząłem pisać klasę rozszerzającą te dwie metody.
Klasę by wystarczyło zaicludować w pliku głównym (brak autoloadera) i tyle.

Stwórz dekorator klasy rodzica i załącz go zamiast dekorowanej klasy. Raczej ekonomiczniejsze rozwiązanie niż obchodzenie zawiłości hierarchii dziedziczenia.
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.