Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [php] Zasada działania obiektowości w php
Forum PHP.pl > Forum > PHP
kobr
Witam, w php nie programowałem jeszcze obiektowo, ale miałem już z tym do czynienia w c++. Jestem w trakcie pisania gry internetowej (coś jak rd lub ogame ale o wiele bardziej rozbudowanej) Mając jednak uwagę nad wydajnością gry oraz uporządkowanie całego kodu, zastanawiam się jak tą grę pisać obiektowo czy strukturalnie.

Pisząc strukturalnie wszystkie funkcje raczej były by od razu w pamięci serwera i będą wykonywane od razu po odwołaniu się do nich, (więc wydaje się to szybkie oraz wydajne, lecz przy dużej ilości kodu miałbym problemy z ogarnięciem całości)

Natomiast pisząc obiektowo w pamięci będę miał opisy tych klas, ale jak to wszystko będzie wykonywane? Jeśli mam coś takiego:

class A

class B extend class A

class C extend class A

i w pewnym miejscu tworzę obiekt klasy C to jak on jest tworzony fizycznie?? Tworzą się obiekty tych wszystkich klas?? Jaka jest mniej więcej wydajność kodu pisanego obiektowo a strukturalnie? Licząc, że na serwerze będzie grało z 300 osób staram się, aby to było jak najbardziej wydajne i jak najmniej wykorzystujące serwer.

Macie może jakieś stronki dotyczące tego jak ten kod obiektowy jest wykonywany fizycznie, co kiedy jest tworzone??
Indeo
Myślę, że bez rozwiązań obiektowych i enkapsulacji poszczególnych funkcjonalności serwisu nie ogarniesz go. Masz rację, że kod strukturalny jest efektywny w działaniu ale ja osobiście unikam takiego rozwiązania. Wszystkie moje aplikacje od kilku lat funkcjonują jako jedna aplikacja. Rodzaj frameworka, który jest inicjowany tylko przy pierwszym uruchomieniu następnie jest przechowywany w sesjach. Kolejne żądania wysyłane przez użytkownika inicjują kolejne obiekty dołączane do głównej klasy frameworka. Z mojego doświadczenia wynika, że najwolniejsze mimo wszystko są operacje komunikacji z bazą danych. Mysql ma bardzo wolny zapis. Kilka następujących po sobie zapytań może zająć sporą część sekundy. Pisanie gry jest dużym wyzwaniem tym bardziej, że porównujesz się z ogame. Ja pisałem boty do traviana i w tym wypadku zwłaszcza skanując mapę musiałem zmierzyć się z wydajnością tej gry smile.gif (pomijając obchodzenie zabezpieczeń).
To co mocno obciąża serwery gier to transfer - trzeba do minimum ograniczać ilość przesyłanych danych. Wydaje się nawet, że użycie AJAXA byłoby pod tym względem najbardziej oszczędne. (przesyłasz tylko dane a nie ich opakowania (html i css))


Skoro potrafisz dobrze programować w C++ może warto byłoby zastanowić się nad napisaniem programu kompilowanego - jako rozszerzenie php. Takie rozwiązanie napewno byłoby najbardziej efektywne. Ale nie pomogę Ci w tym, bo po prostu się nie znam smile.gif Znam tylko VB smile.gif

Nie bardzo rozumiem Twoje pytanie odnośnie fizycznej obsługi klas. Każdy z użytkowników wchodząc na stronę inicjowałby swoje własne instancje tych obiektów. 300 użytkowników - w pamięci serwera 300 obiektów klasy C. Musiałby jednak ktoś mądrzejszy sie wypowiedzieć .. .smile.gif
kobr
No właśnie, jeśli każdy z użytkowników miałby swoje obiekty to pisanie takiego czegoś raczej nie ma sensu, pisząc strukturalnie również mogę zadbać o czytelność kod (tworząc pogrupowane funkcje w oddzielnych plikach) do tego by doszło na bieżąco pisanie dokumentacji tego. Mimo wszystko obiektowość to obiektowość
Cytat(Indeo @ 6.12.2007, 22:50:28 ) *
Skoro potrafisz dobrze programować w C++ może warto byłoby zastanowić się nad napisaniem programu kompilowanego - jako rozszerzenie php. Takie rozwiązanie napewno byłoby najbardziej efektywne. Ale nie pomogę Ci w tym, bo po prostu się nie znam smile.gif Znam tylko VB smile.gif

