Witam.

Chciałbym się podzielić z wami swoimi wątpliwościami na temat nauki OOP. Otóż mam solidne podstawy (bardzo solidne) – 2 lata klepania strukturalnie programów, CMS-ów itp. dla pewnej firmy z Ostrowa Wielkopolskiego (z grzeczności nie będę wymieniał z nazwy).

Co prawda wszystkie te projekty z powodzeniem działają do dzisiaj (trzeba było trochę o nie zadbać ale myślę że to normalka). Problem w tym że po takim czasie zauważam w tych wszystkich stronach że to niesamowity szajs. Dziś (tzn. w niedalekiej przyszłości) przyjdzie mi napisać coś swojego (co mógłbym sprzedać). Oczywiście jako że ja swoją osobą będę te(n) produkt(y) reprezentował, zacząłem zgłębiać tajniki OOP (co prawda już wiele razy wcześniej miałem styczność z obiektami ale tym razem szukałem czegoś konkretnego – na tyle kompleksowego aby utworzyć już dosyć stabilną, szybką, niezawodną i przenośną aplikację).

Przejdę do konkretów. Otóż mija już czwarty tydzień moich poszukiwań (dziesiątki przeczytanych kartek, dzisiątki //jeśli nie steki// przejrzanych stron www, dziesiątki przeczytanych wątków na forum (BTW pozdrawiam wszystkich stałych bywalców – ostatnio śnią mi się Wasze nicki po nocach ). I tu pojawia się mój problem ponieważ dobrze rozumiem ideę OOP znam jego zalety, dostrzegam je. Trapi mnie natomiast ilość informacji. PDO, ORM-y, MVC, Adaptery, Singeltony, Strategy, SOLID, DI, PoEAA etc, etc...

Jako że jestem raczej perfekcjonistą (poprzednie projekty wynikały raczej z niewiedzy niż braku chęci ) //powiem szczerze że miałem ochotę kilka razy nieźle popoprawiać te starocie ale kto mi za to zapłaci …// dlatego zastanawiam się czy jest sens i czy w ogóle możliwe jest (na)pisanie od samego początku „idealnego” kodu (napisałem w cudzysłowie ponieważ w głębi duszy czuję że taki kod nie istnieje – zawsze znajdzie się coś szybszego ). W końcu trzeba szlifować dobre nawyki tyle tylko że napisanie prostego kodu nie sprawia żadnego problemu (nawet gdy w grę wejdą bazy danych) ale ile na takich prostych metodach można ciągnąć?

Czy znowu mam klepać podstawy OOP przez rok czy dwa?
Jak to u was wyglądało? Bo troszkę czuję że ten czas spędzony na programowaniu strukturalnym był stracony (co prawda wrył mi się cały język dokumentnie w mózg ale co z tego)?
Wiem że są Frameworki. Ale czy sens jest uczyć się Frameworka skoro dopiero po jego nauczeniu się będę wiedział czy mi się przyda. A jeśli nie to co? Uczyć się kolejnego?

Przepraszam Was za ten wyczerpujący wywód i że straciliście kilka minut życia na czytanie tego.

Pozdrawiam.

Dawid.

Wracam do pisania ….

ja chętnie doradzę pisanie własnego MVC. wiadomo wtedy co z czego się bierze. można skrobać jakieś projekty z czasem widzisz czego brakuje, co sprawia że masz tylko monotonne pisanie, a nie logiczny kod.
dużo też zależy czy lubisz pisać aby zarobić czy bardziej aby ładnie się to kupy trzymało. ale wyraźnie napisałeś "jestem raczej perfekcjonistą" to odradzam uczenia się framework'a. identyczny, a nawet lepszy (bardziej optymalny) kod można uzyskać pisząc od podstaw (choć trwa to dojść długo). no i czasem zdarzy się że będziesz pisał n razy tą samą klasę od początku (trafiają się przebłyski geniuszu i nagle całość idzie łatwiej rozw. - jeden z powodów pisania od nowa )
no i najważniejsze - nie przejmuj się, że niektórzy mówią "po co wynajdywać koło od nowa". tzn. nie żebyś też wszystko pisał od nowa, ale w większości. masz wtedy większą "kontrolę" nad działaniem aplikacji i znasz słabe i mocne strony.

tyle z mojej strony,
pozdrawiam i życzę odnalezienia swojej drogi

Po prostu zacznij wykorzystywać i odkrywać komfort tworzenia w oop, daj sobie czas na oswojenie się z nieco innym niż strukturalne podejściem do pisania aplikacji, a z czasem dostrzeżesz zalety i ogromną przewagę OOP nad kodem proceduralnym. Nikt Ci nie wbije do głowy, ani nie przekona na siłę do zalet podejścia obiektowego, wkrótce sam się przekonasz, nie wystarczą same dobre chęci poznania, trzeba też spróbować i dać sobie wystarczająco dużo czasu na przyzwyczajenie się do zmian. Framework (jeden z wiodących) może być dla Ciebie równie dobrym, co złym startem, ale to zależy od Twojego charakteru i sposobu przyswajania wiedzy.

Pisanie własnego MVC.pewnie, tylko że trzeba umieć chodzić aby zacząć biegać.
Według mnie dobrym ćwiczeniem jest przerobienie wzorców projektowych. Robisz sobie listę, wybierasz jeden np "dekorator".

1. Znajdujesz kod (im więcej tym lepiej, przykłady z różnych źródeł) z reifikacjami danego wzorca
2. Czytasz, uruchamiasz rozkminiasz.
3. Jak już ci się wydaje że wiesz o co chodzi to zamykasz wszystkie te informacje i starasz się od zera, samemu odtworzyć.
4. Nie wyszło to dzień przerwy i od punktu 2.

Dziękuję Wam za te porady.

Rozumiem że każdy ma swoją metodę zależną od charakteru. Niemniej jednak jestem dość uparty a poza tym lubię programować więc przetestuję każdą z Waszych metod. Być może któraś z nich (może kilka) okaże się skuteczna.

Poza tym i tak uważam że to co robię cały czas to nie zginie. Jeśli przestudiuję techniki w różny sposób to przynajmniej będę miał w przyszłości bardziej elastyczne podejście mając na uwadze wszelkie aspekty.

Pozdrawiam.

@topic: nie ma czegoś takiego, jak idealny kod. Co najwyżej może być zgodny ze standardami i dobrymi nawykami programistycznymi, wydajny, dobrze udokumentowany, optymalny i bardzo dobrze skalowalny.
// edit
i jeszcze tani w późniejszej tzw. konserwacji

Szczerze mówiąc to bardzo przypominasz mi mnie samego, i to co sam robię aktualnie. Na początku raczej robiłem coś w php bo ciekawiło mnie to i nie będę się oszukiwał że pisałem strukturalnie (a kto nie?) i to w sumie też przez podobny czas, tyle że ja nie pracowałem wówczas w żadnej firmie związaną z IT.

Śmiać mi się trochę chcę, oczywiście bez urazy, ale na prawdę mnie to śmieszy, jak wszyscy piszą MVC, MVC i MVC. Rozumiem że można mieć różne wyobrażenia na temat danego wzorca, ale sorry, mnie ta nachalność MVC i wrzucania tego wszędzie gdzie się da, zwyczajnie odrzuca. Więc moja rada jest taka, żebyś się nie sugerował tym wzorcem, a wybrał taki jaki będzie odpowiadał twojej wizji/idei. Wzorce to wzorce, standardy to standardy. Trzymaj się standardów, wzorzec sobie wybierz taki jaki ci odpowiada, bo się tylko przejedziesz, uwierz mi

Od jakiegoś czasu szlifuje swoje oop, nie wiem właściwie czy aby to co robię jest dobrym podejściem, dlatego jak skończę pewnie pokażę jakiejś części ludzi, być może nawet na forum tutaj wrzucę, żeby wytknąć mi błędy, czy wskazać lepsze rozwiązania. Na chwilę obecną w sumie jestem całkiem zadowolony z tego co zrobiłem i postępów jakie uczyniłem przez ostatni czas. Także jeżeli jesteś uparty tak jak ja (2 dni nie spałem, żeby zrozumieć regex na tyle żeby większość problemów móc rozwiązać samemu) to szybko ci to zejdzie. Książek kilka przeczytałem, być może źle kupiłem, ale te co mam, to są trochę przestarzałe (zamiast preg_ wszędzie eregi itp), a jako takich materiałów ciekawych w sieci nie znalazłem, które poprowadziłby by mnie za rączkę. Postanowiłem więc analizować jakieś frameworki. Zaczęło się od kohany 2, która częściowo była jeszcze strukturalna, no ale jak to zawsze bywa, reklamowana jako oop/mvc framework.. I potem zmierzyłem się z symfony 1.4, zendem i odrobinę kohana 3. Ostatnio trochę jeszcze symfony 2 i trochę rzeczy po analizie kodu i próbach zrozumieniu "jak to działa", coś tam do głowy mi weszło.

Odnośnie tematu. Kod idealny będzie istniał tylko wtedy kiedy nie osiągniemy żadnych postępów. Zwyczajnie zrobimy coś i nic w kierunku ulepszania swojej wiedzy nie zrobimy, ten kod będzie dla nas idealny. Ale tak bywa raczej rzadko, zazwyczaj to nawet na drugi dzień, już widzimy jak można napisać lepiej ten sam kod, ale raczej to jest dobry objaw.

http://pl.wikipedia.org/wiki/DRY
http://pl.wikipedia.org/wiki/Brzytwa_Ockhama
Fail.
Jeśli uważasz że obecne fw są słabo napisane, napisz własny lepszy.
Ale nie namawiaj usera aby olewał DRY...

Czyli mam rozumieć że warto bazować na doświadczeniach innych. Ale tak uściślając: radzisz opierać się i analizować kod frameworków czy z nich korzystać?

Na pewno korzystanie z doświadczenia innych Ci nie zaszkodzi. Implementowanie gotowych rozwiązań ma swoje plusy. Możesz dowiedzieć się "jak robią to inni", zobaczyć co Ci przeszkadza i co zrobiłbyś (w swoim mniemaniu ) lepiej.

Nie koniecznie cały FW będzie ci się nie podobał. FW takie jak zend czy symfony mają bardzo dużo pluginów/komponentów które bez większego problemu działają bez danego FW i w tym przypadku wymyślanie koła na nowo jest dobrze powiedziane. Polecam niektóre komponenty symfony 2, jak chociażby httpfundation, tam masz obiekty od resposne (nagłówki) i request, session (ten akurat mniej mi się podoba i z niego nie korzystam). Zobacz sobie routing w symfony 1.4 (ten mi się najbardziej podobał) i w sumie z każdego fw, czy tam innych bibliotek pozbierać trochę i już masz większość swojego FW napisane, posklejać to jakoś (dependancy injection jest fajne), dorobić trochę swojego kodu i masz gotowego FW.

Osobiście uważam, że pisanie obiektowe jest czymś, co przychodzi naturalnie. Najpierw zaczynasz używać pojedynczych obiektów, później samych obiektów, następnie zaczynasz rozumieć różnicę pomiędzy obiektami brzegowymi (interfejs), obiektami sterującymi (to co jest pomiędzy corem, a interfejsem), a encjami, zaczynasz dostrzegać sens stosowania tego podziału. Później zauważasz taki cudowny twór jakim jest klasa abstrakcyjna i wszystko staje się prostsze. Później poznajesz interfejs i pomimo bolesnych początków, dostrzegasz coraz więcej plusów z jego stosowania. No i są jeszcze wzorce. Mimo boleści, które towarzyszą zrozumieniu tego wszystkiego, po jakimś czasie dostrzegasz, że było warto i nie potrafisz pojąć, jak mogłeś napisać chociaż linijkę kodu bez tego wszystkiego:)


