Jak mogę ćwiczyć lepsze programowanie obiektowe? [Zamknięte]

Od lat programuję w językach obiektowych, ale potajemnie patrzę na niektóre rzeczy, które moi koledzy robią z zazdrością. Wydaje się, że wielu z nich ma jakiś wewnętrzny instynkt OO, którego ja nie mam - bez względu na to, jak bardzo się staram. Przeczytałem wszystkie dobre książki na temat OO, ale nadal nie mogę ich złamać. Czuję się jak facet, który dał z siebie 110% na bycie profesjonalnym piłkarzem, ale po prostu nie miał naturalnego talentu, by to osiągnąć. Jestem zagubiony i myślę o zmianie kariery - co mam zrobić?

Powiedziałbym, że skupiaj się mniej na programowaniu obiektowym, a bardziej na projektowaniu obiektowym . Chwyć kartkę i ołówek (a może narzędzie do modelowania UML) i odejdź od ekranu.

Ćwicząc, jak zaprojektować system, zaczniesz w naturalny sposób wyczuwać relacje między obiektami. Kod jest tylko produktem ubocznym projektu. Rysuj diagramy i modeluj swoją aplikację w formie czysto niekodowej. Jakie są relacje? Jak współdziałają modele? Nawet nie myśl o kodzie.

Po spędzeniu czasu na projektowaniu ... przetłumacz to na kod. Będziesz zaskoczony, jak szybko można napisać kod z dobrego projektu OO.

Po wielu praktykach projektowych zaczniesz widzieć wspólne obszary, które można modularyzować lub wyodrębnić, i zobaczysz poprawę zarówno w projektach, jak i w kodzie.

Najłatwiej jest nauczyć się takich pojęć, jak SOLID, DRY, FIT, DDD, TDD, MVC, itp. Kiedy spojrzysz na te akronimy, poprowadzi Cię to do wielu innych króliczych nory, a kiedy skończysz czytać, powinieneś mieć dobre zrozumienie, czym jest lepsze programowanie obiektowe!

Podcasty SOLID: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

SOLIDNY ​​podział: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

DRY: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

FIT: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

Wymagana lektura DDD: http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD: http://en.wikipedia.org/wiki/Test-driven_development

MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

I tak, zakasanie rękawów i kodowanie to zawsze dobry pomysł. Zrób mały projekt najlepiej jak potrafisz. Następnie przeczytaj artykuł z góry. Następnie zmodyfikuj kod, aby spełniał potrzeby tego, co właśnie przeczytałeś. Powtarzaj, aż do diabła zrefaktorujesz swój kod. Na koniec powinieneś nie tylko wiedzieć, o co chodzi w OO, ale powinieneś umieć wyjaśnić, dlaczego jest to ważne i jak zdobyć ich za pierwszym razem. Nauka refaktoryzacji jest również kluczem do dobrego kodu. To, co jest teraz, nie jest właściwe jutro.

Zbyt wiele osób myśli o kodowaniu najpierw, obiektach, na końcu.

Możesz przeczytać wszystkie książki, które chcesz, ale to nie nauczy cię myślenia obiektowego - wymaga to praktyki i określonej metodologii.

1. Oto kilka metod, które mi pomogły: Kiedy jesteś z dala od pracy i masz otwarty umysł, możesz ćwiczyć, patrząc na wszystko jak na przedmiot . Nie patrz na te obiekty i nie zastanawiaj się, jak je zaprogramujesz, spójrz na nie tylko jako na właściwości i funkcje oraz jak są ze sobą powiązane lub dziedziczą. Na przykład, kiedy widzisz osobę, jest ona przedmiotem i dlatego reprezentuje klasę. Mają takie właściwości, jak kolor włosów, odcień skóry, wzrost itp. Pełnią również określone funkcje. Chodzą, rozmawiają, śpią itp. Niektóre z funkcji tych osób dają wyniki. Na przykład ich funkcja robocza zwraca kwotę w dolarach. Możesz to zrobić ze wszystkim, co widzisz, ponieważ wszystko jest przedmiotem. Rower, samochód, gwiazda itp.

