Uzupełnianie metod rodzica Opcje

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

Ten post edytował markonix 18.06.2011, 00:04:24

[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ę:

[PHP] pobierz, plaintext 
class rodzic {
	function metodaX() {
		echo 'bu';
	}
}
 
// Koniec kodu aplikacji właściwej
 
class rozszerzajaca extends rodzic {
	function metodaX() {
		// akcja niezależnego licznika
		parent::metodaX();
	}
}
 
$rozszerzajaca = new rozszerzajaca;
[PHP] pobierz, plaintext 

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ę".

Ten post edytował markonix 18.06.2011, 14:05:25

[wookieb]

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:

[PHP] pobierz, plaintext 
$obj = new Rodzic();
$obj->metodaX();
[PHP] pobierz, plaintext 

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]

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.

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]

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.