Witam mam taki mały dylemat ponieważ do tej pory nie pisałem obiektowo i nie widzę jakoś zastosowań obiektowego.
Może mi ktoś opisać jakie klasy warto stworzyć budując cmsa bo mi jakoś wszystko pasuje strukturalnie...

Myślałem żeby zrobić księgę gości obiektowo aby zapoznać się z obiektowym ale jakoś nie widzę zastosowania w księdze dla oop co w takiej księdze można by zrobić obiektowego?
Czy opłaca się pisać klasę filtracji danych? Bo w wielu przypadkach wymagamy zupełnie innej filtracji...

1. http://pl.wikipedia.org/wiki/Filtracja
2. Na pewno poczytałeś odpowiednią ilość materiałów? Bo mnie się coś wydaje, że Ty w ogóle nie rozumiesz za bardzo co to jest programowanie obiektowe.

Programowanie obiektowe to pewien sposób myślenia o programie który piszesz. Możesz napisać wszystko "ciurkiem" i też będzie dobrze. Problem pojawia się w sytuacji, gdy musisz modyfikować kod - po prostu obiektowy jest bardziej elastyczny (ale można też skopać ). To tylko niewielki aspekt, ale zawsze. Uważam, że powinieneś zobaczyć jak wykorzystywany jest ten paradygmat we frameworkach i przeczytać jakąś książkę (kursy w internecie są zbyt ubogie). To jest sporo wiedzy i ucząc się na wyrywki masz nikłe szanse na załapanie o co chodzi tak naprawdę
Księga gości to trochę za mały program, lepiej napisz nieśmiertelnego bloga, bo tam już można zobaczyć jak obiekty ze sobą współpracują. Zresztą - bez gruntownej wiedzy o OOP nie masz wielkich szans pracę w małej nawet firmie.

Zobacz tu: http://www.symfony-project.org/gentle-intr...1_4/en/10-Forms
Przyjrzyj się listingom tam umieszczonym, a zwłaszcza jaki poziom abstrakcji prezentują.

Pozdrawiam

pedro84 nie pytam się jak pisać obiektowo bo już te definicje znam klasy, klasy abstrakcyjne, interfejsy itd. ale chodzi o praktyczne zastosowanie tego bo teoria a praktyka to dwie różne rzeczy a mając przykłady odnoszące się do rzeczywistych zagadnień o wiele upraszczają naukę...

JA uważam, że programowanie obiektowe to tylko inny sposób myślenia i inne spojrzenie na programowanie. Nie ma podziału na aplikacje, które tworzy się proceduralnie, a te które obiektowo. Aplikacja będzie działać tak samo (powinna, ale tak nie jest ze względu na to, że żaden profesjonalista nie będzie pisał wielkiej aplikacji bez frameworka, a przynajmniej OOP), jednak zmienia się sposób programowania - masz wszystko jasno opisane, podzielone na moduły, klasy, z których korzystasz kiedy jest potrzeba. W programowaniu proceduralnym, jak już pewnie wiesz, wszystko jest pisane z palca w momencie gdy jest potrzebne i kopiowane w każdym momencie, gdy zachodzi kolejna potrzeba użycia tego (przeciwko temu powstała zasada DRY).

Przykładowo proceduralnie aby filtrować dane piszesz przy dodawaniu loginu, treści, itp kawałek kodu (może nawet nie kawałek) aby filtrować każdy element z formularza. W programowaniu obiektowym metodą filtrującą tworzysz powiedzmy raz a jako argument podajesz dany input, który zostaje przefiltrowany. Funkcja napisana raz, wykorzystana N razy (zachowana zasada DRY).

To bardzo prosty przykład, ale jakoś za ciepło jest żeby wymyślać coś bardziej inteligentnego. Polecam Ci przeczytać książki o programowaniu obiektowym (nie takie które objaśniają co to klasa abstrakcyjna, bo nie wiele Ci to da) i ich praktycznym zastosowaniu (chociażby książka o tworzeniu sklepu internetowego, coś bardziej praktycznego w każdym razie), a na pewno zrozumiesz mniej więcej na jakiej zasadzie to działa i jakie są plusy tego, a zapewniam Cię, że są.

Pzdr.

Mylisz pojęcia, programowanie strukturalne równie dobrze może zachowywać zasadę DRY. W przytoczonym przykładzie piszesz prostą funkcję do filtrowania, którą wykorzystasz wiele razy - nie musisz przekopiowywać tego samego kodu n razy. Programowanie proceduralne jak sama nazwa wskazuje, opiera się na procedurach/funkcjach, a nie na copy & paste.

Powielanie kodu to całkowicie inna bajka, równie dobrze powielać można tworząc kod w paradygmacie OOP, aczkolwiek stosowanie obiektów jest środkiem do tego aby powtórzeń było mniej, co nie znaczy że zawsze tak jest.

Wszystko pisać OOP a nic nie pisac nie.

Peter, może bezpośrednio nie ma DRY żadnego związku z OOP, ale pośrednio jak najbardziej tak. Przejrzyj proszę Cię parę aplikacji napisanych strukturalnie, a następnie obiektowo (najlepiej w frameworku) i wtedy będziesz miał zarys tego, o czym pisałem wyżej.

Robi się flame, bez sensu.

Wyobraź sobie, iż masz zamiar taką księgę gości, zastosować w 50 stronach na tym samym serwerze, jeśli masz możliwość takiej konfiguracji że pewne elementy będą wspólne, to aktualizując coś dodając jakąś nową funkcjonalność robisz to po prostu w jednym miejscu. Księga gości może wykorzystywać klasy np. do połączeń z bazą danych, ale i inne twoje projekty mogą je wykorzystywać, poco się powtarzać, masz już taką klasę w jednym miejscu i tylko z niej korzystasz, nie powielasz kodu. Poza tym tak było w przeszłości i na pewno będzie iż jakieś funkcje zostają zamieniane lub pojawiają się nowe, zmieniasz wtedy w jednym miejscu i wszędzie działa. Takie przykłady można mnożyć.
Ja w przeszłości robiłem wszystko strukturalnie bo PHP po prostu tylko to oferowało, ale z czasem oferuje coraz więcej i dlaczego tego nie wykorzystywać.
Zobacz na http://www.phpclasses.org/ polecam bo tam można znaleźć szereg zastosowań OOP.