Witam mam pewne pytanie .
Czy kod napisany obiektowo jest wolniejszy do napisanego standardowo ? Nie chodzi mi o szybkość pisania takiego kodu tylko o to który typ jest bardziej wydajniejszy (czyt. szybciej się ładuje itp.) . Bo spotkałem się z opinią że kod napisany obiektowo jest mniej wydajny niż kod napisany w normalny tradycyjny sposób.
Czy to prawda ?

W 99% przypadków tak. Ale różnice w przeciętnych zastosowaniach są bardzo małe - praktycznie niezauważalne. Jest to mała cena jaką się płaci za lepszą strukturę kodu.

Czasami nawet i duża...

Gdy mamy np. zbieranie 50 różnych danych o użytkowniku na jednej stronie to obiektowo robimy 50 zapytań, a normalnie to jedno zapytanie i wszystkie wyniki są w tablicy.

Dziękuję, Babcia@Stefa

Ciekawe. Jak masz dobrze zaprojektowaną bazę i relacje to da się mniejszą ilością. Jak kiepsko napiszesz strukturalnie to też możesz 50 wydać..

Gdyby programowanie obiektowe było dużo wolniejsze to ludzie nadal pisaliby strukturalnie..


Co masz na myśli pisząc w "przeciętnych zastosowaniach" ?

Kod obiektowy jest wolniejszy.
Czy dużo? To zależy.
To zależy od tego jaki to jest kod i jak napisany.
W rzeczywistości to spowolnienie nie jest duże. Ma ono jest nawet mniejsze niż małe.

Nie mniej jednak szybkość jest tylko jednym z czynników wyboru stylu kodowania.
OOP ma tyle zalet, że to spowolnienie jest czymś co można przyjąć bez problemu.


Nie wygaduj takich bzdur bo ludzie zaczną powtarzać. Przez taki bełkot rośnie niewiedza ludzka.

w takiej sytuacji podaję zawsze pewien przykład.

Parę lat temu był konkurs gdzieś tam za oceanem, na napisanie skryptu w php, wykonującego pewne operacje symulujące sortowanie kart czy coś w tym stylu.
Zainteresowanie konkursem było duże, nagroda za kilkaset $, a wygrał ją człowiek z polski (bodajże carget - choć nie bijcie, jeśli pomyliłem ksywę - ostatnio robię to nagminnie)

Założeniem było to, że praca miała wykonać określone zadanie i miała być jak najszybsza.

Prace były bardzo różne.
Niektórzy posuwali się nawet do tego, że usuwali spacje i komentarze z kodu, po to by ten działał szybciej. (O skracaniu nazw zmiennych i funkcji nawet nie wspominając.)

Oczywiście większość osób, z uwagi na to, że przecież kluczowym kryterium była prędkość, pisała strukturalnie.

Nasz Polak wygrał ten konkurs kodem w pełni obiektowym, świetnie skomentowanym, sformatowanym i z u standaryzowanymi nazwami zmiennych i funkcji.
Na dodatek jego kod był od kliku do kilkudziesięciu razy szybszy niż większość oddanych prac.

Dlaczego?
Bo pisząc obiektowo mógł skupiać się na budowie algorytmu działania tego mechanizmu, a nie martwić się strukturą kodu.

Wtedy byłem w szoku. Teraz nie wyobrażam sobie kodowania strukturalnego...
(i dlatego np. nie chciałbym zajmować się programowaniem driverów albo układów scalonych, gdzie niestety - kod prawie zawsze musi być strukturalny)

Przeciętny projekt to taki nie za duży nie za mały :-) A tak na serio - jeśli system aukcyjny to jest to przeciętny projekt - jeśli robisz to samo ale dla Allegro (zakładając taką a taką liczbę userów itp, skomplikowanie itp.) wtedy jest to projekt "nieprzeciętny". W takim wypadku dobrze napisany kod strukturalny byłby prawdopodobnie szybszy niż obiektowy - tylko to jest przypadek podobny do tego co napisał DeyV czyli prawdopodobnie w praktyce kod obiektowy byłby szybszy bo byłby bardziej przemyślany.

Innymi słowy - kod obiektowy jest wolniejszy bo ma narzuty na tworzenie obiektów, ale z drugiej strony jest bardziej "poukładany" przez co nadrabia. IMHO na szybkość kodu wpływa bardzo wiele czynników przy czym różnica w szybkości kodu strukturalnego i obiektowego jest jednym z najmniej ważnych.

