Dlaczego OOP jest trudny? [Zamknięte]

Kiedy zacząłem używać języka obiektowego (Java), po prostu przeszedłem na „Cool” i zacząłem kodować. Nigdy tak naprawdę nie myślałem o tym aż do niedawna po przeczytaniu wielu pytań na temat OOP. Mam ogólne wrażenie, że ludzie się z tym zmagają. Ponieważ nie uważałem tego za trudne i nie powiedziałbym, że jestem geniuszem, myślę, że musiałem coś przeoczyć lub źle to zrozumieć.

Dlaczego OOP jest trudny do zrozumienia? Czy trudno to zrozumieć?

Osobiście uważałem, że mechanika OOP jest dość łatwa do zrozumienia. Najtrudniejsze było dla mnie „dlaczego”. Kiedy zostałem po raz pierwszy zetknięty, wydawało mi się, że to rozwiązanie problemu. Oto kilka powodów, dla których myślę, że większość ludzi ma trudności:

1. Nauczanie OO od początku przez IMHO to okropny pomysł. Kodowanie proceduralne nie jest „złym nawykiem” i jest właściwym narzędziem do niektórych zadań. Poszczególne metody w programie OO i tak wydają się dość proceduralne. Ponadto, zanim nauczy się programowania proceduralnego wystarczająco dobrze, aby jego ograniczenia stały się widoczne, OO nie wydaje się zbyt przydatne dla studenta.

2. Zanim naprawdę zrozumiesz OO, musisz poznać podstawy struktur danych oraz funkcje późnego wiązania / wyższego rzędu. Trudno wywołać polimorfizm (który w zasadzie przekazuje wskaźnik do danych i zestaw funkcji, które działają na danych), jeśli nawet nie rozumiesz koncepcji konstruowania danych zamiast używania prymitywów i przekazywania funkcji wyższego rzędu / wskaźniki do funkcji.

3. Wzorów projektowych należy uczyć jako czegoś podstawowego dla OO, a nie czegoś bardziej zaawansowanego. Wzory projektowe pomagają zobaczyć las przez drzewa i dają względnie konkretne przykłady, w których OO może uprościć prawdziwe problemy, a w końcu i tak będziesz chciał się ich nauczyć. Ponadto, gdy naprawdę pojawi się OO, większość wzorów projektowych staje się oczywista z perspektywy czasu.

Myślę, że jest kilka czynników, o których jeszcze nie wspomniano.

Przede wszystkim, przynajmniej w „czystym OOP” (np. Smalltalk), gdzie wszystko jest przedmiotem, musisz przekręcić swój umysł w raczej nienaturalną konfigurację, aby myśleć o liczbie (tylko dla jednego przykładu) jako inteligentnym obiekcie zamiast tylko wartość - ponieważ w rzeczywistości 21(na przykład) naprawdę jest tylko wartością. Staje się to szczególnie problematyczne, gdy z jednej strony dowiesz się, że dużą zaletą OOP jest dokładniejsze modelowanie rzeczywistości, ale zaczynasz od spojrzenia na coś, co wygląda okropnie jak inspirowany LSD widok nawet najbardziej podstawowych i oczywistych części rzeczywistość.

Po drugie, dziedziczenie w OOP nie bardzo ściśle podąża za modelami umysłowymi większości ludzi. Dla większości ludzi klasyfikowanie rzeczy w szczególności nie ma żadnych zasad absolutnych niezbędnych do stworzenia działającej hierarchii klas. W szczególności, tworzenie class Ddziedziczącego z innego class Boznacza, że ​​obiekty class Ddzielą się absolutnie, pozytywnie, wszystkimi cechami class B. class Dmoże dodawać nowe i różne własne cechy, ale wszystkie cechy class Bmuszą pozostać nienaruszone.

Z drugiej strony, kiedy ludzie klasyfikują rzeczy mentalnie, zwykle postępują według znacznie luźniejszego modelu. Na przykład, jeśli dana osoba ustanawia pewne reguły dotyczące tego, co stanowi klasę obiektów, dość typowe jest, że prawie każda reguła może zostać złamana, o ile przestrzegane są wystarczające inne reguły. Nawet te kilka zasad, których tak naprawdę nie można złamać, prawie zawsze można trochę „rozciągnąć”.

