•  

    Nie rozumiem OOP.

    Rozumiem na czym polega, rozumiem że kod jest przez to czytelniejszy, umiem go wykorzystać, jednak nie widzę praktycznych zalet wykorzystywania tego typu programowania.
    Wszyscy mówią, że takie pisanie kodu jest jedynym słusznym, wierzę, że tak jest. Problem z tym, że pisząc jakikolwiek projekt nie mogę znaleźć powodu, by bawić się w definiowanie klas, obiektów, metod, kiedy mogę to zrobić zamiast w 10 linijkach to w 2.
    Mam na swoim koncie kilka płatnych projektów, największy zajął mi 6 miesięcy, m.in. zawierał autorski CMS. Wszystko strukturalnie. Brak jakiegokolwiek doświadczenia z kimś kto patrzyłby na pisany przeze mnie kod sprawia, że jedynym warunkiem jaki sobie stawiam to to czy kod działa, nie wiem jak niektóre rzeczy powinienem rozwiązać ze względu na "sztukę programowania" itp.

    Zwykle gdy się uczę nowej technologii, frameworka bariera między "nie rozumiem nic", a "rozumiem wszystko" jest bardzo cienka. Czytałem o OOP naprawdę dużo, umiem to zastosować, ale ciągle nie widzę sensu.

    Poniżej jeden z napisanych przeze mnie kodów, nie zjedzcie mnie pls.

    #naukaprogramowania #php

    •  

      @Jurix: Ja tylko napiszę, że jeżeli masz 5 poziomów zagnieżdżeń ifów, to wiedz, że coś się dzieje

    •  

      @Jurix: nie testujesz jednostkowo funkcji, prawda? podejrzewam, ze testy manualne to maks, jaki robisz, a kodu sam dlugo nie musisz utrzymywać i nie wspolpracujesz nad nim z innymi ludzmi. we wlasnym sosie niektorych mechanizmow faktycznie sie nie potrzebuje i to rozumiem. ale programisci nie tworzą systemów w pojedynke. oop daje narzut, ale też możliwości.

    •  

      @uirapuru: Nie testuję jednostkowo (chyba), szczerze to nie wiem nawet co to znaczy. Tą stronę z CMS'em robiłem w 4 osobowym zespole, którym ja zarządzałem.

      @joolekk: Jasne, że nie. Ta książka jest ogólna, czy dotyczy/odnosi się do jakiegoś konkretnego języka?

    •  

      @Jurix: bardzo ogólna.

      Co by było gdybyś musiał przekazać swój projekt komuś?

    •  

      @Jurix: doskonale rozumiem, że można sobie radzić bez opp. mozna nieźle w php programować funkcyjnie na przykład. rzecz w tym, że jeżeli nie jesteś w mainstreamie, będzie ciężko wspołpracować Tobie i innym. Ale to nie jedyny powód

    •  

      @Jurix: Widziałeś kiedyś "legendarny" kod źródłowy pierwszego MS Office? To m.in. z myślą o takich potworkach powstały pewne standardy i paradygmaty programowania obiektowego. Zajmie ci to niewiele więcej, a zyskać możesz na tym bardzo dużo.

    •  

      @joolekk: Zamysł taki był od samego początku, wszystko jest odpowiednio komentowane, a zmienne (w większości) zrozumiale nazwane. Struktura plików na serwerze jest przystępna, a dodatkowo opisana w dokumencie tekstowym, aby w razie ewentualnych zmian lub poprawek wiedzieć gdzie czego szukać.
      @push3k-pro: Nie widziałem, pewnie i tak bym nie zrozumiał.

      "Czytelniejszy kod" to pojęcie względne, bo jestem pewny że dobrze napisany strukturalnie kod jest czytelniejszy od źle napisanego OOP. Z tego powodu ciągle nie rozumiem idei pisania w ten konkretnie sposób.

    •  

      Mam na swoim koncie kilka płatnych projektów, największy zajął mi 6 miesięcy, m.in. zawierał autorski CMS. Wszystko strukturalnie.

      @Jurix: czyli robisz niewielkie rzeczy w których nie współpracujesz z innymi, nie utrzymujesz tego i nie przejmujesz kodu po kimś. Dodatkowo stawiam na brak testów i inne typowe problemy w takich sytuacjach, w efekcie powstają takie potworki jak na Twoim obrazku. Na tym etapie nie dziwi że masz takie odczucia, ale jak zaczniesz robić cokolwiek większego lub żyjącego dłużej (i rozwijanego, a nie na zasadzie że stoi zapomniane pięć lat) to zobaczysz czemu tak jednak jest lepiej.

    •  

      @Jurix: z tym że dobry kod jest czytelniejszy od złego to się zgadzam. xD

      Ale twój strukturalny jest czytelniejszy dla ciebie. Nikt kto na co dzień pisze obiektowo nie zrozumie na pierwszy rzut oka tego co napiszesz.

    •  

      "Czytelniejszy kod" to pojęcie względne, bo jestem pewny że dobrze napisany strukturalnie kod jest czytelniejszy od źle napisanego OOP. Z tego powodu ciągle nie rozumiem idei pisania w ten konkretnie sposób.
      @Jurix: Pewnie, ale to powstało dla wszystkich, a nie dla ciebie i z myślą taką, że to będzie działało baaaaaardzo długo i na skalę globalną.

      +: joolekk
    •  

      @Jurix: sensem oop nie jest 'pisanie klas' a delegowanie zadań (do wyspecjalizowanych obiektów)
      masz np: komentarz w kodzie

      Sprawdzenie jakie $IDMenu ma strona o ID $IDStronyMenu
      możesz zacząć od refaktoryzacji kodu by komentarz nie był potrzebny

    •  

      @Jurix: i tak jak napisał @aseeon_

      w OOP czysto i ładnie rozbijesz swoje ify na max kilka linii

      +: Jurigag
    •  

      @Jurix: a co jeśli w innym miejscu kodu będziesz chciał sprawdzić

      jakie $IDMenu ma strona o ID $IDStronyMenu
      ?

      znów skopiujesz ten sam kod z tym samym komentarzem?

      Nie łatwiej byłoby zlecić to zadanie np. obiektowi który zajmuje się m.in obsługą DB?

    •  

      @xetrov: Z Twojej wypowiedzi mogę wywnioskować, że mogę ten temat olać i czekać na komercyjne projekty z kimś doświadczonym nad sobą. A na takie coś mogę liczyć najwcześniej za rok. To sporo czasu, a fajnie na start pracy znać takie "podstawy".

      @joolekk: Zazwyczaj w takich sytuacjach robię sobie stosownie nazwaną funkcję, która jest we wspólnym pliku functions.php, załączanym do wszystkich skryptów.

    •  

      @Jurix rozumiem, że łatwiej Ci pierdolnąć 4 includy w każdym pliki osobno, niż zrobić core class w którym tworzysz instancje połączenia do bazy wraz z poszczególnymi metodami autoryzujacymi i potem tylko excludowac core przy nowej klasie? Pracuje obecnie na dużym projekcie w "czystym" PHP i uwierz mi, co innego zrobić i oddac, a co innego modyfikowac/optymalizować/zabezpieczać bez OOP

    •  

      @Jurix: Jeżeli to nie bait, to zmień język.

    •  

      @Jurix:
      Tak naprawdę, przy małych projektach do szuflady, to OOP większego sensu nie ma. Ale nigdy nie wiesz jak Twój projekt skończy, i jak będzie się rozwijał w przyszłości. A mądrze zrobione OOP (ale mądrze, to że se gdzieś class wpiszesz nie wystarczy) daje dużo większą możliwość rozwijania projektu. Zobacz - tutaj pokazałeś kawałek kodu który zapisuje w bazie jakąś stronę. Pewnie masz w aplikacji analogiczne kawałki zapisujące np. komentarze, kategorie i tego typu rzeczy. One z punktu widzenia logiki programu nie mają ze sobą niczego wspólnego, mimo że zadanie do wykonania jest bardzo podobne. I wyobraź sobie teraz, że masz dorobić jakąś funkcję śledzenia zmian - właściciel strony zatrudnił pracownika i chce zawsze mieć możliwość podejrzenia co kto kiedy w czym zmienił. I okazuje się, że musisz zmodyfikować KAŻDE miejsce w którym cokolwiek zapisujesz do bazy, bo jedynym wspólnym punktem jest mysqli_query na które nie masz żadnego wpływu. A jak coś zmieniasz, to musisz przetestować każdy jeden zapis do bazy. Możliwe, ale roboty masa. A jak z tym skończysz, to klient powie "a weź jeszcze IP skąd był zalogowany tutaj dorzuć".

      Jeśli w tym punkcie ciągle się do OOP nie przekonasz, to zapewne napiszesz to proceduralnie, i zobaczysz wielki wzrost szybkości pisania, bo zaczniesz używać kodu ponownie zamiast robić kopiuj/wklej.

      OOP to następny krok po pisaniu funkcji - po prostu lepsze narzędzie do używania kodu ponownie. Dużo łatwiej wydzielić sobie bardziej "ogólne" kawałki kodu (np, każdy zapis do bazy jest podobny, mimo że pisze różne dane do różnych tabel, ale też wszystko co ma zrobić aplikacja jest w jakiś sensie akcją i ma jakieś parametry, więc jest do siebie podobne - nieważne czy jest wywołane z konsoli, z przeglądarki przez serwer, czy może po prostu z innego kawałka kodu), bo masz do tego narzędzia typu dziedziczenie.

      Dodatkowo mocno wzrasta czytelność kodu, nie masz wszystkiego ze sobą wymieszanego. new Strona($_POST['strona']) -> save() jest dużo czytelniejsze niż wpisanie wszystkiego ciurkiem jedno pod drugim. Zobacz co będzie kiedy dojdą tam jakieś walidacje, jakieś wersje językowe...

      Do tego jeszcze dochodzą Ci nowe możliwości typu testy jednostkowe, ale tak naprawdę nie mieszałbym tego do zagadnień OOP.

      A tak przy okazji, to masz kosmiczne dziury na SQL Injection w tym kodzie co pokazałeś, weź sobie o tym doczytaj, bo jeśli bierzesz pieniądze za programowanie to trochę głupio takie dziury robić :)

    •  

      @Perfer: Łatwo mówić przez pryzmat swoich projektów i doświadczeń, jednak przy małym doświadczeniu jakie ja posiadam wciąż nie mogę zastosować tej wiedzy w praktyce, nie mogę znaleźć, wyobrazić sobie konkretnej sytuacji, konkretnego skryptu czy projektu w którym takie rozwiązanie naprawdę ma sens. Tak jak mówię, wynika to tylko z mojego doświadczenia.
      @cooltang: Naprawdę chciałbym poznać ścieżkę Twojego rozumowania, po której mogłeś pomyśleć że moje pytanie jest baitem.

    •  

      @kao3991: Hm, o takie podejście mi chodziło. Brzmi rozsądnie, logicznie i przede wszystkim konkretnie, o to mi chodziło :)
      Następny projekt jaki będę pisał spróbuję w pełni obiektowo.

      A co do sql injection, nie mam pojęcia jakim cudem mogłem tego chociaż podstawowo nie zabezpieczyć, niby jest to wewnętrzny panel admina, jednak nie zmienia to faktu, że zabezpieczenie musi być. Pozostałe skrypty są zabezpieczone.

    •  

      @Jurix: Czemu bait? bo piszesz, że nie rozumiesz oop, a potem że używasz php :) Zainteresuj się asp.net core albo springiem, testami jednostkowymi, dependency injection, czystym kodem, SOLID.

      +: Jurix
    •  

      @Jurix prawda jest taka, że nie przekonasz się do OOP i tych wszystkich DRY'i itp., póki nie trafisz na 10 letnią rzeźbę jakiegoś dziadostwa, które musisz przerobić pod nowe założenia, ale "ma działać jak dotychczas". ;)

      W każdym razie, nie przejmuj się, rób swoje, doksztalcaj się, doświadczenie przyjdzie samo, tylko trzeba iść do przodu, małymi lub większymi kroczkami.

    •  

      @Jurix: o Panie, też tak kiedyś pisałem, musisz się nauczyć delegowania zadań do specjalnych obiektów, które mają tylko jedną odpowiedzialność, następnie poczytać o wzorcach projektowych i je po mału wdrażać, nauczyć się wspoldzielic kawałki kodu żeby go nie powielać. Ale pierwsze co to zacznij pisać kod po angielsku, nie uciekniesz od tego, im prędzej zaczniesz tym lepiej dla Ciebie. Niech angielski idzie równo w parze z programowaniem, bo znacznie Cię on blokować prędzej czy później.

    •  

      @veranoo: na Twoim przykładzie:

      napisałeś kod i teraz klient mówi ze oprócz tytułu i treści strona musi mieć jeszcze autora, datę i godzinę utworzenia i wszystkie istniejące strony (stworzone bez tego) trzeba zaktualizować o te pola.

      Jak się do tego zabierasz w swoim kodzie?

    •  

      @Jurix: Tłumaczą Ci od dłuższego czasu po co używać OOP, a ty dalej swoje:

      Łatwo mówić przez pryzmat swoich projektów i doświadczeń, jednak przy małym doświadczeniu jakie ja posiadam wciąż nie mogę zastosować

      Jakbyś pracował jako kopacz rowów. Szef do Ciebie mówi "młody bierz koparkę i kop" a ty jak pizda stoisz i kopiesz łopatą, bo nie widzisz zastosowania koparki. To jest to samo...

      Przy małych projektach pewnie nie ma to sensu. Ale jak masz duży projekt gdzie dużo rzeczy musisz obsłużyć i przetestować to jest ciężko. Ściągasz frameworka, który dostarcza Ci routing, szablony, ORM, mvc i kilka innych przydatnych narzędzi i lecisz. A nie napieprzasz 40 ifów do obsługi GETów i POSTów. Już nie wspomnę o wzorcach i schematach, które przyspieszają pracę oraz umożliwiają wdrożenie się nowym programistom.

      A jak to dalej Cię nie przekonuje, zobacz oferty pracy. Zwykły makaroniarz z kilkuletnim stażem zarabia 2-3k PLN, natomiast znając już OOP, frameworki itp 5-10k. Coś więcej chcesz?

    •  

      @Jurix: ja ze swojej strony mogę Ci powiedzieć, że dużo lepiej udało mi się zrozumieć OOP dzięki PHPowym frameworkom. Idealnie do tego celu nadaje się Symfony, które na pierwszy rzut oka wydaje się ciężką do zrozumienia kobyłą, ale dzięki takim kursom jak np knpuniversity można łatwo dostrzec, że to bardzo proste i przyjazne programiście narzędzie.

      Nie poddawaj się i próbuj, jeżeli tylko nie zabraknie Ci siły to sam będziesz zaskoczony jak naturalne stają się wszystkie te sprawy.

    •  

      @Jurix: Skorzystaj z frameworka. Może być choćby Laravel. Framework narzuca styl kodowania. Przez co z czasem zrozumiesz jaki w tym wszystkim sens, o ile kod jest przejrzystszy i łatwiej o jego rozbudowę. Zaczynałem programować w PHP w czasach, gdy OOP w PHP praktycznie nie istniało i też później miałem problem z przestawieniem się. W tej chwili jednak nie wyobrażasz sobie, abym mógł wrócić do starych nawyków.

      +: Jurigag
    •  

      @buntuubuntu: dodaje odpowiednie pola do modelu danych i przekazuje je do widoku

    •  

      @Jurix: No siema, pokuszę się o odpowiedź, bo moim zdaniem to jest bardzo dobre pytanie, którego niestety wiele programistów sobie w życiu nie zadała i efekt jest niestety smutny. Używają fancy bibliotek i frameworków, ale ich kod jest wciąż chujowy, bo nawet o tym nie wiedzą. Framework jest tylko małą podstawą projektu i im więcej jest autorskiego kodu tym projekt jest cięższy w utrzymaniu, bo ich kod autorski jest po prostu nie przemyślany. Ale wciąż myślą, że wszystko jest ok, tak powinno być.

      Zacznijmy od tego, że każdy program da się napisać strukturalnie. Absolutnie każdy. Co to oznacza? Oznacza, że OOP nie daje nowych możliwości w sensie o jakim myślisz, czyli że czegoś by się nie dało zrobić bez OOP. Przynajmniej teoretycznie.

      OOP daje zalety innej kategorii, a mianowicie pomaga w pracy programiście. OOP ma zalety w dwóch segmentach.

      Pierwszy, to strukturyzacja kodu. Ta część jest oczywista i pewnie osoby powyżej już o tym pisały (nie chciało mi się czytać poprzednich komentarzy ;-) )
      - w OOP tworzysz ograniczone konteksty, dzięki czemu widząc zmienną, nie musisz szukać bo całym projekcie, czy gdzieś ta zmienna jest jeszcze użyta, jaka może być jej wartość, żeby czegoś nie zepsuć. Czyli nie musisz myśleć o całej bazie kodu pracując na małym wycinku, bo wiesz, że jak jesteś wewnątrz klasy, to nic z zewnątrz nie ma dostępu do jej wnętrza poza interfejsem publicznym.
      - taki kod jest łatwiejszy w testowaniu automatycznym. Możesz zapytać po co te całe testy, ale to juz odrębny temat.
      - oczywiście dochodzą takie rzeczy jak reusability, czyli masz kod którego używasz w wielu miejscach. To samo można osiągnąć stylem proceduralnym. Mam nadzieję, że wiesz jaka jest różnica między strukturalnym , a proceduralnym. ;-)

      Na tej pierwszej części niestety wielu programistów się zatrzymuje. Przez to traktują klasy jako worki na funkcje, co nie jest dobre. Druga część, to semantyka kodu. Klasom/obiektom nadajemy znaczenie w sensie logiki biznesowej. Nadajemy im zachowanie i właściwości. W ten sposób łatwiej jest operować na skomplikowanych projektach. Uczą tego na każdym podstawowym kursie OOP - zaczynasz od klasy "samochód", klasa ma metody jedz, zatrzymaj itp itd. Potem jakoś ludzie o tym zapominają i klasa staje się jedynie strukturą w kodzie bez większego znaczenia.

      Dodatkowo podsumowując do obu zakresów (struktury i semantyki) dochodzą dodatkowe rzeczy, poniekąd wynikające z już wspomnianych.
      Pisałeś, że robiłeś projekt przez 6 miesięcy. To niedużo. Pracuj nad nim mocno modyfikując go przez 5-10 lat, zobaczysz, że wkrótce będzie Ci ciężko coś zmienić. Potem zostaw ten projekt i wróć do niego po 3 latach. Zobaczysz, że ciężko Ci będzie sobie przypomnieć co gdzie znaleźć, oraz co jak działa. Odnalezienie się w kodzie będzie wymagało długich godzin przesiedzianych na czytaniu kodu.

      Generalnie wszystko jest po to, żeby dało się ogarnąć bardziej złożony kod. Samemu, jako początkujący programista, przez 6 miesięcy nie napiszesz dużego programu. Pomyśl ile kodu napisze przez kilka lat cały zespół dobrych zawodowych programistów. Do tego te 6 miesięcy, to jest nic. Projekty długoterminowe to projekty kilku-kilkunastoletnie.

      P.S. Co do Twojego kodu:
      - SQL Injection motzno. Nigdy nie ufaj danym z zewnętrz. POSTem można przysłać cokolwiek.
      - Pisz kod po angielsku, bo źle się czyta, gdy masz mieszankę angielskiego i polskiego. Do tego ciężko będzie Ci pomóc np. gdy zadasz kiedyś pytanie na StackOverflow podając taki kod.
      - Jak widzisz, stosujesz komentarze, że opisać, co robi kod. To jest błąd. Kod się zmienia, a komentarzy nikt nie poprawia, więc potem tylko utrudniają. Dlatego kod sam z siebie powinien wyglądać tak, żeby czytając go od razu było wiadomo, co robi.
      - Jakbyś sobie wyobrażał teraz zmianę bazy danych np. na PostgreSQL albo Redis? Latasz po całym kodzie i szukasz gdzie robisz jakieś zapytania i martwisz się czy da się analogicznie zrobić w innej bazie? A jak nie, to już widzę jak zmieniać cały przepływ danych mając 5 zagnieżdżonych if-else'ów. Powiedzmy, że baza nie wyrabia. Jak teraz tutaj chciałbys dodać warstwę cache'a zapytań? I jeszcze na koniec sobie wyobraź że takich kwestii na przestrzeni czasy w produkcyjnym kodzie jest mnóstwo. Czyli w pewnym momencie takie zmiany musisz robić mając w takim pliku kilka tysięcy linii kodu.
      - Tak poza tym, ogólnie kod ultra chujowy. Wynika co z całego mojego komentarza. Czyli problematyka tego kodu wynika z wiedzy, co może pójść nie tak w przyszłości przez to, że teraz zrobiłeś to tak jak zrobiłeś.

      To tak w skrócie. ( ͡° ͜ʖ ͡°)

    •  

      @Jurix: napisz stronę korzystając z jakiegoś frameworka mvc. Zrozumiesz.

    •  

      @Jurix: myśle że dla Ciebie jest ok ale dla innych będzie problem zrozumieć kod. Podaj nam jakiś przykładowy plik. Ocenimy ;)

    •  

      @Jurix: Oprócz tego co inni piszą OOp to jeszcze 2 fajne rzeczy. Pierwsza to autoloading. Przy większym projekcie masz dożo plików i musisz się jebać z includami. Nie dość, że ciężko w takim kodzie coś zmienić, to jeszcze za każdym razem jest ładowany cały kod do pamięci php (chyba, że masz include w ifach). W przypadku OOP ładowane są tylko te klasy które faktycznie są w użyciu. Najlepszy przykład: wyobraź sobie, że twoja apka ma jakiś system templaek, ale również system fakturowania, koszyk i jakieś endpointy restowe. Jaki jest sens includowania tego wszystkiego, kiedy chcesz tylko wypluć jakiegoś jsona na enpoincie? Albo jaki jest sens ładować templatki, kiedy potrzebujesz tylko wygenerować fakturę?

      Druga, chyba najlepsza rzecz w OOP to dziedziczenie i interfejsy. Wyobraź sobie, że masz klasę robiącą fakturę z zamówienia. Klasa zamówienia implementuje interface funkcji która powinna zwracać całkowitą kwotę zamówienia.
      Teraz przychodzi szef i mówi, ze chce mieć w określonych przypadkach cały koszyk za free. Zamiast napierdzielać ifami, dodajesz klasę która dziedziczy po interfejsie zamówienia i zwraca 0 dla tej funkcji. Nie musisz nic zmieniać w kodzie generującym faktury itp. A jak szef będzie chciał kupony zniżkowe to wystarczy dodać klasę której możesz podać przy tworzeniu o jaki procent jest przecenione zamówienie i już. Tak samo gdy chcesz dodać kupon odejmujący x zł przy zamówieniu.
      Wykorzystując dobrze OOP jesteś w stanie tworzyć kod o wiele bardziej elastyczny. Może nie jest to tak istotne dla małych projektów, ale duży projekt napisany na funkcjach to masakra.

    •  

      Czytałem o OOP naprawdę dużo, umiem to zastosować, ale ciągle nie widzę sensu.

      @Jurix: OOP jest też po części po to aby rodzielić widok od logiki, podzielić aplikację na części, wydzielić wspólny kod do obiektów, no i autoloading a nie jakieś pisanie include, no i dziedziczenie i interfejsy, często w aplikacji masz sobie np jakiegoś zwykłego użytkownika czy klienta w systemie który nie musi mieć konta, oraz administratora który musi mieć itd, i ten administrator może dziedzczyć pola po użytkowniku, poza tym ORM, jak można pisać jakieś zapytania, inserty, update itp itd wszystko samemu jak ORM bardzo ułatwia robotę?

      poza tym ty w tym kodzie masz SQLi, wtf is this? > Tak naprawdę, przy małych projektach do szuflady, to OOP większego sensu nie ma.

      @kao3991: oop może i nie, ale warto i tak skorzystać z jakiegoś microframeworka typu slim i jakiegoś orm i wydzielić widoki a nie pisać jakieś echo

    •  

      Z Twojej wypowiedzi mogę wywnioskować, że mogę ten temat olać i czekać na komercyjne projekty z kimś doświadczonym nad sobą. A na takie coś mogę liczyć najwcześniej za rok. To sporo czasu, a fajnie na start pracy znać takie "podstawy".

      @Jurix: nikt cię nie przyjmie do programowania nad komercyjnym projektem bez praktycznego doświadczenia z OOP

    •  

      A co do sql injection, nie mam pojęcia jakim cudem mogłem tego chociaż podstawowo nie zabezpieczyć, niby jest to wewnętrzny panel admina, jednak nie zmienia to faktu, że zabezpieczenie musi być. Pozostałe skrypty są zabezpieczone.

      @Jurix: w taki sposób że korzytasz z mysqli/pdo, w ORM jest o to dużo ciężej imho, co prawda też nijak by to nie zabezpieczyło ale dla dużej części nie musisz pisać samemu żadnych zapytań

    •  

      @Jurix: tj w sensie rodzielenie widoku, nigdzie pisząc w OOP nie będziesz miał echo, a jeśli masz no to tak naprawdę nie piszesz OOP tylko właśnie strukturalnie, powinieneś mieć oddzielną klasę od widoku która załadnie za pomocą include/require odpowiedni widok do któreg przekażesz wymagane parametry, czy to za pomocą extract czy przypisując te zmienne do widoku za pomocą $this->$zmienna i w widoku uzyskując dostęp do tych zmiennych, poza tym w widoku zamiast robić echo 'asdasd' możesz wtedy robić <p><?=$a; ?></p> imho jest to dużo czytelniejsze

    •  

      @veranoo: pytanie miało byc do @Jurix: a nie do Ciebie, sry ;)

      +: veranoo
    •  

      Tak, naprawdę to jeszcze nie zdajesz sobie jak masz braki, jeżeli chodzi o programowanie. Programowanie obiektowe jest po to, żeby kod był łatwiejszy w utrzymaniu i w rozumieniu go przez inną osobę. Częściej czytasz kod niż piszesz.
      Widzę u Ciebie efekt Krugera-Dunninga, jeszcze nie wiesz jakie masz braki, dopiero jak wejdziesz w to głębiej zobaczysz, ile jeszcze masz do nauki. Doświadczyłem to na sobie.

      P.S.
      Przez takie potworki jakie stworzyłeś, później mają beke z #php :D

    •  

      Wracając do tego wątku:
      @zakopiak: Dzięki za długą, rzeczową wypowiedź!
      - SQL injection - mój błąd, do poprawy.
      - Problem polega na tym, że akurat ten kod nie wiem kto będzie obrabiał, do tego wgląd do tego mieli nauczyciele, którym nie po drodze z angielskim, stąd decyzja na mieszankę. Przy standardowych projektach o tym pamiętam.
      - Kurcze, przez 3 lata uczono mnie, żeby wszystko komentować, nawet najprostsze ify, jednak ma sens to co piszesz.

      @Jurigag: @pyra991:

      Nie rozumiem 2 rzeczy:
      - W jaki sposób programowanie obiektowe pozwala uniknąć includów/require?
      - W jaki sposób mogę edytować coś we wszystkich skryptach, jeśli nie ma wspólnego pliku importowanego includem?

    •  

      - W jaki sposób programowanie obiektowe pozwala uniknąć includów/require?

      @Jurix: ponieważ autoloader to robi lub metoda klasy którą wielokrotnie wykorzytujesz(w przypadku klasy odpowiadającej za widoki)

      - W jaki sposób mogę edytować coś we wszystkich skryptach, jeśli nie ma wspólnego pliku importowanego includem?

      @Jurix: ponieważ będziesz korzystał z kontenera zależności i będziesz odwoływał się do obiektu danej klasy wszędzie która będzie tą samą instancją

      +: Jurix