2. Przed zakodowaniem projektu zaprojektuj go za pomocą karteczek samoprzylepnych i tablicy do czyszczenia na sucho. Będzie to dobra praktyka, dopóki nie zrozumiesz tego. Pomyśl o swoim konkretnym obiekcie / funkcji / właściwości. Każdy z tych elementów będzie miał własną karteczkę samoprzylepną. Umieść je jako hierarchię na tablicy do czyszczenia na sucho. W związku z tym funkcja / właściwości zostaną umieszczone pod obiektem. Jeśli masz inny przedmiot, zrób to samo dla tego. Następnie zadaj sobie pytanie, zrób dowolne z tych notatek (obiekty / funkcje / właściwości) związane ze sobą. Jeśli dwa obiekty używają tej samej funkcji, utwórz obiekt nadrzędny (karteczkę samoprzylepną) i umieść go nad innymi z funkcją wielokrotnego użytku pod nową notatką. Narysuj linię za pomocą markera suchościeralnego od dwóch obiektów podrzędnych do rodzica.

3. Kiedy to wszystko zostanie zrobione, martw się o wewnętrzne aspekty tego, jak działa klasa.

Proponuję nauczyć się czegoś innego.

Naucz się programowania funkcjonalnego i zastosuj zdobytą wiedzę do OOP. Jeśli znasz C ++, pobaw się z programowaniem ogólnym.

Naucz się języków nie zorientowanych obiektowo.

Nie tylko dlatego, że powinieneś używać wszystkich tych rzeczy (powinieneś), lub dlatego, że powinny one całkowicie zastąpić OOP ( prawdopodobnie nie powinny), ale dlatego, że możesz zastosować lekcje z nich również do OOP.

Sekret OOP polega na tym, że nie zawsze warto go używać . Nie wszystko jest klasą. Nie każdy związek lub zachowanie powinny być modelowane jako klasa.

Ślepe próby zastosowania OOP lub dążenie do napisania najlepszego możliwego kodu OOP zwykle prowadzą do ogromnego, przeprojektowanego bałaganu ze zbyt wieloma poziomami abstrakcji i pośrednictwa oraz bardzo małą elastycznością.

Nie próbuj pisać dobrego kodu OOP. Spróbuj napisać dobry kod. I używaj OOP, gdy przyczynia się do osiągnięcia tego celu.

Na wielu polach jest moment „eureki”, w którym wszystko się łączy.

Pamiętam frustrację w geometrii w liceum. Nie wiedziałem, które twierdzenie zastosować na każdym etapie dowodu. Ale trzymałem się tego. Szczegółowo poznałem każde twierdzenie i przestudiowałem, jak zostały one zastosowane w różnych przykładowych dowodach. Ponieważ zrozumiałem nie tylko definicję każdego twierdzenia, ale także sposób jego użycia, zbudowałem „zestaw narzędzi” znanych technik, z których mogłem korzystać w razie potrzeby.

Myślę, że tak samo jest w programowaniu. Dlatego algorytmy, struktury danych i wzorce projektowe są badane i analizowane. Nie wystarczy przeczytać książkę i poznać abstrakcyjną definicję techniki. Musisz to zobaczyć w akcji.

Spróbuj więc czytać więcej kodu , oprócz ćwiczenia samodzielnego pisania. To jedna z zalet open source, możesz pobrać mnóstwo kodu do nauki. Nie cały ten kod jest dobry, ale studiowanie złego kodu może być tak samo edukacyjne, jak studiowanie dobrego kodu.

Naucz się innego języka! Większość programistów korzystających tylko z języka Java (jako przykład) ma tylko ograniczone zrozumienie OO, ponieważ nie mogą oddzielić funkcji i koncepcji językowych. Jeśli jeszcze tego nie wiesz, spójrz na Pythona. Jeśli znasz Pythona, naucz się Rubiego. Lub wybierz jeden z języków funkcjonalnych.

Odpowiedź jest w Twoim pytaniu;)

Ćwicz, ćwicz, ćwicz.

Przejrzyj swój kod i ucz się na błędach.

