Trochę piszę w php, ostatnio nawet zacząłem czytać o programowaniu obiektowym. Wszystko ładnie pięknie, rozumiem jak to działa, ale nie wiem po co mi to do szczęścia. Programuję strukturalnie i na razie nie widzę potrzeb pisania obiektowego: kodu nie udostępniam, bo piszę dla siebie albo do pracy, a tworzenie całej klasy aby stworzyć jeden obiekt wydaje mi się nieco zbędne. To tak jakbym dostał młotek wraz z instrukcją obsługi, ale nie wiem wogóle po co mam wbijać gwoździe.
Proszę o łopatologiczne wyjaśnienie "potrzeby wbijania gwoździ", czyli progamowania obiektowego.

Takich pytań jak Twoje przewijało się na forum już dużo.
Nie chcesz, nie pisz. Życie prędzej czy później samo ci wyjaśni "po co".

W tym problem, że chcę tylko jakoś nie widzę, co mi to daje...

To skoro chcesz to zacznij to robić.

Właśnie zacząłem, ale tak mechaniczne. Wolałby jednak rozumieć po co robić klasy i obiekty, jak można to zrobić strukturalnie.

BTW
Wyszukiwarka postów wywala błąd: Wystąpił bląd. Wróć i spróbuj ponownie.
connection to localhost:3312 failed (errno=111, msg=Connection refused)
Co jest nie tak?

google -> programowanie obiektowe co daje
I ja tam znalazłem parę ciekawych informacji dla początkujących. Skoro "chcesz" to poszukaj wpierw trochę sam, a potem ewentualnie dopytuj o szczegóły.

ps: tak, wyszukiwarka forum nie działa.

Łatwa rozbudowa, porządek, szybkość działania aplikacji, itd.

Samo OOP może Ci nie wiele wyjaśnić, ale w połączeniu z MVC dostrzeżesz korzyści.

Łatwa rozbudowa owszem,porządek także ,ale z szybkością działania nie mogę się zgodzić.Czytałem trochę i kod napisyny strukturalnie jest wykonywany szybciej niż pisany obiektowo,choć pewnie różnice nie będą, aż tak widoczne dla normalnego użytkownika.

A co sądzicie o takim sposobie-główny "szkielet"(silnik) aplikacji pisany strukturalnie.Rozbudowanie aplikacji o np.dodatkowe ficzery już pisane obiektowo.

Wiadomą sprawą jest, że przy prosty/ małych aplikacjach, kod strukturalny sprawdzi się lepiej i jego szybkość również będzie lepsza. Inaczej to wygląda przy dużych serwisach, z dużym ruchem.

Wiadomo,że przy dużych aplikacjach się tego nie robi.Wyobrażasz sobie pewne moduły zamieszczone przykładowo w 10 klasach, sprowadzone do jednego pliku?Wyobraź sobie kod z 10tyś linijek i teraz wyszukaj w takim kodzie konkretną linijkę konkretnego modułu,aby coś poprawić.Wydaje mi się że i tak pisane strukturalnie by byłą szybsze niż pisane obiektowo(odchodzi czas dostępu i wczytywania zewnętrznego pliku),ale tego się nie robi ze względu na ewentualną konserwację,modernizacje i rozwój.

Gadasz teraz głupoty. Stwórz sobie plik php z kodem składającym się z 10 tys linijek a potem go odpal. Przekonasz się wówczas, że wczytywanie z plików tylko tego co potrzeba, jest o wiele wiele wiele razy wydajniejsze.

ps: poza tym 10tys linijek to zajmuje wstęp do średniej wielkości aplikacji. W takich 100tys to już można coś napisać

Ale jak to robisz:
Pierwszy sposób:

[PHP] pobierz, plaintext 
if(warunek1){
include(klasa.php)}
else{
include(klasa2.php)
}
[PHP] pobierz, plaintext 

Drugi sposób:

Drugi sposób będzie szybszy,lecz mniej czytelny niż 1, gdyż od razu następuje wykonywanie kodu po określonym warunku.W pierwszym sposobie po spełnionym warunku następuje odczyt pliku z katalogu i egzekucja kodu.

Tylko wariat pisałby taką aplikację strukturalnie

Widzę nie zrozumiałeś.... o wykonanie tego co prosiłem już nie wspominam...