Przejrzyj oferty pracy, a będziesz wiedział, który ci się przyda:)


Pisanie własnego FW ma sens tylko i wyłącznie wtedy, jeżeli ma sens:P Chodzi mi o to, że pisanie FW, to mnóstwo rzeczy, które nie mają żadnego związku z pisaną aplikacją np. jeżeli chcesz system do zarządzania danymi klientów, to na czym się skupiasz? Na tym jak obsługiwać routing, pliki językowe, połączenie z bazą, architekturę (MVC, MVP etc.)? Czy raczej nie marnujesz na to czasu i piszesz, to na czym ci zależy? Jeżeli piszesz aplikacje internetowe, to jest tyle rzeczy do zrobienia, że naprawdę warto się odciążyć i skorzystać z gotowego FW i ORM'a. Jasne, że własny FW może być wydajniejszy (jeżeli jest dobrze napisany), ale tak jak pisałem wyżej, takie zabiegi mają sens tylko wtedy, gdy jest to potrzebne. Prędkość twojego internetu też może być szybsza, bo możesz poprowadzić własny światłowód, ale decydujesz się używać tego, co jest, bo połączenie, które masz jest wystarczające:)


Przerobienie wzorców jak najbardziej, ale to naprawdę polecam zostawić na koniec, bo w trakcie uczenia się OOP i poprawnego jego stosowania mimowolnie napotkasz kilka i łatwiej ci później będzie je zrozumieć. A poza tym wzorce trzeba ugryźć wielokrotnie żeby tak naprawdę je zrozumieć. Nie wystarczy przeczytać definicji z wikipedii.


MVC, to nie tylko wzorzec projektowy, a architektura, a co za tym idzie, dużo cięższa jest jego pełna implementacja. W PHP nie do spotkania. MVC, HMVC, MVP itp. czy to ważne? Moim zdaniem dużo istotniejszy jest podział obiektów na sterujące, brzegowe i encje, bo to ten podział to kwestia, która później ułatwia zrozumienie logiki, jej rozbudowę bądź zmianę.