Otóż, zastanawia mnie taka rzecz, mamy aplikację, w której stosujemy pewnego rodzaju moduły. Moduł składa się z jednego pliku PHP, w którym jest klasa. Klasa ta dziedziczy po ogólnej klasie (załóżmy: Module) oraz implementuje interfejs (ModuleInterface). Dziedziczy, by móc korzystać z dobrodziejstw aplikacji, na której działa, a implementuje, by każdy moduł posiadał jedno wspólne API, by aplikacja wiedziała, jak je uruchomić (moduły).

Teraz pytanie: Jeśli w aplikacji, modułów mamy przykładowo 20 (każdy z nich może być też wielokrotnie konkretyzowany), to czy za każdym razem sprawdzać, czy dany moduł implementuje dany interfejs oraz czy dziedziczy po danej klasie? Sprawdzanie za każdym razem kolejnej klasy będzie sprawiać obciążenie, w tym wypadku niepotrzebne (IMO). Jeśli programista nie użyje dziedziczenia, to sam zauważy, że coś mu nie działa, więc "podepnie" klasę do innej (w tym przypadku Module). A jeśli nie zaimplementuje interfejsu... no cóż, najprawdopodobniej wyskoczy błąd PHP, że nie ma takiej metody - jeśli defacto jej nie doda do klasy.

Jak bardzo należy trzymać się wydajności aplikacji, na rzecz sprawdzania tego typu rzeczy. I nie chodzi mi tylko o moduły, ale praktycznie każdą rzecz, która powinna posiadać dziedziczenie lub implementować jakiś interfejs.

1. Dziedziczenie praktycznie nigdy nie powinno być wykorzystywane do sprawdzania API danej klasy - od tego są właśnie interfejsy, tylko na nich powinieneś się skupić.
2. Masz jakiś faktyczny problem z wydajnością w tym aspekcie? Przedwczesna optymalizacja często dostarcza jedynie niepotrzebnych problemów.

20 modulów, to nie jest jakiś specjalny problem. Problem by był gdyby twoja aplikacja takich modułów miała kilkaset. No i tak, jest to kosztowne dla php, ale są to wciąż tak małe wartości, że np takie symfony które ma około 2000 klas/interfejsów w wersji standard vendors, o ile bez opcache chodzi to ślamazarnie, tak z opcache, chodzi w miarę przyzwoicie. Kolejną sprawą są również wersje php, sam ostatnio na jednym projekcie zobaczyłem różnicę między php 5.3 a php 5.5. Zysk wydajności nawet bez opcache był ogromny. Ale nie każdy projekt pozwala na uruchomienie na php 5.5. Więc nie staraj się na siłę szukać optymalizacji po stronie aplikacji (zmniejszenie ilości klas/interfejsów, żeby zyskać o 50kb i 10ms szybszą aplikacje), ale też zwróć uwagę na środowisko w którym uruchamiasz aplikację.

Aplikacja powinna działać przede wszystkim stabilnie. Zastanów się czy klient doceni jej wydajność, jeśli co chwilę coś nie będzie działało i rzucało błędami?

Klient docenia szybkość działania aplikacji, a błędy zdarzają się jak zawsze, przy produkcie, który jest stale rozwijany, ale są to błędy przeważnie na poziomie GUI czy danego kontrolera, niż tak bardzo systemowe.



To rozumiem, nie korzystam z dziedziczenia w tym sensie. Są one po to, by każdy z modułów posiadał dokładnie ten sam zestaw metod, chciałem ujednolicić zarządzanie danymi. Nie mówię, że to dobre rozwiązanie, ale znakomicie się sprawdza.



Nie sprawdzałem jeszcze jak bardzo obciążenie to generuje, ale tak, szukam rozwiązań, które mogę zastosować by przyśpieszyć aplikację.

@by_ikar - Niestety, nie mogę liczyć na jednolite serwery u wszystkich klientów. Gdybym tak zrobił to miałbym ich bardzo mało. Aplikacja działa z PHP 5.3.10+, więc na większości serwerów dzisiejszych w miarę przyzwoicie, ale ja wiem, że zawsze jest coś co można przyśpieszyć, polepszyć. Właśnie tego szukam i dlatego ten temat.