Na przykład rozważ „samochód” jako klasę. Łatwo zauważyć, że zdecydowana większość tego, co większość ludzi uważa za „samochody”, ma cztery koła. Jednak większość ludzi widziała (przynajmniej zdjęcie) samochód z tylko trzema kołami. Kilku z nas w odpowiednim wieku pamięta również samochód wyścigowy lub dwa z wczesnych lat 80. (lub mniej więcej), który miał sześć kół - i tak dalej. To daje nam zasadniczo trzy możliwości:

1. Nie twierdzę nic o tym, ile kół ma samochód - ale prowadzi to do domniemanego założenia, że ​​zawsze będzie to 4, i kodu, który prawdopodobnie złamie inną liczbę.
2. Zapewnij, że wszystkie samochody mają cztery koła, i po prostu sklasyfikuj te inne jako „nie samochody”, chociaż wiemy, że tak naprawdę są.
3. Zaprojektuj klasę, aby umożliwić zmianę liczby kół, na wszelki wypadek, nawet jeśli istnieje duża szansa, że ​​ta zdolność nigdy nie będzie potrzebna, używana ani odpowiednio testowana.

Nauczanie o OOP często koncentruje się na budowaniu ogromnych taksonomii - np. Fragmentów czegoś, co byłoby gigantyczną hierarchią całego znanego życia na ziemi lub czegoś w tym porządku. Rodzi to dwa problemy: po pierwsze, prowadzi wielu ludzi do skupienia się na ogromnych ilościach informacji, które są całkowicie nieistotne dla danego pytania. W pewnym momencie widziałem dość długą dyskusję o tym, jak modelować rasy psów i czy (na przykład) „miniaturowy pudel” powinien odziedziczyć po „pełnowymiarowym pudle” lub odwrotnie, czy też powinna istnieć abstrakcyjna baza „Pudel” „klasa, z„ pełnowymiarowym pudlem ”i„ miniaturowym pudlem ”, które dziedziczą po nim. Wszyscy zdawali się ignorować to, że aplikacja miała zajmować się śledzeniem licencji dla psów,

Po drugie, i prawie co ważne, prowadzi to do skupienia się na charakterystyce przedmiotów, zamiast skupiać się na cechach, które są ważne dla danego zadania. Prowadzi to do modelowania rzeczy takimi, jakie są, gdzie (przez większość czasu) naprawdę potrzebna jest budowa najprostszego modelu, który zaspokoi nasze potrzeby, i użycie abstrakcji, aby dopasować niezbędne podklasy, aby dopasować abstrakcję, którą zbudowaliśmy.

Na koniec powiem jeszcze raz: przez lata powoli podążamy tą samą ścieżką baz danych. Wczesne bazy danych były zgodne z modelem hierarchicznym. Poza skupieniem się wyłącznie na danych, jest to pojedyncze dziedziczenie. Przez krótki czas kilka baz danych działało zgodnie z modelem sieci - zasadniczo identycznym jak wielokrotne dziedziczenie (i patrząc pod tym kątem, wiele interfejsów nie różni się wystarczająco od wielu klas bazowych, aby zauważyć lub o to dbać).

Jednak dawno temu bazy danych były w dużej mierze zbieżne na modelu relacyjnym (i chociaż nie są one SQLem, na tym poziomie abstrakcji obecne bazy danych „NoSQL” również są relacyjne). Zalety modelu relacyjnego są na tyle dobrze znane, że nie zawracam sobie głowy ich powtarzaniem. Po prostu zauważę, że najbliższym analogiem modelu relacyjnego, który mamy w programowaniu, jest programowanie ogólne (i przykro nam, ale pomimo nazwy, generyczne Java, na przykład, tak naprawdę nie kwalifikują się, chociaż są niewielkim krokiem w dobry kierunek).

OOP wymaga umiejętności abstrakcyjnego myślenia; dar / przekleństwo, które tak naprawdę ma niewiele osób, nawet profesjonalnych programistów.

Myślę, że możesz podsumować podstawową trudność w ten sposób:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