TDD pomogło mi najbardziej w poprawie ogólnego zestawu umiejętności, w tym OOP.

Im więcej kodu napiszesz, tym bardziej zauważysz pułapki niektórych praktyk programistycznych. Po odpowiednim czasie i wystarczającej ilości kodu będziesz w stanie zidentyfikować znaki ostrzegawcze tych pułapek i być w stanie ich uniknąć. Czasami, kiedy piszę kod, z tyłu głowy pojawia mi się swędzenie, które mówi mi, że może być lepszy sposób na zrobienie tego, nawet jeśli robi to, czego potrzebuję. Jedną z moich największych słabości w programowaniu jest „nadmierna analiza” rzeczy do tego stopnia, że ​​zaczyna radykalnie spowalniać czas programowania. Próbuję temu zapobiec, poświęcając trochę więcej czasu na projektowanie, co zwykle skutkuje znacznie mniejszą ilością czasu na pisanie kodu.

... potajemnie patrzę na niektóre rzeczy, które moi koledzy robią z zazdrością. Wydaje się, że wielu z nich ma jakiś wewnętrzny instynkt OO, którego ja nie mam - bez względu na to, jak bardzo się staram ...

Myślę, że odpowiedziałeś tutaj na swoje własne pytanie. Czytanie dobrego kodu to dobry początek, a zrozumienie dobrego kodu jest jeszcze lepsze, ale zrozumienie kroków prowadzących do tego dobrego kodu jest najlepsze. Kiedy zobaczysz kod, o który jesteś zazdrosny, być może możesz zapytać autora, jak doszedł do tego rozwiązania. Zależy to całkowicie od środowiska pracy, a także relacji z kolegami. W każdym razie, jeśli ktoś zapyta mnie o proces myślowy związany z jakimkolwiek kodem, który piszę, nie waham się mu powiedzieć, ponieważ wiem, że chciałbym, aby zrobili to samo dla mnie.

Projektanci języków interpretowali „programowanie obiektowe” na różne sposoby. Na przykład zobacz, jak zdefiniował go Alan Kay, człowiek, który jako pierwszy użył terminu OOP:

OOP oznacza dla mnie tylko przesyłanie wiadomości, lokalne przechowywanie i ochronę oraz ukrywanie procesów stanu i ekstremalnie późne wiązanie wszystkich rzeczy. Można to zrobić w Smalltalk i LISP. Prawdopodobnie są inne systemy, w których jest to możliwe, ale nie jestem ich świadomy.