Co miałeś na myśli?
edit1
A przypadkiem nie jest tak że obiekt byłby tworzony po kliknięciu na jakiś link a następnie po wyslaniu kodu użytkownikowi wszystkie obiekty są kasowane??
edit2
Chyba wiem już o co chodzi ale do tego chyba muszę mieć dostęp do serwera. Nie jestem pewien czy dobrze myślę więc proszę abyś rozwiną swoją myśl
Cysiaczek
@kobr To samo tyczy się kodu strukturalnego - każda funkcja jest ładowana do pamięci dla każdego usera osobno. Wątpię, aby używanie obiektów zamiast funkcji miało jakiś bardziej zauważalny spadek wydajności. Mieści się on raczej w okolicach błędu pomiarowego.

Pozdrawiam.

P.S Na forum była gdzieś dyskusja na ten temat. Poszukaj.
krowal
Cytat(kobr @ 6.12.2007, 23:16:44 ) *
Co miałeś na myśli?
edit1
A przypadkiem nie jest tak że obiekt byłby tworzony po kliknięciu na jakiś link a następnie po wyslaniu kodu użytkownikowi wszystkie obiekty są kasowane??


Dokładnie tak jest, po twoim ostatnim poście, a właściwie po tym zdaniu:
Cytat(kobr @ 6.12.2007, 23:16:44 ) *
No właśnie, jeśli każdy z użytkowników miałby swoje obiekty

Pomyślałem sobie że tego nie wiesz i strasznie mąci Ci to w głowie smile.gif obiekty są tworzone jeśli użytkownik wyśle żądanie do serwera, a po wysłaniu strony do użytkownika są od razu niszczone z resztą zrób sobie klasę z samym konstruktorem i destruktorem i sprawdź smile.gif
kobr
Cysiaczek chyba jesteś w błędzie, w pliku index.php mam

require_once($plik);

Jeśli cały czas na stronie będzie minimum 10 osób to plik prawie na okrągło będzie w pamięci i dla serwera nieważne jest jaki użytkownik odświeży stronę więc jeśli po moim wejściu na stronę serwer wczyta te funkcje i jak ktoś inny po kilku sekundach wejdzie na serwer to już te funkcje będą wczytane
dr_bonzo
kobr: LOL

a jesli inkludujesz plik ktory ma w sobie.. uwaga... klasy, to czemu one nie mialy by byc w pamieci?

Po prostu:
- w podstawowej wersji php za kazdym requestem wczytuje pliki, fukcje, klasy itd, kompiluje to i przetwarze
- jak masz akcelerator php to odpada ci kazdorazowa kompilacja


Poza tym "wczytanie klas od pamieci" nie rozni sie niczym od wczytania funkcji do pamieci, a tworzenie obiektow tak samo zajmuje pamiec jak tworzenie zmiennych globalnych (przy progr. strukturalnym)
kobr
Dr_bonzo wiem, że definicje tych wszystkich klas będą w pamięci. Główna różnica między programowaniem strukturalnym w moim przypadku a obiektowym polega na tym, że bardzo rzadko będę wykonywał wiele metod z tej klasy a mimo wszystko musze obiekt tej klasy stworzyć, dla przykładu:

Mam klasę A która ma wiele metod i jedna z tych metod używa metody z klasy C, aby tej metody użyć musze najpierw stworzyć ten obiekt, i na tym polega problem. Że musze tworzyć, kupę nowych obiektów aby użyć jednej metody a takich sytuacji będzie dużo.
Cysiaczek
Krótko mówiąc - nie potrzebujesz obiektów, więc ich nie używaj. Nie widzisz korzyści, to nic nie poradzimy - ja jakoś dolączając 150 klas do systemu nie widzę szczególnego spadku wydajności poza, nie licząc funkcji wielokrotnego wywołania include(), co można zminimalizować pisząc jakiś mini "kompilator" dla często używanych plików.

