Jakie korzyści wnoszą klasy do php ?
Czy różnią się od funkcji?
Czy warto się nauczyć tworzenia klas ?
Pełna wersja: klasy vs funkcje
Porzadkuja kod i w sumie to mi sie najbardziej podoba.. wiem gdzie co jest. Dodatkowo dostajesz do reki kilka przydatnych rozwiazan ... jak np. dziedziczenie.
Wstep do OOP masz w artykulach na php.pl. Wiec czytaj, czytaj i czytaj...
Wstep do OOP masz w artykulach na php.pl. Wiec czytaj, czytaj i czytaj...
Dzięki klasom masz większą kontrolę nad kodem oraz możesz zmniejszyć jego objętość. Np tworzysz klasę forma a w niej tworzysz metody input, submit, text, itp. Następnie zamiast pisać <form><input></form> itd. wpiszujesz tylko obiekt form i masz zaoszczędzone wiele wierszy kodu. Ponadto klasy możesz trzymać w osobnym pliku i ładować te pliki za pomocą require_once.
w funkcjach tez wiesz gdzie co jest, no chyba ze nie umiesz pilnowac pozadku i gubisz sie w swoim kodzie:P
plik z funkcjami tez mozesz ladowac z osobnych plikow poprzez require_once:P
mozesz sobie rowniez utworzyc funkcje ktora wyswietla rozne obiekty z atrybutu:P
slabe argumenty .
plik z funkcjami tez mozesz ladowac z osobnych plikow poprzez require_once:P
mozesz sobie rowniez utworzyc funkcje ktora wyswietla rozne obiekty z atrybutu:P
slabe argumenty .
Ale w przypadku klas możesz zamknąć podobne funkcje w jednej klasie, np form lub table. Ponadto klasy oferują dziedziczenie w przeciwieństwie do zwykłych funkcji. Dzięki temu w kodzie panuje ład 
Ja mam sie gubic w swoim kodzie? To raczej inni powinni sie odnalezc w moim kodzie bo nie pracuje sam, tylko osoby z firmy tez powinny sie odnalezc w tym co ja napisze
Argumenty byly przytaczane w wielu ksiazkach, ja jestem od kodzenia. i sam probowalem pisac w php samymi funkcjami, ale jest to NIEWYGODNE. Zreszta kazdy z czasem sie sam o tym przekona. Jak nie to niech mi da znac, chetnie spojrze na jego kod i ocenie
Jak ktos chce szuka jak wyglada wiekszy kod php napisany struktrualnie to niech spojrzy na skrypt phorum. Chodz oni i tak skorzystali czesciowo z klas.. 3 byla wykorzystywala klase do bazy danych.. potem zrezygnowali z tej klasy i jest tylko mysql... a gdyby byly klasy TO LATWO mozna byloby zmienic to na inny rodzaj bazy danych np. postgres, a tak to PUPA. Yyy w 5 z tego co widzialem to wykorzystuja klasy przy tworzeniu formularzy.
Argumenty byly przytaczane w wielu ksiazkach, ja jestem od kodzenia. i sam probowalem pisac w php samymi funkcjami, ale jest to NIEWYGODNE. Zreszta kazdy z czasem sie sam o tym przekona. Jak nie to niech mi da znac, chetnie spojrze na jego kod i ocenie
Jak ktos chce szuka jak wyglada wiekszy kod php napisany struktrualnie to niech spojrzy na skrypt phorum. Chodz oni i tak skorzystali czesciowo z klas.. 3 byla wykorzystywala klase do bazy danych.. potem zrezygnowali z tej klasy i jest tylko mysql... a gdyby byly klasy TO LATWO mozna byloby zmienic to na inny rodzaj bazy danych np. postgres, a tak to PUPA. Yyy w 5 z tego co widzialem to wykorzystuja klasy przy tworzeniu formularzy.
Przykład aplikacji napisanej za pomocą klas:
Pierwszy plik to config o zawartośi:
W pliku tym można zamieścić wiele potrzebnych stałych, jak np miesiące do list rozwijanych, itp.
Następny plik to klasa_db:
Plik index.php
Wszystko jak na dłoni. Prosto i przejrzyście. W razie potrzeby tworzy się więcej klas. Zamiast dołączać klasy w konkretnym pliku można dołączyć go w configu i już. Nie trzeba pisać x funkcji bo wszystko zamknięte jest w klasie.
Pierwszy plik to config o zawartośi:
W pliku tym można zamieścić wiele potrzebnych stałych, jak np miesiące do list rozwijanych, itp.
Następny plik to klasa_db:
Plik index.php
Wszystko jak na dłoni. Prosto i przejrzyście. W razie potrzeby tworzy się więcej klas. Zamiast dołączać klasy w konkretnym pliku można dołączyć go w configu i już. Nie trzeba pisać x funkcji bo wszystko zamknięte jest w klasie.
W ostatniej wypowiedzi mnie oświeciło jak Klasy są przydatne. Zaczynam się tego uczyć :]
Widzę, że dużo osób jest na "+", a jako, że zawsze jestem za słabszą drużyną , to nie będę zachwalał programowania obiektowego, a poszukam jego "-".
Dziś po południu rzucę na to trochę więcej światła, przedstawiając wam pewien wywiad w którego posiadaniu jestem
Wywiad był przeprowadzany z samym twórcą języka obiektowego, jakim jest C++ chociaż nie tak do końca obiektowego.
Mimo, że nie mogę do końca uwierzyć w to co tam przeczytałem, to muszę przyznać, że gość mówi nie od rzeczy. Niedługo go wkleję.
, to nie będę zachwalał programowania obiektowego, a poszukam jego "-".Dziś po południu rzucę na to trochę więcej światła, przedstawiając wam pewien wywiad w którego posiadaniu jestem
Wywiad był przeprowadzany z samym twórcą języka obiektowego, jakim jest C++ chociaż nie tak do końca obiektowego. Mimo, że nie mogę do końca uwierzyć w to co tam przeczytałem, to muszę przyznać, że gość mówi nie od rzeczy. Niedługo go wkleję.
Cytat
1 stycznia 1998 roku Bjarne Stroustrup udzielił wywiadu dla jednego z czasopism komputerowych - "IEEE Computer". Wydawcy myśleli, że będzie to nawiązanie do minionych siedmiu lat programowania obiektowego za pomocą języka, który sam stworzył. W trakcie wywiadu, prowadzący go redaktor został dość niemile zaskoczony przez swojego rozmówcę, co było powodem późniejszej chęci zatajenia treści wywiadu przez wydawców, tłumaczonej "dbaniem o dobro przemysłu komputerowego". Jednak jak to zwykle bywa w takich przypadkach, również i tutaj wystąpił tzw. przeciek informacji. Oto kompletny odpis tego co zostało powiedziane, bez jakichkolwiek obróbek merytorycznych. Dlatego też nie wygląda to tak, jak w przypadku innych, wcześniej uzgadnianych wywiadów. Jednak myślę, że spotka się to z zainteresowaniem...
Redaktor: Minęło już parę lat odkąd zrewolucjonizowałeś świat programowania. Co o tym myślisz, patrząc wstecz na swoje dokonania?
Stroustrup: Właściwie myślałem o tym tuż przed twoim przyjściem. Pamiętasz?... Wszyscy pisali w C, a problemem było to, że byli w tym cholernie dobrzy. Również uniwersytety były dobre w nauczaniu tego języka. W bardzo szybkim tempie wypuszczali na świat wykwalifikowanych (podkreślam słowo: wykwalifikowanych) absolwentów. To właśnie spowodowało problem.
Redaktor: Problem?
Stroustrup: Tak, problem. Pamiętasz jak dawniej wszyscy pisali w Cobol-u?
Redaktor: Oczywiście, ja też w tym pisałem...
Stroustrup: Więc na początku ci ludzie byli jak półbogowie. Mieli wysokie pensje, i traktowani byli niemalże jak członkowie rodziny królewskiej.
Redaktor: To były czasy..., prawda?
Stroustrup: Właśnie! I co się stało? Firma IBM miała tego dosyć, więc zainwestowała miliony dolarów na wytrenowanie tylu programistów, aż było ich dosłownie na pęczki.
Redaktor: Z tego właśnie powodu ja też odszedłem. Pensje spadły w przeciągu roku na tyle, że bardziej opłacało się pisanie artykułów do magazynów.
Stroustrup: Dokładnie. To samo stało się z programistami piszącymi w C.
Redaktor: No tak. Ale do czego zmierzasz?
Stroustrup: Otóż pewnego dnia, kiedy siedziałem w swoim biurze, myślałem nad czymś co wprowadziłoby trochę równowagi do ówczesnej sytuacji. Zastanawiałem się co by było, gdyby istniał język na tyle skomplikowany i trudny do nauczenia, że nikt nie byłby w stanie zalewać rynku programistami. Miałem parę pomysłów z X10, no wiesz, X windows. To dopiero było okropne środowisko graficzne... chodziło tylko na maszynach typu Sun 3/60. Ale miało wszystkie składniki jakich potrzebowałem: naprawdę śmiesznie skomplikowaną składnię, mętne i niejasne funkcje oraz pseudo obiektową strukturę. Nawet w dzisiejszych czasach, nikt kto chce pozostać przy zdrowych zmysłach, nie pisze w czystym kodzie X-windows.
Redaktor: Chyba żartujesz...?
Stroustrup: Ani trochę. Był też kolejny problem. Unix został napisany w C, a to znaczyło że każdy programista piszący w tym języku, mógł bardzo łatwo przejść na pisanie systemów operacyjnych. Pamiętasz chyba ile wtedy programista takich głównych systemów zarabiał ?
Redaktor: Jasne że tak, sam też się tym zajmowałem....
Stroustrup: Zatem ten nowy język musiał oddzielić się od Unix-a, ukrywając wszystkie wywołania systemowe. To umożliwiłoby zarobienie paru groszy również tym, którzy znali tylko DOS-a.
Redaktor: Nie wierzę, że to powiedziałeś...
Stroustrup: No cóż, minęło już trochę czasu i moim zdaniem większość ludzi odkryła, że całe C++ to tylko strata czasu, choć muszę powiedzieć, że zajęło im to o wiele dłużej niż przypuszczałem.
Redaktor: Zatem, jak udało ci się osiągnąć taki sukces ?
Stroustrup: To miał być tylko żart. Nigdy nie sądziłem, że ludzie mogliby brać moją książkę na poważnie. Każdy, nawet półgłówek dostrzeże, że programowanie zorientowane obiektowo jest nielogiczne, niewydajne i działa wbrew intuicji.
Redaktor: Co?
Stroustrup: A co do wielokrotnego wykorzystywania kodu... - kiedy słyszałeś, żeby jakaś firma działała w ten sposób ?
Redaktor: No..., właściwie to nigdy, ale...
Stroustrup: No właśnie! To znaczy, kilka próbowało w tamtych czasach. Była taka firma z Oregonu - Mentor Graphics, która w '90 albo '91-szym roku próbowała przepisać wszystko na C++ i niestety nie wyszło im to na dobre. Było mi ich naprawdę żal ale uważam, że ludzie powinni uczyć się na własnych błędach.
Redaktor: Dokładnie. A im się to nie udało ?
Stroustrup: Niestety ani trochę. Problem w tym, że większość firm ma tendencję do tuszowania swoich poważniejszych zaniedbań, a wytłumaczenie się akcjonariuszom ze straty 30 milionów dolarów, byłoby dość trudne. Sprawiedliwości stało się zadość, jednak w końcu udało im się jakoś wyjść na prostą.
Redaktor: Naprawdę? No więc sam widzisz, że programowanie obiektowe skutkuje.
Stroustrup: Prawie. Pliki .EXE były tak duże, że ich załadowanie na maszynie HP ze 128MB RAM-u, trwało pięć minut. Programy uruchamiały się w ślimaczym tempie. Właściwie myślałem, że będzie to główną wadą nowego języka, jednak nikogo to nie obchodziło. Firmy takie jak Sun czy HP były zbyt zadowolone ze sprzedaży swoich mocnych komputerów z ogromnymi zasobami, a wszystko po to tylko, żeby uruchamiać na nich proste, banalne programy. Wyobraź sobie, że kiedy pojawił się pierwszy kompilator C++ na komputerze AT&T, skompilowałem pod nim zwykłe "Hello World" i wprost nie mogłem uwierzyć rozmiarowi tego pliku - 2.1 MB.
Redaktor: Co? Zgoda, ale kompilatory bardzo się od tamtego czasu zmieniły.
Stroustrup: Czyżby? Weźmy na przykład ostatnią wersję g++ - nie uzyskasz większej redukcji objętości jak zaledwie o niecałe 0.5 MB. Mógłbym przytoczyć ci jeszcze kilka innych przykładów z całego świata. Swego czasu firma British Telecom miała z tego powodu nie lada katastrofę, ale na szczęście udało im się w porę usunąć problemy i zacząć od nowa. Australian Telecom nie miała tyle szczęścia, co ich brytyjski odpowiednik. Teraz dochodzą mnie słuchy, że Siemens buduje kolejnego "dinozaura" martwiąc się coraz bardziej o to, aby sprzęt równoważył wymagania programów. Czy zatem wielopoziomowe dziedziczenie nie jest po prostu pomyłką ?
Redaktor: Przecież C++ jest bezpiecznym językiem.
Stroustrup: Naprawdę w to wierzysz ? Czy kiedykolwiek pracowałeś nad projektem w C++? Oto co się dzieje: po pierwsze, w C++ istnieje wystarczająco dużo pułapek, dzięki którym tylko najbanalniejsze projekty działają za pierwszym razem. Weź np. przeładowanie jakiegoś operatora. Pod koniec projektu, prawie każdy moduł je posiada, bo w mniemaniu programistów powinno ono wystąpić, przecież o tym mówiono im na kursac szkoleniowych. Zatem ten sam operator w każdym kolejnym module oznacza coś zupełnie innego. A spróbuj nad tym zapanować, kiedy będziesz miał około setki modułów... A co do ukrywania danych: O Boże, czasami nie sposób się nie roześmiać, kiedy słyszę o firmach starających się sprawić aby ich moduły ze sobą współpracowały. Myślę, że słowo "synergetyczny" zostało specjalnie wymyślone, aby można było szefowi projektu "przekręcać nóż w żebrach".
Redaktor: Muszę przyznać, że zaczynam być tym wszystkim przerażony.Mówisz, że stworzyłeś ten język po to, aby wzrosły pensje programistów? To okropne!
Stroustrup: Nie zupełnie. Przecież każdy ma wybór. Nie przypuszczałem, że aż tak bardzo wymknie się to spod kontroli, jednak stało się. C++ już stopniowo wymiera, ale programiści dalej są dobrze opłacani - szczególnie ci, którzy zajmują się tworzeniem projektów za pomocą tego steku bzdur. Zdajesz sobie sprawę, że pracowanie nad dużym modułem programu w C++ nie jest możliwe, jeśli sam go nie napisałeś ?
Redaktor: Jak to ?
Stroustrup: Nie kojarzysz o czym mówię, prawda? A pamiętasz dyrektywę: typedef?
Redaktor: Oczywiście że tak.
Stroustrup: Przypomnij sobie ile czasu zabiera śledzenie "po omacku" plików nagłówkowych tylko po to, aby dowiedzieć się że np. 'RoofRaised' to liczba typu double. Wyobraź sobie ile czasu zabiera znalezienie wszystkich konkretnych dyrektyw typedef we wszystkich klasach jakiegoś większego projektu.
Redaktor: Po czym zatem poznałeś swój sukces ?
Stroustrup: Pamiętasz ile zajmowało stworzenie średniej objętości projektu w C ? Około 6 miesięcy. To trochę za krótko, aby facet mający żonę i dzieci mógł zarobić na utrzymanie i w miarę godziwy standard życia. A weź teraz napisz ten sam projekt używając C++...i co otrzymasz? Powiem ci - jeden do dwóch lat. Czyż to nie wspaniałe zapewnienie sobie pracy? Kolejna rzecz. Uniwersytety nie nauczały C od tak dawna, że teraz brakuje porządnych programistów piszących w tym języku. Szczególnie tych, którzy wiedzą coś na temat programowania pod systemami z rodziny Unix-a. Ilu teraz wiedziałoby co zrobić z 'malloc', skoro przez tyle lat używali 'new' - i nigdy nie zaprzątali sobie głowy sprawdzaniem wartości zwracanego kodu. W rzeczywistości, większość z programistów C++ pomija te zwracane wartości. Co się stało ze starym, dobrym '-1' ? Przynajmniej wiedziałeś, że masz błąd, bez grzęźnięcia w cały ten bałagan z 'try', 'throw' i 'catch'.
Redaktor: Ale przecież dziedziczenie oszczędza mnóstwo czasu i pracy...
Stroustrup: Tak sądzisz? Czy kiedykolwiek zauważyłeś różnicę między planowaniem projektu w C, a planowaniem projektu w C++? To drugie jest trzy razy dłuższe. Musisz dokładnie upewnić się, że wszystko co powinno być dziedziczone, jest dziedziczone, a wszystko co nie powinno - nie jest. A potem i tak występują w tym błędy. Kto przedtem słyszał o jakiejś konsumpcji pamięci przez program napisany w zwykłym C? A teraz znajdywanie ich, to chleb powszedni. Większość firm pod tym względem poddaje się, wypuszczają na rynek swój produkt, wiedząc że cieknie z niego jak z dziurawego worka, no ale wtedy unikają kosztów związanych z łataniem tych dziur.
Redaktor: Są do tego odpowiednie narzędzia...
Stroustrup: ...z których większość została napisana w C++.
Redaktor: Czy zdajesz sobie sprawę z tego, że jeśli opublikujemy ten wywiad, to prawdopodobnie zostaniesz "zlinczowany" ?
Stroustrup: Wątpię. Jak już powiedziałem, C++ minął już swój szczyt rozkwitu i popularności i żadna firma przy zdrowych zmysłach nie zacznie tworzenia projektu w C++ bez wstępnych prób. One powinny ich przekonać, że zmierzają prosto ku katastrofie. A jeśli tego nie zauważą, to niech mają na co zasłużyli. Wiesz, próbowałem kiedyś przekonać Dennis'a Ritchie, aby przepisał Unix-a w C++.
Redaktor: O mój Boże..., i co powiedział?
Stroustrup: Na szczęście ma poczucie humoru
Redaktor: Minęło już parę lat odkąd zrewolucjonizowałeś świat programowania. Co o tym myślisz, patrząc wstecz na swoje dokonania?
Stroustrup: Właściwie myślałem o tym tuż przed twoim przyjściem. Pamiętasz?... Wszyscy pisali w C, a problemem było to, że byli w tym cholernie dobrzy. Również uniwersytety były dobre w nauczaniu tego języka. W bardzo szybkim tempie wypuszczali na świat wykwalifikowanych (podkreślam słowo: wykwalifikowanych) absolwentów. To właśnie spowodowało problem.
Redaktor: Problem?
Stroustrup: Tak, problem. Pamiętasz jak dawniej wszyscy pisali w Cobol-u?
Redaktor: Oczywiście, ja też w tym pisałem...
Stroustrup: Więc na początku ci ludzie byli jak półbogowie. Mieli wysokie pensje, i traktowani byli niemalże jak członkowie rodziny królewskiej.
Redaktor: To były czasy..., prawda?
Stroustrup: Właśnie! I co się stało? Firma IBM miała tego dosyć, więc zainwestowała miliony dolarów na wytrenowanie tylu programistów, aż było ich dosłownie na pęczki.
Redaktor: Z tego właśnie powodu ja też odszedłem. Pensje spadły w przeciągu roku na tyle, że bardziej opłacało się pisanie artykułów do magazynów.
Stroustrup: Dokładnie. To samo stało się z programistami piszącymi w C.
Redaktor: No tak. Ale do czego zmierzasz?
Stroustrup: Otóż pewnego dnia, kiedy siedziałem w swoim biurze, myślałem nad czymś co wprowadziłoby trochę równowagi do ówczesnej sytuacji. Zastanawiałem się co by było, gdyby istniał język na tyle skomplikowany i trudny do nauczenia, że nikt nie byłby w stanie zalewać rynku programistami. Miałem parę pomysłów z X10, no wiesz, X windows. To dopiero było okropne środowisko graficzne... chodziło tylko na maszynach typu Sun 3/60. Ale miało wszystkie składniki jakich potrzebowałem: naprawdę śmiesznie skomplikowaną składnię, mętne i niejasne funkcje oraz pseudo obiektową strukturę. Nawet w dzisiejszych czasach, nikt kto chce pozostać przy zdrowych zmysłach, nie pisze w czystym kodzie X-windows.
Redaktor: Chyba żartujesz...?
Stroustrup: Ani trochę. Był też kolejny problem. Unix został napisany w C, a to znaczyło że każdy programista piszący w tym języku, mógł bardzo łatwo przejść na pisanie systemów operacyjnych. Pamiętasz chyba ile wtedy programista takich głównych systemów zarabiał ?
Redaktor: Jasne że tak, sam też się tym zajmowałem....
Stroustrup: Zatem ten nowy język musiał oddzielić się od Unix-a, ukrywając wszystkie wywołania systemowe. To umożliwiłoby zarobienie paru groszy również tym, którzy znali tylko DOS-a.
Redaktor: Nie wierzę, że to powiedziałeś...
Stroustrup: No cóż, minęło już trochę czasu i moim zdaniem większość ludzi odkryła, że całe C++ to tylko strata czasu, choć muszę powiedzieć, że zajęło im to o wiele dłużej niż przypuszczałem.
Redaktor: Zatem, jak udało ci się osiągnąć taki sukces ?
Stroustrup: To miał być tylko żart. Nigdy nie sądziłem, że ludzie mogliby brać moją książkę na poważnie. Każdy, nawet półgłówek dostrzeże, że programowanie zorientowane obiektowo jest nielogiczne, niewydajne i działa wbrew intuicji.
Redaktor: Co?
Stroustrup: A co do wielokrotnego wykorzystywania kodu... - kiedy słyszałeś, żeby jakaś firma działała w ten sposób ?
Redaktor: No..., właściwie to nigdy, ale...
Stroustrup: No właśnie! To znaczy, kilka próbowało w tamtych czasach. Była taka firma z Oregonu - Mentor Graphics, która w '90 albo '91-szym roku próbowała przepisać wszystko na C++ i niestety nie wyszło im to na dobre. Było mi ich naprawdę żal ale uważam, że ludzie powinni uczyć się na własnych błędach.
Redaktor: Dokładnie. A im się to nie udało ?
Stroustrup: Niestety ani trochę. Problem w tym, że większość firm ma tendencję do tuszowania swoich poważniejszych zaniedbań, a wytłumaczenie się akcjonariuszom ze straty 30 milionów dolarów, byłoby dość trudne. Sprawiedliwości stało się zadość, jednak w końcu udało im się jakoś wyjść na prostą.
Redaktor: Naprawdę? No więc sam widzisz, że programowanie obiektowe skutkuje.
Stroustrup: Prawie. Pliki .EXE były tak duże, że ich załadowanie na maszynie HP ze 128MB RAM-u, trwało pięć minut. Programy uruchamiały się w ślimaczym tempie. Właściwie myślałem, że będzie to główną wadą nowego języka, jednak nikogo to nie obchodziło. Firmy takie jak Sun czy HP były zbyt zadowolone ze sprzedaży swoich mocnych komputerów z ogromnymi zasobami, a wszystko po to tylko, żeby uruchamiać na nich proste, banalne programy. Wyobraź sobie, że kiedy pojawił się pierwszy kompilator C++ na komputerze AT&T, skompilowałem pod nim zwykłe "Hello World" i wprost nie mogłem uwierzyć rozmiarowi tego pliku - 2.1 MB.
Redaktor: Co? Zgoda, ale kompilatory bardzo się od tamtego czasu zmieniły.
Stroustrup: Czyżby? Weźmy na przykład ostatnią wersję g++ - nie uzyskasz większej redukcji objętości jak zaledwie o niecałe 0.5 MB. Mógłbym przytoczyć ci jeszcze kilka innych przykładów z całego świata. Swego czasu firma British Telecom miała z tego powodu nie lada katastrofę, ale na szczęście udało im się w porę usunąć problemy i zacząć od nowa. Australian Telecom nie miała tyle szczęścia, co ich brytyjski odpowiednik. Teraz dochodzą mnie słuchy, że Siemens buduje kolejnego "dinozaura" martwiąc się coraz bardziej o to, aby sprzęt równoważył wymagania programów. Czy zatem wielopoziomowe dziedziczenie nie jest po prostu pomyłką ?
Redaktor: Przecież C++ jest bezpiecznym językiem.
Stroustrup: Naprawdę w to wierzysz ? Czy kiedykolwiek pracowałeś nad projektem w C++? Oto co się dzieje: po pierwsze, w C++ istnieje wystarczająco dużo pułapek, dzięki którym tylko najbanalniejsze projekty działają za pierwszym razem. Weź np. przeładowanie jakiegoś operatora. Pod koniec projektu, prawie każdy moduł je posiada, bo w mniemaniu programistów powinno ono wystąpić, przecież o tym mówiono im na kursac szkoleniowych. Zatem ten sam operator w każdym kolejnym module oznacza coś zupełnie innego. A spróbuj nad tym zapanować, kiedy będziesz miał około setki modułów... A co do ukrywania danych: O Boże, czasami nie sposób się nie roześmiać, kiedy słyszę o firmach starających się sprawić aby ich moduły ze sobą współpracowały. Myślę, że słowo "synergetyczny" zostało specjalnie wymyślone, aby można było szefowi projektu "przekręcać nóż w żebrach".
Redaktor: Muszę przyznać, że zaczynam być tym wszystkim przerażony.Mówisz, że stworzyłeś ten język po to, aby wzrosły pensje programistów? To okropne!
Stroustrup: Nie zupełnie. Przecież każdy ma wybór. Nie przypuszczałem, że aż tak bardzo wymknie się to spod kontroli, jednak stało się. C++ już stopniowo wymiera, ale programiści dalej są dobrze opłacani - szczególnie ci, którzy zajmują się tworzeniem projektów za pomocą tego steku bzdur. Zdajesz sobie sprawę, że pracowanie nad dużym modułem programu w C++ nie jest możliwe, jeśli sam go nie napisałeś ?
Redaktor: Jak to ?
Stroustrup: Nie kojarzysz o czym mówię, prawda? A pamiętasz dyrektywę: typedef?
Redaktor: Oczywiście że tak.
Stroustrup: Przypomnij sobie ile czasu zabiera śledzenie "po omacku" plików nagłówkowych tylko po to, aby dowiedzieć się że np. 'RoofRaised' to liczba typu double. Wyobraź sobie ile czasu zabiera znalezienie wszystkich konkretnych dyrektyw typedef we wszystkich klasach jakiegoś większego projektu.
Redaktor: Po czym zatem poznałeś swój sukces ?
Stroustrup: Pamiętasz ile zajmowało stworzenie średniej objętości projektu w C ? Około 6 miesięcy. To trochę za krótko, aby facet mający żonę i dzieci mógł zarobić na utrzymanie i w miarę godziwy standard życia. A weź teraz napisz ten sam projekt używając C++...i co otrzymasz? Powiem ci - jeden do dwóch lat. Czyż to nie wspaniałe zapewnienie sobie pracy? Kolejna rzecz. Uniwersytety nie nauczały C od tak dawna, że teraz brakuje porządnych programistów piszących w tym języku. Szczególnie tych, którzy wiedzą coś na temat programowania pod systemami z rodziny Unix-a. Ilu teraz wiedziałoby co zrobić z 'malloc', skoro przez tyle lat używali 'new' - i nigdy nie zaprzątali sobie głowy sprawdzaniem wartości zwracanego kodu. W rzeczywistości, większość z programistów C++ pomija te zwracane wartości. Co się stało ze starym, dobrym '-1' ? Przynajmniej wiedziałeś, że masz błąd, bez grzęźnięcia w cały ten bałagan z 'try', 'throw' i 'catch'.
Redaktor: Ale przecież dziedziczenie oszczędza mnóstwo czasu i pracy...
Stroustrup: Tak sądzisz? Czy kiedykolwiek zauważyłeś różnicę między planowaniem projektu w C, a planowaniem projektu w C++? To drugie jest trzy razy dłuższe. Musisz dokładnie upewnić się, że wszystko co powinno być dziedziczone, jest dziedziczone, a wszystko co nie powinno - nie jest. A potem i tak występują w tym błędy. Kto przedtem słyszał o jakiejś konsumpcji pamięci przez program napisany w zwykłym C? A teraz znajdywanie ich, to chleb powszedni. Większość firm pod tym względem poddaje się, wypuszczają na rynek swój produkt, wiedząc że cieknie z niego jak z dziurawego worka, no ale wtedy unikają kosztów związanych z łataniem tych dziur.
Redaktor: Są do tego odpowiednie narzędzia...
Stroustrup: ...z których większość została napisana w C++.
Redaktor: Czy zdajesz sobie sprawę z tego, że jeśli opublikujemy ten wywiad, to prawdopodobnie zostaniesz "zlinczowany" ?
Stroustrup: Wątpię. Jak już powiedziałem, C++ minął już swój szczyt rozkwitu i popularności i żadna firma przy zdrowych zmysłach nie zacznie tworzenia projektu w C++ bez wstępnych prób. One powinny ich przekonać, że zmierzają prosto ku katastrofie. A jeśli tego nie zauważą, to niech mają na co zasłużyli. Wiesz, próbowałem kiedyś przekonać Dennis'a Ritchie, aby przepisał Unix-a w C++.
Redaktor: O mój Boże..., i co powiedział?
Stroustrup: Na szczęście ma poczucie humoru
Cytat(batman @ 2005-08-28 12:04:02)
Ale w przypadku klas możesz zamknąć podobne funkcje w jednej klasie, np form lub table.
a funkcje moze zamknac w jednym pliku np. form.php lub table.php
wlasnie mi sie przypomniala wypowiedz @hwao w jakims poprzednim topiku (nie pamietam ktorym) ze programowanie obiektowe to nie zmaina w sposobie pisania skryptu tylko ze zmiana w sposobie myslenia (tak mi sie wydaje ze to on powiedzial i mniej wiecej o to chodzilo
)
@markac faktycznie troche szokujący artykuł Ale mimo wszystko większość aplikacji (w tym chyba nawet Windows) jest pisana w języku C++ i odnosi sukcesy na rynku, więc OOP rządzi Mi osobiście, wraz z poznawaniem możliwości programowania obiektowego, coraz bardziej się ono podoba Zalety już wymienili moi poprzednicy: przejrzystość i mniejsza objętość kodu, możliwość wielokrotnego wykorzystania itp. Ja jednak póki co piszę skrypty metodą strukturalną, bo o programowaniu obiektowym dowiedziałem się niedawno. ale jak lepiej poznam i opanuję możliwości OOP na pewno zacznę pisać skrypty metodą obiektową.
Ale mimo wszystko większość aplikacji (w tym chyba nawet Windows) jest pisana w języku C++ i odnosi sukcesy na rynku, więc OOP rządzi Mi osobiście, wraz z poznawaniem możliwości programowania obiektowego, coraz bardziej się ono podoba Zalety już wymienili moi poprzednicy: przejrzystość i mniejsza objętość kodu, możliwość wielokrotnego wykorzystania itp. Ja jednak póki co piszę skrypty metodą strukturalną, bo o programowaniu obiektowym dowiedziałem się niedawno. ale jak lepiej poznam i opanuję możliwości OOP na pewno zacznę pisać skrypty metodą obiektową.
ty piszesz ze ma takie zalety a autor c++ napisal ze sa to wady:P ze wcale nie jest szybszy, ze wcale nie jest mniej kodu i wcale ne jest czytelniejszy, nie wiem czemu dla ciebie to jest lepsze...
ja w swoich projektach nie wymyslam roznych silnikow enginow czy jak to zwal inaczej, klas uzywam jaka dodatek do mojeo projektu, np stronicowanie, statystyki, obsluga bazy danych, ale po co pisac klase strony?
no chyba ze jeszcze az tak rozbudowanego projektu nie robilem zeby zauwazyc wieksze korzysci:)
ja w swoich projektach nie wymyslam roznych silnikow enginow czy jak to zwal inaczej, klas uzywam jaka dodatek do mojeo projektu, np stronicowanie, statystyki, obsluga bazy danych, ale po co pisac klase strony?
no chyba ze jeszcze az tak rozbudowanego projektu nie robilem zeby zauwazyc wieksze korzysci:)
Moim zdaniem przejrzystość kodu to zaleta, a że autor ma inne zdanie, no to już jego własna opinia. Ja wole mieć porządek w kodzie, łatwiej go wtedy modyfikować, łatwiej znaleźć błędy gdy coś nie działa. A poza tym kto tu mówi, żeby całą stronę wpychać do jednej klasy? Ja na razie nie dodaje klas do swoich projektów, bo jeszcze nie zdążyłem żadnej napisać Planuję zrobić własny mechanizm obsługi sesji i sterownik bazy danych, ale to przecież też tylko dodatki, a nie cała strona. Ale ma to swoje zalety, bo jeden projekt np. mechanizmu sesji, będe mógł wykorzystać we wszystkich moich stronach wpisując tylko require_once ('i_nazwa_klasy'), a nie przepisując te same kody do każdego skryptu/strony oddzielnie.
Planuję zrobić własny mechanizm obsługi sesji i sterownik bazy danych, ale to przecież też tylko dodatki, a nie cała strona. Ale ma to swoje zalety, bo jeden projekt np. mechanizmu sesji, będe mógł wykorzystać we wszystkich moich stronach wpisując tylko require_once ('i_nazwa_klasy'), a nie przepisując te same kody do każdego skryptu/strony oddzielnie.
Ten wywiad to bzdura wymyslona przez nie wiem kogo, ale swego czasu wywolal on niezla burze.. jednak nawet na stronie autora w FAQ jest pytanie czy taki wywiad mial miejsce i udziela on na nie odpowiedzi negatywnej.
Pozatym ów hipotetyczny wywiad odbył sie w 1998, wtedy byly "troche" inne realia. Jak widac czas zweryfikowal to i tamto.
Pozatym ów hipotetyczny wywiad odbył sie w 1998, wtedy byly "troche" inne realia. Jak widac czas zweryfikowal to i tamto.
Cytat
a funkcje moze zamknac w jednym pliku np. form.php lub table.php
Z tym że nie możesz nazwać dwóch funkcji tak samo ;P. A poza tym dzięki obiektowi widzisz dokładnie co dana metoda robi. Owszem można nazwać funkcję bazadanych_select, ale od razu widać niewygodę
.A co do projektów pisanych w OOP to rację mają ci, którzy twierdzą, że nie potrzeba wszedzie klas wpychać. Jednak projekty, nad którymi pracuję są tak ogromne, że pisanie wszystkiego strukturalnie zajęło by mi całe wieki. A tak mam wszystko pod ręką i czysto w pliku z wyświetlaną stroną.
tak ten wywiad raczej nie mial miejsca przynajmniej nie byl az tak negatywny. Jakby byla to prawda w 100% to napewno juz dawno przestanoby tworzyc jezyki obiektowe i zaczeto ulepszac programowanie strukturalne.
Z tym że nie możesz nazwać dwóch funkcji tak samo ;P. A poza tym dzięki obiektowi widzisz dokładnie co dana metoda robi. Owszem można nazwać funkcję bazadanych_select, ale od razu widać niewygodę winksmiley.jpg.
masz racje nie mozna ale ja tego nie pisalem jako przeciwnik programowania obiektowego bo tak nie jest. to byla odpowiedz tylko na twoj arguyment ze wszystko mozna zebrac w jednym miejscu
racja jest tez ze trzeba wiedziec kiedy i gdzie klasy stosowac bo wpychac je gdzie sie tylko da albo w klasie zamykac tylko jedna funkcje jest glupota. do wszystkiego trzeba podchodzic z rozsadkiem.
o i to jest ten przypadek kiedy powinno sie stosowac klasy. nacisk na slowo ogromne
Czy to prawda ze napoczatku tyle zajmowalo. jak ja uzywalem kompilatora g++ to az tak wielkie plik mi nie wychodzily dla wiekszych programow
Cytat
Cytat
QUOTE
a funkcje moze zamknac w jednym pliku np. form.php lub table.php
a funkcje moze zamknac w jednym pliku np. form.php lub table.php
Z tym że nie możesz nazwać dwóch funkcji tak samo ;P. A poza tym dzięki obiektowi widzisz dokładnie co dana metoda robi. Owszem można nazwać funkcję bazadanych_select, ale od razu widać niewygodę winksmiley.jpg.
masz racje nie mozna
ale ja tego nie pisalem jako przeciwnik programowania obiektowego bo tak nie jest. to byla odpowiedz tylko na twoj arguyment ze wszystko mozna zebrac w jednym miejscu racja jest tez ze trzeba wiedziec kiedy i gdzie klasy stosowac bo wpychac je gdzie sie tylko da albo w klasie zamykac tylko jedna funkcje jest glupota. do wszystkiego trzeba podchodzic z rozsadkiem.
Cytat
Jednak projekty, nad którymi pracuję są tak ogromne, że pisanie wszystkiego strukturalnie zajęło by mi całe wieki.
o i to jest ten przypadek kiedy powinno sie stosowac klasy. nacisk na slowo ogromne
Cytat
Wyobraź sobie, że kiedy pojawił się pierwszy kompilator C++ na komputerze AT&T, skompilowałem pod nim zwykłe "Hello World" i wprost nie mogłem uwierzyć rozmiarowi tego pliku - 2.1 MB
Czy to prawda ze napoczatku tyle zajmowalo. jak ja uzywalem kompilatora g++ to az tak wielkie plik mi nie wychodzily dla wiekszych programow
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.