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.
@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: 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.
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
"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ą.
@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 #!$%@?ąć 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: 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
@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.
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
źródło: comment_N6zON8Ar1GpOUILDYx6x5eK7cunU2GFu.jpg
Pobierz@joolekk: Jasne, że nie. Ta książka jest ogólna, czy dotyczy/odnosi się do jakiegoś konkretnego języka?
Co by było gdybyś musiał przekazać swój projekt komuś?
@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.
@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
Ale twój strukturalny jest czytelniejszy dla ciebie. Nikt kto na co dzień pisze obiektowo nie zrozumie na pierwszy rzut oka tego co napiszesz.
@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ą.
masz np: komentarz w kodzie
możesz zacząć od refaktoryzacji kodu by komentarz nie był potrzebny
w OOP czysto i ładnie rozbijesz swoje ify na max kilka linii
?
znów skopiujesz ten sam kod z tym
@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.
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ś
classwpiszesz 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 jestmysqli_queryna 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
@cooltang: Naprawdę chciałbym poznać ścieżkę Twojego rozumowania, po której mogłeś pomyśleć że moje pytanie jest baitem.
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.