(Cytat z http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

Może się wydawać dziwne, że nie bierze pod uwagę języków Java i C ++ OOP! Ale jako projektant jednego z pierwszych i najlepszych języków OOP (Smalltalk) ma ku temu własne uzasadnione powody. Dlaczego Alan Kay uważał Lispa za język zorientowany obiektowo, ale nie za Javę? To pytanie wymaga poważnego rozważenia przez każdego, kto twierdzi, że rozumie OOP.

Erlang ma zupełnie inną implementację OOP, Scheme ma inną. Warto rozważyć wszystkie te alternatywne poglądy. Jeśli to możliwe, naucz się wszystkich tych języków! To da ci szersze spojrzenie, da ci kilka nowych i potężnych narzędzi i uczyni cię lepszym programistą.

W tym artykule podsumowałem swoje eksperymenty z implementacją języka OOP, oparte na pomysłach zapożyczonych z Smalltalk, Scheme i Erlang .

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

Jeśli nie wiesz, jak projektować systemy obiektowe, zacznij od danych. Dowiedz się, jakie rzeczy musisz śledzić i jakie informacje naturalnie idą w parze (na przykład wszystkie specyfikacje modelu samochodu ładnie się łączą).

Każda z tych rzeczy, które zdecydujesz się śledzić, staje się klasą.

Wtedy, gdy trzeba umieć wykonać określone czynności (np. Oznaczenie modelu auta jako wycofanego z eksploatacji) lub zadać konkretne pytania (np. Zapytać ile danego modelu auta zostało sprzedanych w danym roku) ładujemy tę funkcjonalność na klasę, z którą oddziałuje najmocniej.

Ogólnie rzecz biorąc, w strukturze Twojej klasy zawsze powinno być całkiem naturalne miejsce dla danego fragmentu kodu. Jeśli go nie ma, oznacza to, że istnieje miejsce, w którym należy zbudować konstrukcję.

Jest za dużo informacji o obiektach. Najważniejsze jest opanowanie podstaw i łatwiej wszystko układa się na swoim miejscu.

Oto sposób myślenia o obiektach. Pomyśl o strukturach danych w językach proceduralnych. Są grupą pól bez zachowania. Pomyśl o funkcjach, które otrzymują wskaźniki do tych struktur danych i manipulują nimi. Teraz, zamiast rozdzielać je, zdefiniuj funkcje wewnątrz definicji struktur i załóż, że funkcje zwykle otrzymują wskaźnik do struktury danych, którą można manipulować. Ten wskaźnik nazywa się tym. Podsumowując, pomyśl o obiektach jako o połączeniu statusu (danych) i zachowania (metody - fantazyjna nazwa funkcji w OOP).

To jest absolutna podstawa. Są jeszcze trzy koncepcje, które musisz bezwzględnie opanować:

Dziedziczenie - chodzi o ponowne wykorzystanie kodu.

Hermetyzacja - chodzi o ukrycie implementacji przed interfejsem. Mówiąc najprościej, wszystko powinno pozostać prywatne, dopóki nie zostanie udowodnione, że jest inaczej.

Polimorfizm - nie ma znaczenia typ zmiennej referencyjnej, ale typ rzeczywistej instancji, aby wiedzieć, które zachowanie (metoda) jest wywoływane. Java nie sprawia, że ​​ta koncepcja jest bardzo widoczna, ponieważ z definicji wszystko jest polimorficzne. .Net ułatwia zrozumienie, gdy decydujesz, co jest polimorficzne, a co nie, stąd zauważasz różnicę w zachowaniu. Osiąga się to poprzez połączenie wirtualizacji i nadpisywania.

Jeśli te pojęcia są dobrze zrozumiane, wszystko będzie dobrze.

Ostatnia wskazówka: wspominasz o najlepszych książkach. Czy czytałeś „ Thinking in Java ” Bruce'a Eckela? Polecam tę książkę nawet osobom rozpoczynającym przygodę z .Net, ponieważ koncepcje OOP są jasno określone.

Stań się bardziej zwinny, naucz się testować junit i ucz się projektowania opartego na domenie. Proponuję książkę Domain-Driven Design: Tackling Complexity in the Heart of Software, chociaż w niektórych punktach jest to trochę trudne.

Umiejętności OOP pojawiają się z czasem. Czytanie 1, 2 ... 10 książek nie wystarcza. Poćwicz pisanie kodu. Jeśli pracujesz w środowisku programistycznym ... to może być pomocne. Jeśli nie, spróbuj się w to wciągnąć. Zaproponuj bezpłatne opracowanie niektórych aplikacji. Musisz ubrudzić sobie ręce. Pamiętaj ... żadna aplikacja nie jest idealna od podstaw, dlatego dochodzi do ponownego faktoringu.

Poza tym ... nie daj się zbytnio ponieść emocjom z OOP ... to z czasem. Martw się o tworzenie w pełni funkcjonalnych aplikacji.

Wypróbuj programowanie we własnym zakresie , jednym z najczystszych języków obiektowych. Tak czysty, że nie ma nawet klas, tylko obiekty. Nie ma też zmiennych, pól, statystyk, atrybutów, tylko metody. Ciekawe jest również to, że każdy obiekt w systemie jest również obiektem na ekranie i odwrotnie.

Niektóre z interesujących artykułów na temat Self to Prototype-Based Application Construction using SELF 4.0 (samouczek), Self: The Power of Simplicity i Organizowanie programów bez zajęć . Ponadto Self: The Video (Randall B. Smith; Dave Ungar) jest wspaniały, ponieważ dwóch projektantów języka wyjaśnia pomysły Self.

To działa w przypadku prawie każdej koncepcji, przynajmniej w moim przypadku: znajdź język, który najbardziej czysto uosabia koncepcję, której chcesz się nauczyć, i po prostu go użyj.

OO w końcu mnie kliknął, gdy próbowałem zaprogramować podobny do banku program, który obsługiwał transakcje, obliczał odsetki i śledził to wszystko. Zrobiłem to, gdy uczyłem się języka Java. Sugerowałbym po prostu wypróbowanie tego, ukończenie go, a kiedy skończysz, spójrz na DOBRE rozwiązanie i zobacz, co mogłeś zrobić lepiej.

Myślę też, że umiejętności OOP wzmacniane są głównie ćwiczeniami. Rozważ zmianę firmy, jeśli jesteś tam dłużej niż 3 lata. Z pewnością nie dotyczy to wszystkich zawodów, ale często człowiek przyzwyczaja się do projektów i praktyk w firmie i przestaje robić postępy w miarę upływu czasu.

Podwiń rękawy i zakoduj!

Sam powiedziałeś odpowiedź: ćwicz. Najlepszym rozwiązaniem jest stworzenie gry. Skorzystaj z pojęć, których nauczyłeś się w tamtejszych książkach.

Czy przeczytałeś rozdział o OO z pierwszego wydania książki Scotta Meyersa „Effective C ++”? Nie dotarło do późniejszych wydań, ale było to świetne wyjaśnienie. Tytuł brzmiał w zasadzie „mów, co masz na myśli, miej na myśli to, co mówisz” o odpowiednich konwencjach.

Właściwie możesz zobaczyć moją odpowiedź na podobne pytanie tutaj .

HTH

Twoje zdrowie,

Zaplanuj wszystko. Zadaj sobie pytanie, w jaki sposób chcesz, aby twoje obiekty odnosiły się do siebie nawzajem i dowiedz się, jak można je zmienić i zmodularyzować.

Zakoduj rzeczy w taki sposób, że jeśli chcesz zmienić 1 fragment kodu, musisz zmienić tylko ten 1 fragment kodu, a nie 50 jego wystąpień.

OOP nie jest rzeczą, którą można opanować, czytając tysiące książek. Musisz raczej poczuć wewnętrzne koncepcje. Czytaj wszystko, ale staraj się czuć to, co czytasz. Zbuduj koncepcję z tyłu swojego umysłu i spróbuj dopasować te koncepcje, gdy zmierzysz się z nowym scenariuszem. Weryfikuj i aktualizuj swoje koncepcje, odkrywając nowe rzeczy.

Powodzenia!

piwo pomaga. poważnie. położyć się na kanapie z notatnikiem A3, długopisem i piwem. Zamknij psa, kota i żonę na zewnątrz. I myśl o problemie będąc zrelaksowanym. Nie waż się nawet rysować na nim API!

Schematy blokowe, karty odpowiedzialności (CRC) i piwo (ale nie za dużo) to długa droga.

Najłatwiejszym sposobem na refaktoryzację kodu jest przede wszystkim rezygnacja z tego.

http://misko.hevery.com/code-reviewers-guide/

Te małe proste zasady sprawią, że będziesz lepszym programistą OO. Postępuj zgodnie z zasadami religijnymi podczas kodowania, a przekonasz się, że Twój kod jest lepszy niż byłby w innym przypadku.

Będziesz także chciał poznać Solidne zasady: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

O ile te zasady i sposoby programowania powodują debatę, są one jedynym sposobem na naprawdę doskonałe napisanie kodu.

Możesz już napisać kod w ten sposób i nie wiedzieć o tym - jeśli tak, to świetnie. Ale jeśli potrzebujesz celu, do którego chcesz dążyć, to jest to złoty standard.

Poddać się! Dlaczego potrzebujesz tego OOP? Po prostu napisz użyteczną aplikację. Nie ma znaczenia przy użyciu OOP, podejścia proceduralnego lub funkcjonalnego.

Jakie podejście wybierzesz Język Python powinien być odpowiedni, aby go przećwiczyć.

Jesteś moją grupą docelową. Spójrz na umiejętności budowania w projektowaniu OO

Może to pomoże.