Kod, który ma 10tys linijek w jednym pliku jest wolniejszy od wczytania kilka plików z kodem, który akurat teraz potrzebujemy.
Jest wolniejszy i zżera o wiele więcej pamięci. Gdy tego kodu będzie jeszcze więcej, to aplikacja ci w ogóle padnie. Paniał?

W pełni się z tobą zgadzam ,ty mówisz o czasie dostępu do pliku i będzie on dużo większy niż rozbijając to na wiele plików,gdyż sam rozmiar pliku jest większy,wzrośnie też zużycie zasobów,ale ja mówiłem o egzekwowaniu samego kodu.
Dajmy na to został już wczytany plik z 10tyś linijek(będzie to trwało dłużej,zużycie pamięci większe),ale wykonanie już kodu w tym pliku będzie trwało krócej,gdyż brak już jest jakichkolwiek odwołań do zewnętrznych plików,które także zawierają jakiś tam kod.

Ja się staram pisząc u siebie nie przekraczać 2tyś linijek,tak aby to jeszcze ogarnąć ,resztę pakuję w klasy.

Ale wykonanie kodu to też jego wczytanie i sparsowanie. Wiec dla dużych plików aplikacja tak czy siak będzie działała wolniej. Wiec wniosek jeden: robijać na pliki niezależnie czy piszesz obiektowo czy strukturalnie.

Zgadzam się ,ciekawe jak to się ima do języków kompilowanych,gdzie kompilacja następuje tylko raz.

Zależy od języka, może być różnie np. z Javą, C# bo one kompilują do kodu, który rozumie ich maszyna, co innego C/C++ etc.

Ale i tak wątpię, że ma to jakiekolwiek znaczenie, kompilujesz raz.

Nie ma różnicy w językach natywnie kompilowanych, czy kod będzie w jednym pliku, czy w wielu.

Edit: Oczywiście miałem na myśli tylko szybkość wykonania

a ja bym powiedział tak jeden z kolegów wyżej, żeby spróbował mvc np. jakiś framework
bo faktycznie może się wydawać że równie dobrze mogą być zwykle funkcje pisane strukturalnie, jak i metody klasy i niczym się nie różni - dobry przykład podstawą

- żadna poważna firma, która zna się na rzeczy, nie przyjmie Cie do pracy jak nie masz pojęcia o OOP.
- żaden rozbudowany projekt (niech będzie 5k linijek) nie ma szans się rozwijać, gdy jest napisany strukturalnie, szczególnie gdy mają nad nim pracować więcej niż 2 osoby.
- OOP jest po to min. żeby nie powielać 50razy tego samego kodu... np. chcesz pobrać treść newsa, piszesz:



zamiast całych funkcji łączenia z bazą. Do tego dochodzą loadery klas np. SPL które załadują plik z klasą wtedy gdy jest potrzebny... strukturalnie, jakoś nie bardzo to widzę. I najważniejsze, chcesz zmienić coś w pobieraniu newsa? zmianiasz tylko metodę getNews(); w 1 pliku, a nie tam gdzie zrobiłeś do niej odwołanie.

Dokładnie. Dalsza modyfikacja poprzez poprawianie tudzież usprawnianie jest o wiele przyjemniejsza, bo nazwy danych metod/właściwości/stałych zostać mogą takie same, a robić mogą zupełnie coś innego.

Do tego dziedziczenie, wzorce i można sporo zaoszczędzić sobie czasu oraz ilości kodu który będziemy musieli nastukać.

Też kiedyś myślałem, tak mi się wydawało, i uważałem że to jest zbędne. A teraz średnio potrafię akceptować kod strukturalny, zwłaszcza takich średnich lotów

Słyszałeś o linuksie? Ma o wiele więcej niż 5k linijek, rozwija się i pracują nad nim więcej niż 2 osoby.


A słyszałeś o funkcjach?


Chyba nigdy nie widziałeś kodu ludzi cierpiących na obiektofilie i wzorcologie, którzy wszędzie widzą dziedziczenie. Takie coś to dopiero cięzko rozbudować.


Ja mam to samo, tyle że z kodem obiektowym.

To linux jest napisany w PHP? Strukturalnie? WOW.



Słyszałem. Odpowiadają za wykonywanie małych czynności, do bardziej rozbudowanych używa się klas. Bo jakoś nie wyobrażam sobie np. odczytu pliku html przez funkcje odczytaj_html() a cokolwiek innego np. wczytaj tylko znaczniki z pliku x z funkcji znaczniki_html() jak mogę zrobić klasę