Jasne, ludzie mogą przyzwyczaić się do mapowania „lewej” jako 270, a tak, powiedzenie „Car.Turn” zamiast „obrócić samochód” nie jest tak wielkim skokiem. ALE, aby dobrze sobie radzić z tymi obiektami i je tworzyć, musisz odwrócić normalne myślenie.

Zamiast manipulować obiektem, mówimy temu obiektowi, aby faktycznie robił rzeczy samodzielnie. To może już nie być trudne, ale polecenie otwarcia okna brzmi dziwnie. Ludzie nieprzyzwyczajeni do tego sposobu myślenia muszą nieustannie zmagać się z tą dziwnością, aż w końcu stanie się ona naturalna.

Każdy paradygmat wymaga pewnego popchnięcia „ponad krawędź”, aby zrozumieć, dla większości ludzi. Z definicji jest to nowy sposób myślenia, dlatego wymaga pewnej ilości porzucenia starych pojęć i pewnego stopnia pełnego zrozumienia, dlaczego nowe pojęcia są użyteczne.

Myślę, że duży problem polega na tym, że metody nauczania programowania są ogólnie dość słabe. OOP jest teraz tak powszechny, że nie jest tak zauważalny, ale nadal często go widać w programowaniu funkcjonalnym:

• ważne pojęcia ukryte są pod nieparzystymi nazwami (FP: Co to jest monada? OOP: Dlaczego czasami nazywają je funkcjami, a innym razem metodami?)

• nieparzyste koncepcje są objaśniane w metaforach, a nie w kategoriach tego, co faktycznie robią, dlaczego ich używasz, lub dlaczego ktokolwiek myślał o ich użyciu (FP: Monada to skafander kosmiczny, zawija trochę kodu. OOP: An obiekt jest jak kaczka, może hałasować, chodzić i dziedziczyć po zwierzętach)

• dobre rzeczy różnią się w zależności od osoby, więc nie jest całkiem jasne, co będzie punktem zwrotnym dla każdego ucznia, a nauczyciel często nawet nie pamięta. (FP: Och, monady pozwalają ukryć coś w samym typie i kontynuować bez konieczności jawnego zapisywania tego, co się dzieje za każdym razem. OOP: Och, obiekty pozwalają zachować funkcje dla pewnego rodzaju danych z tymi danymi.)

Najgorsze jest to, że jak wskazuje pytanie, niektórzy ludzie natychmiast zrozumieją, dlaczego koncepcja jest dobra, a niektórzy nie. To naprawdę zależy od tego, jaki jest punkt krytyczny. Dla mnie kluczem było uchwycenie, że obiekty przechowują dane i metody dla tych danych, po czym wszystko inne po prostu pasuje jako naturalne rozszerzenie. Potem miałem skoki, jak uświadomienie sobie, że wywołanie metody z obiektu jest bardzo podobne do wykonania wywołania statycznego z tym obiektem jako pierwszym parametrem.

Małe skoki później pomagają udoskonalić zrozumienie, ale jest to pierwsza, która zabiera osobę z „OOP nie ma sensu, dlaczego ludzie to robią?” do „OOP jest najlepszy, dlaczego ludzie robią coś jeszcze?”

Ponieważ podstawowe wyjaśnienie OOP ma bardzo, bardzo mało wspólnego z tym, jak jest używane w terenie. Większość programów do nauczania tego próbuje używać modelu fizycznego, takiego jak „Myśl o samochodzie jako obiekcie, a koła o obiektach, drzwiach i skrzyni biegów ...”, ale poza pewnymi niejasnymi przypadkami programowania symulacyjnego, obiekty są znacznie częściej wykorzystywane do reprezentowania pojęć niefizycznych lub do wprowadzania pośrednich. Skutkuje to tym, że ludzie rozumieją to intuicyjnie w niewłaściwy sposób.

Nauczanie na podstawie wzorców projektowych jest znacznie lepszym sposobem na opisanie OOP, ponieważ pokazuje programistom, jak niektóre rzeczywiste problemy z modelowaniem można skutecznie atakować obiektami, zamiast opisywać je w sposób abstrakcyjny.