Gorące dyskusje ostatnie 12h

  • odpowiedzi (24)

  • odpowiedzi (25)

  • avatar

    #steam #gry #globaleliteshop #thiswarofmine

    #rozdajo #rozdajosteam This War of Mine. Losujemy wsrod plusujacych jutro kolo 20. Nie biorą udziału ludzie od patostrimów i osoby które uznamy za toksyczne, całą resztę zapraszamy :)

    pokaż spoiler Mozecie u nas kupic KAZDA gre/dlc jakie jest dostepne na Steam. Ceny to 93% aktualnej steamowej ceny jezeli decydujecie sie na zakup na allegro, lub 80% aktualnej steamowej ceny jezeli decydujecie sie na zakup bez allegro (wtedy zapraszamy do kontaktu na PW na wykopie)


    pokaż spoiler Co oznacza aktualna steamowa cena? To cena która widnieje na stronie gry w sklepie steam w polskiej strefie cenowej. Promocje steam mozna laczycz nasza oferta. Przykladowo: gra normalnie kosztuje 100zl, ale obecnie na Steam mozna ja kupic za 50zl, bo zostala przeceniona o polowe. Wiec u nas zaplacicie wtedy 40zl (80% z przecenionej ceny).


    pokaż spoiler Wszystkie gry to legalnie gifty zakupione bezposrednio na Steam w polskiej strefie cenowej (zadnych VPN i innych kombinacji)


    pokaż spoiler Nasza oferte allegro znajdziecie na http://globaleliteshop.pl, jezeli tam nie ma tego czego szukacie to napiszcie, wystawimy lub zalatwimy sprawe poza allegro.


    pokaż spoiler I na koniec juz, prowadzimy tez skup przedmiotów z gier #csgo #dota2 #h1z1 i z kazdej innej gry której przedmioty sa dostepne na rynku steam. Jezeli macie cos na sprzedaz zapraszamy do kontaktu bezposrednio na naszym profilu steam
    pokaż całość

    odpowiedzi (12)