[PHP] pobierz, plaintext 
$x = new costamhtml;
$x-> getCode();
$x-> getZnacznik('a');
[PHP] pobierz, plaintext 

I nie ogranicza mnie kolizja nazewnictwa, w innych klasa też mogę użyć getCode(), a spróbuj coś takiego zrobić przy samych funkcjach.




Chodzi Ci o to że wszędzie to wykorzystują? Tak, też czasami śmiać mi się z tego chce

Bez sensu taka rozmowa. Jedni preferują programowanie strukturalne, inni obiektowe. Jeśli nikt tego od Ciebie nie wymaga programowania obiektowego to rób to, na co masz ochotę.
Wszystko co da się zrobić programując obiektowo można osiągnąć programowaniem strukturalnym / proceduralnym. Wcale nie jest prawdą, że kod napisany obiektowo jest łatwiejszy do analizy lub modyfikacji. Kod napisany strukturalnie nawet składający się z kilkuset tysięcy linii kodu, ładnie podzielony na pliki, jest tak samo czytelny jak napisany obiektowo.

Wkrótce w podręcznikach pierwszy skrypt zapewne będzie wyglądał tak:

[PHP] pobierz, plaintext 
class greeting {
 
    function sayHello() {
 
        echo 'Hello world!!!';
 
    }
 
}
 
//-------------------------------
 
$greeting = new greeting();
 
$greeting->sayHello();
[PHP] pobierz, plaintext 

ps. Nie jestem zagorzałym fanatykiem programowania strukturalnego, większość rzeczy piszę obiektowo. Denerwuje mnie tylko wciskanie na siłę obiektówki, tych wszystkich frameworków, mvc itp. Chyba Microsoft w to inwestuje po to, żeby wszystko sprowadzić do poziomu Windowsa

Niektóre FW są fanatykami dziedziczenia, to nie zawsze jest korzystne. MVC to raczej standard, tzn. jeden z popularniejszych wzorców, który się po prostu sprawdza i co MS ma do tego?



Tylko zmień coś w tych kilku tysiącach liniii kodu i pewien jesteś że gdzieś indziej kod się nie posypie? Strukturalnie masz zmienną $x, ktoś inny utworzy taką samą zmienną w innym pliku i co? Kod przestaje działać. To jest właśnie ta przewaga OOP.

Kiedyś tak samo myślałem, że pisanie kodu obiektowo to wymysł by wyciągnąć więcej kasy od klientów. Wygląda bardziej pro. Ale kiedyś dostałem do poprawek jedną stronę w kodzie strukturalnym i obiektowym , poznałem potęgę. Od tej pory nie wyobrażam sobie pisania inaczej niż obiektowo na jakimś wzorcu

Oby podręczniki nie popełniały wyżej zademonstrowanych błędów.

Tak przepraszam, zapomniałem o public, no chyba że chodzi Ci o to, że nie zaimplementowałem mvc.



Ogólnie to nie chodziło mi o pokazanie, że programowanie obiektowe jest gorsze, tylko jestem zdania, że każdy powinien pisać tak jak woli (nie licząc oczywiście projektów grupowych, gdzie trzeba się liczyć z większością). Programowanie obiektowe pomaga tylko i wyłącznie w pracy programiście, nie ma żadnego znaczącego wpływu na wydajność aplikacji. Umysł każdego z nas inaczej przetwarza obrazy, tzn dla niektórych bardziej czytelny będzie kod napisany obiektowo, dla innych strukturalnie. Sam osobiście preferuję obiektowo, chociaż przez prawie 20 lat większość rzeczy pisałem strukturalnie (głównie przez to, że w assembler za bardzo się do tego nie nadaje).

OOP jest świetne, gdy wiesz, o co w tym chodzi Sam kilka razy próbowałem się nauczyć programowac obiektowo, zanim mi się to udało. To po prostu trzeba zrozumieć. Interfejs ponad implementację, to bardzo ułatwia pracę z poprawianiem kodu. Btw. mogę się mylić, ale moim zdaniem programowanie zorientowane obiektowo wykorzystuje paradygmat programowania proceduralnego (metody), zaś ono wykorzystuje często też paradygmat strukturalny, czyli właściwie pisząc obiektowo, piszesz strukturalnie oraz proceduralnie.

Public swoją drogą ale np. metody nie powinny printować a zwracać