W większości nie zgadzam się z odpowiedzią dsimcha:

1. Nauczanie OO od samego początku nie jest złym pomysłem, podobnie jak nauczanie języków proceduralnych. Ważne jest to, że uczymy ludzi pisania jasnego, zwięzłego, spójnego kodu, niezależnie od OO lub proceduralnych.

2. Poszczególne metody w dobrych programach OO wcale nie są proceduralne. Staje się to coraz bardziej prawdziwe wraz z ewolucją języków OO (czytaj C #, ponieważ inny niż C ++ to jedyny inny język OO, jaki znam) i ich składnia staje się coraz bardziej złożona z dnia na dzień (lambda, LINQ do obiektów itp.). Jedynym podobieństwem między metodami i procedurami OO w językach proceduralnych jest ich liniowy charakter, który, jak sądzę, wkrótce by się zmienił.

3. Nie można również opanować języka proceduralnego bez zrozumienia struktur danych. Koncepcja wskaźnika jest równie ważna dla języków proceduralnych, jak dla języków OO. Na przykład przekazywanie parametrów przez odniesienie, co jest dość powszechne w językach proceduralnych, wymaga zrozumienia wskaźników tak samo, jak wymagane jest nauczenie się dowolnego języka OO.

4. Nie sądzę, że wzorców projektowych należy uczyć w ogóle na początku programowania OO, ponieważ w ogóle nie są one fundamentalne dla programowania OO. Z pewnością można być dobrym programistą OO, nie wiedząc nic o wzorcach projektowych. W rzeczywistości osoba może nawet stosować dobrze znane wzorce projektowe, nawet nie wiedząc, że są one udokumentowane odpowiednimi nazwami i że napisano o nich książki. Zasadniczo należy uczyć zasad projektowania, takich jak pojedyncza odpowiedzialność, otwarte zamknięcie i segregacja interfejsu. Niestety, wielu ludzi, którzy uważają się za programistów OO w tych dniach, albo nie znają tej podstawowej koncepcji, albo po prostu ignorują ją i dlatego mamy tak dużo śmieciowego kodu OO.

Tak, aby odpowiedzieć na pytanie oryginalnego plakatu, OO jest trudniejszym do zrozumienia pojęciem niż programowanie proceduralne. Jest tak, ponieważ nie myślimy o właściwościach i metodach przedmiotów z prawdziwego życia. Na przykład ludzki mózg nie myśli o „TurnOn” jako o metodzie telewizyjnej, ale postrzega ją jako funkcję włączania telewizora przez człowieka. Podobnie, polimorfizm jest obcą koncepcją dla ludzkiego mózgu, który na ogół widzi każdy obiekt z życia tylko jedną „twarzą”. Dziedzictwo znowu nie jest naturalne dla naszych mózgów. To, że jestem programistą, nie oznacza, że ​​mój syn byłby jednym z nich. Mówiąc ogólnie, ludzki mózg musi być przeszkolony do nauki OO, podczas gdy języki proceduralne są dla niego bardziej naturalne.

Myślę, że wielu programistów ma trudności z początkowym projektowaniem i planowaniem na początek. Nawet jeśli ktoś wykona dla ciebie cały projekt, nadal możesz oderwać się od zasad OOP. Jeśli wezmę garść kodu spaghetti i wrzucę go do klasy, czy to naprawdę OOP? Ktoś, kto nie rozumie OOP, może nadal programować w Javie. Nie myl też trudności w zrozumieniu z niechęcią do stosowania określonej metodologii lub nie zgadzania się z nią.

Powinieneś przeczytać Objects Never? Cóż, prawie nigdy. (Wymagane członkostwo w ACM) przez Mordechai Ben-Ari, który sugeruje, że OOP jest tak trudne, ponieważ nie jest to naturalny paradygmat, który jest czymś naturalnym. (Chociaż mam zastrzeżenia do tego artykułu, ponieważ nie jest jasne, jakie kryteria jego zdaniem program musi spełnić, aby powiedzieć, że jest napisany na paradygmacie OOP w przeciwieństwie do paradygmatu proceduralnego używającego języka OO).

Programowanie obiektowe samo w sobie nie jest trudne.

Trudność polega na tym, aby robić to dobrze. Gdzie umieścić wycięcie między kodem, aby łatwo przenieść rzeczy do wspólnego obiektu podstawowego i rozszerzyć je później? Jak sprawić, by Twój kod był użyteczny dla innych (rozszerzanie klas, zawijanie serwerów proxy, metoda przesłonięcia) bez przeskakiwania przez obręcze, aby to zrobić.

To jest trudna część, a jeśli zrobione dobrze, może być bardzo eleganckie, a jeśli zrobione źle, może być bardzo niezdarne. Moje osobiste doświadczenie jest takie, że potrzeba dużo praktyki, aby być we wszystkich sytuacjach, w których ŻYCZYŁEŚ, abyś zrobił to inaczej, aby tym razem zrobić to wystarczająco dobrze .

Właśnie oglądałem wideo Richarda Feynmana omawiające, w jaki sposób ludzie mogą mieć zupełnie inne metodologie w głowie, myśląc - mam na myśli zupełnie inną sytuację.

Kiedy robię projektowanie na wysokim poziomie, zdarza mi się wizualizować obiekty, widzę je, widzę ich interfejsy i widzę, jakie ścieżki muszą przechodzić informacje.

Mam również problemy z zapamiętywaniem szczegółów i uznałem, że OO jest świetną pomocą organizacyjną - dużo łatwiej jest znaleźć funkcjonalność niż skanowanie luźno zorganizowanej listy podprogramów.

Dla mnie OO było wielką korzyścią, ale jeśli nie wizualizujesz w ten sam sposób lub nie robisz architektury wysokiego poziomu, prawdopodobnie jest to bezcelowe i denerwujące.

Zrobiłem programowanie GW-Basic i Turbo Pascal dość długo, zanim zapoznałem się z OO, więc początkowo MÓGŁEM się tym zająć.

Nie mam pojęcia, czy tak dzieje się z innymi, ale dla mnie było tak: mój proces myślenia o programowaniu był czysto proceduralny. Jak w: „takie i takie się zdarzają, a następnie takie i takie mają miejsce w następnej kolejności” itp. Nigdy nie uważałem, że zmienne i dane są czymś więcej niż przelotnymi aktorami w przebiegu programu. Programowanie to „przepływ działań”.

Przypuszczam, że to, co nie było łatwe do uchwycenia (tak głupio, jak mi się teraz wydaje), to pomysł, że dane / zmienne naprawdę naprawdę mają znaczenie , w głębszym sensie, niż bycie ulotnymi aktorami w „przepływie” programu. Innymi słowy: próbowałem zrozumieć to, co się dzieje , a nie to , co jest , co jest prawdziwym kluczem do uchwycenia tego.

Nie sądzę, że trudno to zrozumieć, ale może się zdarzyć, że wielu programistów pytających jest nowością w koncepcji, pochodzących z języków proceduralnych.

Z tego, co widziałem / czytałem wiele osób (przynajmniej na forach) szukaj „wyniku” z OOP. Jeśli jesteś programistą, który nie wraca i nie modyfikuje rozszerzenia swojego kodu, prawdopodobnie trudno będzie zrozumieć korzyści.

Ponadto istnieje wiele złych OOP, jeśli ludzie czytają / widzą to, łatwo jest zrozumieć, dlaczego mogą być dla nich trudne.

IMO musisz poczekać, aż „kliknie” lub zostać nauczonym przez kogoś z prawdziwą wiedzą, nie sądzę, że możesz się spieszyć.

Myślę, że dla wielu osób OOP jest trudne, ponieważ narzędzia tak naprawdę nie ułatwiają tego.

Dzisiejsze języki komputerowe są abstrakcją tego, co dzieje się na komputerze.

OOP to abstrakcyjny sposób reprezentowania abstrakcji.

Tak więc używamy abstrakcji do budowania abstrakcji za pomocą abstrakcji. Dodaj do tego, że to, co abstraktujemy, to zwykle bardzo złożone interakcje fizyczne / społeczne i, cóż, nic dziwnego.

Mam blog o nazwie „Struggles in Object Oriented Programming”, który powstał w wyniku niektórych moich problemów z nauką tego. Myślę, że szczególnie trudno było mi to zrozumieć, ponieważ spędziłem tyle czasu na programowaniu proceduralnym i miałem trudność z myśleniem o tym, że obiekt może być reprezentowany przez zbiór atrybutów i zachowań (byłem przyzwyczajony do po prostu zbiór zmiennych i metod).

Ponadto istnieje wiele pojęć, które sprawiają, że język jest zorientowany obiektowo - dziedziczenie, interfejsy, polimorfizm, kompozycja itp. Naprawdę wiele można się nauczyć na temat teorii tego języka, zanim będzie można faktycznie pisać kod w sposób zorientowany obiektowo sposób, podczas gdy w przypadku programowania proceduralnego, jest to po prostu kwestia zrozumienia rzeczy, takich jak przydział pamięci dla zmiennych i wywołania punktu wejścia do innych metod.

Motywacja. Trudniej jest się czegoś nauczyć, gdy nie rozumiesz dlaczego, a także wtedy, gdy nie możesz spojrzeć na to, co zrobiłeś, i stwierdzić, czy zrobiłeś to dobrze, czy nie.

Potrzebne są małe projekty, które wykorzystują OO do robienia użytecznych rzeczy. Proponuję przejrzeć książkę o wzorach projektowych i znaleźć taki, który jest oczywiście przydatny i dobrze współpracuje z OO. (Użyłem Strategii za jednym razem, gdy ją wypróbowałem. Coś takiego jak Flyweight lub Singleton byłoby złym wyborem, ponieważ są to sposoby używania obiektów w ogólności, a nie używania obiektów do osiągnięcia czegoś.)

Myślę, że zależy to od wieku (wiek jako wskaźnik doświadczenia) i, co ważniejsze, zainteresowania. Jeśli jesteś „młody” (to znaczy być może zielony) i nigdy nie myślałeś w inny sposób, wydaje się to całkiem proste. Z drugiej strony, jeśli uważasz, że jest to najfajniejsza rzecz, jaką kiedykolwiek widziałeś - przytrafiło mi się w wieku 28 lat lub coś w tym rodzaju - łatwo się zdziwić.

Z drugiej strony, jeśli myślisz, podobnie jak wielu moich studentów Javy, „dlaczego się tego uczymy, to tylko moda”, praktycznie nie można się tego nauczyć. Dotyczy to większości technologii.

Bez względu na wybrany paradygmat (OOP, funkcjonalny itp.), Aby napisać program komputerowy, musisz wiedzieć, jakie kroki wykona Twój program.

Naturalnym sposobem definiowania procesu jest zapisywanie jego kroków, w przypadku większych zadań dzielisz je na mniejsze kroki. To jest procedura, tak działa komputer, w ten sposób krok po kroku przeglądasz listę kontrolną.

OOP to inny sposób myślenia. Zamiast myśleć o liście kontrolnej zadań, które należy wykonać krok po kroku, myślisz o przedmiotach, ich umiejętnościach i relacjach. Więc napiszesz wiele obiektów, małych metod, a twój program będzie działał magicznie. Aby to osiągnąć, musisz przekręcić umysł ...

I dlatego OOP jest trudne. Ponieważ wszystko jest przedmiotem, wszystko, co robią, polega na proszeniu innych obiektów o zrobienie czegoś, a te inne przedmioty w zasadzie robią niektóre. Tak więc sterowanie w programie OOP może gwałtownie przeskakiwać między obiektami.

Jako osoba, która obecnie uczy się programowania i ma pewne problemy w tym obszarze, nie sądzę, aby koncepcja była tak trudna do zrozumienia, jak konkretne jej implementacje. Mówię to, ponieważ mam pomysł na OOP i używam go w PHP przez około rok, ale kiedy przechodzę do C # i patrzę na wykorzystanie obiektów przez innych programistów, stwierdzam, że wiele osób robi to na różne sposoby których po prostu nie rozumiem. Właśnie to doprowadziło mnie do lepszego zrozumienia zasad OOP.

Oczywiście zdaję sobie sprawę, że problemem jest najprawdopodobniej mój brak doświadczenia z językiem ojczystym OOP i że z biegiem czasu znajdę nowe sposoby wykorzystania obiektów, które będą tak samo niejasne dla nowego programisty jak to, czym jestem obecnie doświadczam. Jerry Coffin dotyka tego kilka razy, szczególnie w swoim komentarzu:

Staje się to szczególnie problematyczne, gdy z jednej strony dowiesz się, że dużą zaletą OOP jest dokładniejsze modelowanie rzeczywistości, ale zaczynasz od spojrzenia na coś, co wygląda okropnie jak inspirowany LSD widok nawet najbardziej podstawowych i oczywistych części rzeczywistość.

Uważam, że jest to bardzo dokładne, ponieważ to wrażenie, które często mam, widząc kogoś, kto tworzy klasy dla rzeczy, które tak naprawdę nie są rzeczami - konkretny przykład mi ucieka, ale najbliższy, jaki mogę wymyślić w locie, traktuje odległość jak obiekt (edytuję następnym razem, gdy zobaczę coś, co powoduje to samo zamieszanie). Czasami OOP wydaje się chwilowo lekceważyć własne zasady i staje się mniej intuicyjny. Zdarza się to najczęściej, gdy obiekty wytwarzają obiekty, dziedziczą od klasy, która je obudowuje, i tak dalej.

Myślę, że dla kogoś takiego jak ja, pomaga myśleć o obiektach jako mających wiele aspektów, z których jedna obejmuje traktowanie czegoś takiego jak obiekt, gdy inaczej by nie był. Coś w rodzaju odległości, z niewielkim przesunięciem paradygmatu, może wydawać się przedmiotem teoretycznym, ale nie takim, który można trzymać w dłoni. Muszę myśleć o tym jako o zestawie właściwości, ale bardziej abstrakcyjnym zestawie zachowań, takich jak dostęp do jego właściwości. Nie jestem pewien, czy jest to klucz do mojego zrozumienia, ale wydaje się, że to właśnie tam prowadzą moje obecne badania.

Terminologie były dla mnie przeszkodą w nauce zasad programowania obiektowego (POOP). Kiedy zrozumiesz podstawy, elementy zaczynają się układać. Podobnie jak wszystkie rzeczy uczenie się nowych koncepcji jest trochę trudne.

Uzgodniono, że wzorce projektowe należy badać co najmniej równolegle do OOP.

Głównym skokiem było dla mnie zrozumienie abstrakcyjnej koncepcji OOP. Teraz jestem zupełnie nowy w programowaniu. Programuję od roku do półtora roku, więc moje wprowadzenie do OOP dotyczyło ActionScript i Processing. Kiedy po raz pierwszy nauczyłem się kodowania ActionScript, nie było go w OOP. Nauczyłem się kodować bezpośrednio w panelu Operacje i w ten sposób poznałem podstawowe podstawy programowania (zmienne, funkcje, pętle itp.). Nauczyłem się więc, że robię coś bezpośrednio na scenę we Flashu lub Przetwarzaniu.

Kiedy pojawiło się OOP, uświadomienie sobie, że mogę tworzyć metody i właściwości w obiekcie, aby móc go używać i ponownie wykorzystywać, było początkowo trochę trudne. Wszystko było bardzo abstrakcyjne i trudne do przetworzenia, ale same języki programowania były znacznie lepsze, ale w pewnym sensie trzeba było zrobić krok naprzód, aby nawiązać te połączenia.

Przepis

Dobre zrozumienie OOP = Dobry mentor lub dobre książki lub oba + Osobiste zainteresowania + Praktyka.

Zainteresowanie osobiste

Z mojego osobistego doświadczenia wynika , że osobiste zainteresowanie przechodzi długą drogę od przejścia od programowania proceduralnego do OOP z odpowiednimi opiniami mentorów lub dobrych książek lub razem .

Ćwicz, ćwicz i ćwicz

Moim najlepszym przyjacielem, aby lepiej zrozumieć OOP, była tylko praktyka. To zdecydowanie wzmocni twoje umiejętności OOP.

Jak mówi przysłowie: „Nie ma substytutu ciężkiej pracy ani skrótu do sukcesu”.

Powodzenia!