Chciałbym po prostu poznać zdanie ludzi, którzy są bardziej doświadczeni w tym temacie. Mimo, że ktoś wie dużo, zawsze jest jakiś temat, na który wie się mało - stąd na przykład to moje pytanie.

Spoko, ale całkiem dobry współdzielony serwer z ngnix+phpfpm+xcache i php 5.3-5.5 w najdroższym pakiecie wychodzi 360zł rocznie, to jeżeli twojego klienta nie stać na taki serwer, to zastanów się czy będzie go stać na projekt który mu wykonasz.. Ja już jakiś czas temu jak mi powiedzieli że mam w php5.2 coś im zrobić, to powiedziałem że nie będę przepisywać całego fw na nowo, tylko dlatego że on skąpi 150zł na lepszy serwer.. Taki sam problem mam teraz, gdzie klient chce żeby aplikacja miała poniżej 1mb alokowanej pamięci ram, ale "boi" się zainstalować php jako moduł, żeby można było zainstalować jakiś opcacher (nawet ten wbudowany w php5.5), dlatego jak tylko skończę projekt, a jemu nadal nie będzie w głowię jakaś optymalizacja po stronie serwera, to oddam mu projekt, i dalej niech sobie radzi sam.

Ja rozumiem, ale musisz wziąć pod uwagę to, że każdy klient może pozwolić sobie na zakup nowego serwera - niektórzy mają już serwer, a na nim jedną czy dwie stronki i co teraz? Albo pozbywamy się klienta i mówimy "sorry, ale musi Pan kupić nowy serwer bo zrobiliśmy apliakcję, która wymaga XXX, a Pana serwer tego nie ma", albo próbujemy zrobić taką aplikację, która zadziała na 80% serwerów, ale nie będzie przy tym jej nic brakowało, co byśmy chcieli by miała.

No niestety, coś za coś. Już nie raz spotkałem się, że klient miał już wykupiony serwer współdzielony, ale w takiej tragicznej firmie, że aplikacja zadziałała tylko dla tego, że została napisana w pewien sposób. Hosting ten miał główną domenę przypisaną na stałe do serwera do głównego katalogu, i nie dało się tego zmienić. A klient miał tam jeszcze 2 inne strony, a my mieliśmy mu odświeżyć właśnie tą, która przypisana była do głównej domeny.

Czasami się czegoś nie da przeskoczyć, lub zastosować, ale nie oznacza to, że musimy olewać wszystko i robić tak jak chcemy i nakazywać ludziom naszych poglądów. To my mamy zrobić tak, by mieć klientów, a nie na odwrót. Oczywiście nie wspominam tutaj o kwestiach bezpieczeństwa czy użyteczności - to temat na zupełnie inną rozmowę.

PS.
Zgadzam się z Tobą w 100% jeśli chodzi o przytoczony przykład. Tak samo bym postąpił, gdyby ktoś kazał mi pisać pod PHP5.2.

Ale podałem ci przykład sharedów za 150zł rocznie. Jeżeli ktoś ma gdzieś wykupiony serwer, a chcę nową aplikacje która będzie wymagała czegoś od strony serwera i sam nie będzie chciał zainwestować tych 150zł w nowy serwer; to łatwo się zastanowić - skoro żałuj na serwer 150zł rocznie, to czemu miałby mi nie żałować i w końcowym rozrachunku płacić mi na raty po 1235 razy co 3 miesiące? Dla mnie sprawa jest prosta, albo się bawimy, albo mogę się zająć frontendem a do reszty możesz poszukać kogoś kto lubi dłubać dla paru złotych ekstra co trzy miesiące..

Faktycznie, jeśli ktoś nie ma serwera, to i tak musi go kupić i tak - jest to niezbędne. Ale jeśli ktos ma serwer, i ma na nim strony to przeważnie też ma jakieś skrzynki pocztowe. Przeniesienie tych skrzynek jest w jego gestii nie mojej, więc tym bardziej zalecane jest nie zmienianie serwera.

Poza tym, jeśli zostawiłby ten serwer dla jednej strony, którą już ma, a wykupił drugi dla nowej to doszedł by do takiego zamieszania jak mój aktualny klient. Biedny ma 4 serwery, na każdym inne strony i inne domeny, a dodatkowo jeszcze jedno konto w piątej firme, gdzie ma resztę domen. Paranoja...