Co do trzymania pliku w pamięci i udostępnianiu go wielu użytkownikom jednocześnie... wątpię - słyszałeś o bezpieczeństwie?
Zresztą napisz sobie jakiś skrypt, który się wykonuje jakiś dłuższy czas i:
1. Uruchom
2. zmień coś w źródle
3. uruchom drugi proces w trakcie trwania pierwszego

Pozdrawiam.
kobr
Cysiaczek ale chyba się nie rozumiemy, widzę zalety pisania obiektowego i chcę to pisać obiektowo, ale nie wiem jak będzie z prędkością skryptu. W pamięci będę przechowywał tylko definicje funkcji klas i metod i to nie jakoś w specjalny sposób tylko po prostu po kliknięciu na dowolny link zawsze te funkcje są wczytywane, i jak ktoś może mieć wczytane te funkcje tylko sobie?? skoro to serwer je wczytuje do swojej pamięci. Nie ma tu mowy o żadnych innych procesach. Po klikniecie na link serwer wywołuje odpowiednie funkcje wysyła odpowiednie dane użytkownikowi i koniec, albo sobie czeka albo obsługuje następne kliknięcie.
dr_bonzo
kobr: przeprowadz testy i wroc jak stwierdzisz ze jednak serwer nie przechowuje ciagle wczytanych funkcji w pamieci.

Pozatym Cysiaczek podal ci przyklad jak sprawdzic ze jednak serwer nie trzyma skryptow w pamieci przez caly czas.
Cysiaczek
Jednak dalej uważam, że to Ty nie rozumiesz. Owszem, interpreter wczytuje to sobie do swojej pamięci, ale jeśli ktoś inny też wywoła ten sam skrypt, to on zostanie wgrany do pamięci po raz drugi (co wykazuje test, który polecałem Ci zrobić). Każdemu żądaniu php towarzyszy inicjalizacja, czyli uruchomienia potomka procesu php i interpretacja skryptu.

Pozdrawiam.
phpion
Cytat(kobr @ 6.12.2007, 23:55:27 ) *
Witam, w php nie programowałem jeszcze obiektowo, ale miałem już z tym do czynienia w c++. Jestem w trakcie pisania gry internetowej (coś jak rd lub ogame ale o wiele bardziej rozbudowanej) Mając jednak uwagę nad wydajnością gry oraz uporządkowanie całego kodu, zastanawiam się jak tą grę pisać obiektowo czy strukturalnie.

Moim skromnym zdaniem kolega ~kobr jest idealnym przykładem przerostu formy nad treścią. Tworzysz grę internetową? O wiele bardziej rozbudowaną od Ogame? Hmmm, fajnie, ale wydaje mi się, że takie systemy powinny być tworzone tylko i wyłącznie w obiektówce. Przewaga O nad S jest jasna i nie ma tu o czym dyskutować. Powiem więcej: nie widzę takiego projektu napisanego strukturalnie. Zamiast zastanawiać się co jest wydajniejsze O czy S lepiej poczytaj o optymalizacji skryptów (wątek bodajże w dziale Hydepark) i to weź sobie do serca. Skup się na tamtych tematach, a nie na O czy S bo w przypadku gry internetowej takie wątpliwości świadczą raczej o słabej wiedzy programistycznej.

Cytat(kobr @ 6.12.2007, 23:55:27 ) *
Jeśli mam coś takiego:

class A

class B extend class A

class C extend class A

Swoją drogą: chyba masz tu błędy winksmiley.jpg ale wiem - to tylko kody poglądowe smile.gif hehe.
kobr
<?php
require_once(plik.php)

$obiekt= new a();
$obiekt->metoda();
?>
Czyli co po kliknieciu na link ten kod jest wykonywany i po wykonaniu wszystkich funkcji usuwany z pamięci?? Czy jeśli 1ms później ktoś kliknie na ten sam link to plik.php ponownie zostanie wczytany?


Porównywanie z ogame może jest trochę błędem bo tam jest chyba sporo procesów itd. Bardziej to ma przypominać reddragon tyle że sporo więcej możliwości a co za tym idzie funkcji.
phpion.com właśnie takiej odpowiedzi oczekiwałem, więc dylemat na temat O czy S już mam rozwiązany
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.