Babcia@Stefa - jeśli wykonujesz 50 operacji na bazie pisząc obiektowo o 1 pisząc strukturalnie to znaczy, że coś źle zrozumiałeś jeśli chodzi o OOP.
Pisałem kiedyś sklep internetowy - jedna strona z prezentacja produktów + menu + kila bajerów powodowała wywołanie 40-50 zapytań. Działo się tak dlatego, że produkty pochodziły z różnych kategorii, miały rodzaje cech i ich ilości itd itp. Wtedy nie potrafiłem zaprojektować tego systemu poprawnie. Miałem mnóstwo obiektów, różnych tabel itd itp. Wtedy dopiero zaczynałem swoją zabawę z programowaniem.
Teraz po pół roku przepisuje ten kod, gdyż nauczyłem się kilku nowych rzeczy takich jak w miarę poprawne konstruowanie baz danych, korzystanie z dziedziczenia, kompozycji, kolekcji, fabryk itp itd. Strona realizująca dokładnie te same zadania czyli wyświetlająca wielopoziomowe menu, produkty, koszyk + więcej bajerów wywoła około 4-6 zapytań.
Obiektowość nie ma nic do rzeczy jeśli chodzi o ilość wywoływanych zapytań.

Czyli reasumując wasze wypowiedzi lepiej pisać obiektowo niż strukturalnie

Reasumując to zależy co piszesz - im coś jest bardziej "wysokopoziomowe" i złożone tym więcej korzyści odnosisz pisząc obiektowo.

Ogólnie to na prędkości najbardziej tracą chyba projekty pisane w językach kompilowanych. Dla języków interpretowanych to tylko kwestia dodatkowe listy przechowującej obiekty, albo coś w tym stylu. W językach kompilowanych to już zupełnie inna sprawa, bo tam trzeba niektóre operacje zaimplementować, które w odróżnienieniu do swoich strukturalnych odpowiedników są dużo bardziej skomplikowane a przez to wolniejsze.

Dlatego jeżeli zależy Ci na szybkości w C/C++ to pomyśl, którego z tych języków użyć, w php możesz pisać tak jak chcesz.

A tak poza tym pisanie o prędkości aplikacji pisanych w php to już w ogóle troszkę przegięcie .

KOD NAPISANY OBIEKTOWO JEST WOLNIEJSZY NIZ NAPISANY STRUKTURALNIE.
Jedna krótka odpowiedź.

Twoje argumenty są imponujące. Proszę Cię jeśli masz pisać głupoty rób to gdzie indziej ok ? Bo mnie jak i resztę Twoje bezsensowne wypowiedzi już nudzą.

Przepraszam za OT.

Cóż żeby wytłumaczyć co jest szybsze musialbym dac jakies przyklady.
A to naprawde sporo energii by mi zajelo, i jak sie domyslam nasz pytajacy ma nikle pojecie o takim
progrmaowaniu poniewaz zadaje podstawowe pytania.
Gdyby na commodore uzywali obiektowych jezykow to wypisanie hello world trwalo by tyle
co wgranie gry bez turbo abc (albo black boxa) :F

Hmmm... z tego co widze to większość odpowiedzi które uzyskałem są sprzeczne z twoim zdaniem. To po 1 .
Po 2 co ma commodore do php? Po 3 jak szkoda Ci energii to po co w ogóle piszesz posty? Mógłbyś sobie darować bo i tak są bez sensu. Po 4 nie podważaj mojej wiedzy jeśli mnie w ogóle nie znasz.

BTW. Sorry za ot ale nie mogłem się powstrzymać

Jako ciekawostka: test i jego źródło.

Tylko wypraszam sobie teksty typu 'ale w rzeczywistości' etc. Chyba że będą skierowane wyraźnie do kogoś innego ;)

A sorry... myslalem ze chodzi tu ogolnie o programowanie obiektowe... a nie o jakis php ktory tak
naprawd niejest prawdziwym jezykiem progrmaowania tlyko jakims skryptowym niewiadomo czym.

A te testy ktore przeprowadzil kolega powyzej to sa bez sensu totalnie...

Co za roznica cz wywolanie fukncji samodzielnej czy umieszcoznej w klasie?

Chcial pokazac ze niema roznicy... no na pewno na takim przykladzie niebedzie roznicy bo jest
totalnie bezsensowy. I nieukazuje roznic miedzy tymi dwoma rodzajami programowania.

@Kisiol_Ent: niech Ci będzie, że jednak napiszę kilka słów wyjaśnienia.

Wykonywanie programu napisanego obiektowo będzie zawsze nieco wolniejsze od proceduralnego. Pewien narzut, który właśnie pokazałem w teście powyżej, a którego nie zaszczyciłeś swoją uwagą w stopniu większym niż minimalny, zawsze istnieje, i nie da się tego uniknąć.

Nie zmienia to faktu, że w zależności od stopnia skomplikowania aplikacji, ten narzut maleje, by w pewnym momencie stać się niezuważalnym. Do tego dochodzą także względy ekonomiczne tworzenia, a później konserwacji programu, które przy odpowiednim kodzie obiektowym będą nieco mniejsze niż przy strukturalnym (i tak, wiem, że są różne wyjątki działające w różne strony, ale odnośnie php generalnei jest tak jak napisałem).

Kisiol_Ent: to po co tracisz czas na php?
I nie porownoj OOP z php bo to zupelnie inne dziedziny (tak jak drifting a prosche)


Za to ty przedstawiles rzeczywiscie mocne argumenty za swoja teza:


I o to chodzi, zeby napisac ten sam system na dwa sposoby OO i strukturalnie. Prosty nie, 'bo za prosty', skomplikowany nie, bo kto sie podejmie napisac go strukturalnie. OOP zostalo wymyslone zeby ulatwic pisanie skomplikowanych systemow (podzial na moduly, odpowiedzialnosc obiektow itd)



A to czemu, pokazal ze HelloWorl w obiektowym zapisie nie jest wcale tak masakrycznie wolny.

Pan o nicku "nospor" zamknal ten temat, podajac jedynie link do tego tematu, tak wiec chyba tu mam kontynuowac. Ok, juz wiem, ze programowanie obiektowe jest nieznacznie wolniejsze, ale nadal nie widze plusow takiego programowania. Czy moglby ktos podac jakis przyklad, aby wytlumaczyc mi dlaczego warto programowac obiektowo?

OOP - lepsza organizacja, lepsza orientacja w kodzie, wygoda etc. etc .etc.

kod jest bardziej przenośny bo tylko sobie plik z klasą przenosisz i możesz używać a w programowaniu strukturalnym ie da sie tak bo zazwyczaj co najmniej 60% kody trzeba przenieść, pozmieniać, usunąć... a klasa jest czysta i schludna raz dwa i działa

Wydaje mi się, że z programowaniem obiektowym to jest tak, że na początku trzeba się do niego przekonać. Pamiętam, że gdy zaczynałem pisać obiektowo (przynajmniej tak mi się wtedy zdawało) to mówiłem sobie, że to jest fajne, ale za bardzo nie wiedziałem dlaczego. Prawda jest taka, że na początku przenosi się na OOP schematy z programowania proceduralnego i jest się trochę trudno połapać, zawsze czegoś brakuje, coś się wydaje bez sensu.

OOP daje prawdziwego "bosta" dopiero przy trochę większych projektach, gdzie można zastosować wzorce, polimorfizm czy dziedziczenie - tam gdzie potrzebne są zgrabne interfejsy klas i możliwe jest ukrycie pewnej złożoności systemu - czyli jego detali.

W mojej opinii (choć bazuje ją tylko na swoim przykładzie) paradoks OOP polega na tym, że gdy zaczynamy się go uczyć dotykamy tylko czubeczka góry lodowej korzyści i nie potrafimy go tak na prawdę stosować. Jest to po prostu inna składnia, w której piszemy starym stylem - łatwo się zniechęcić. Dopiero przy odrobinie praktyki i kilku wdrożonych mechanizmach uwidacznia się ta cała gama korzyści.

Kiedyś czytałem książkę o UML (zresztą całkiem słabą), ale jedno zdanie mi trochę utkwiło i po przemyśleniu wydaje mi się to największą zaletą OOP - jest to po prostu możliwość generalizacji i składania. Jeśli jest mi potrzebny dostęp do opony samochodowej to pracuje na klasie Opona, za chwilę mogę przenieść się do klasy samochód i zapomnieć o oponie - to samochód troszczy się o współpracę z oponą. A jeśli potrzebuję korek w mieście to generuję sobie kolekcję samochodów i znowu mam jedną klasę. Proste i eleganckie rozwiązania :-)