Jak mogę wyjaśnić programowanie obiektowe komuś, kto jest zakodowany tylko w Fortran 77?

Moja mama zrobiła pracę magisterską w Fortranie, a teraz (ponad dekadę później) musi nauczyć się języka C ++ do symulacji płynów. Jest w stanie zrozumieć całe programowanie proceduralne, ale bez względu na to, jak bardzo staram się wytłumaczyć jej przedmioty, to się nie trzyma. (Dużo pracuję z Javą, więc wiem, jak działają obiekty). Myślę, że mógłbym to wyjaśniać na zbyt wysoki poziom, więc to nie ma sensu dla kogoś, kto nigdy z nimi nie pracował i urósł w dobie programowania czysto proceduralnego.

Czy jest jakiś prosty sposób, w jaki mogę jej wyjaśnić, które pomogą jej zrozumieć?

Krótka odpowiedź: nie.

Długa odpowiedź: nie ma „prostej drogi”, ponieważ OOP jest daleka od prostej. W programowaniu proceduralnym chodzi o „zmienne” i „jeśli to goto”. Cała reszta to cukier składniowy, ale wszystkie te cztery rzeczy dotyczą programowania proceduralnego. Gdy je zdobędziesz, nic Cię nie powstrzyma.

OOP to sposób organizowania zmiennych i fragmentów kodu. Ile jest wzorów do zdefiniowania OOP? 25? 30? Nawet nauczyciele, którzy nauczyli się OOP z różnych języków i środowisk, nie zgadzają się z własną definicją, więc ... jak to może być proste?

Nie wiem, jak do tego doszedłeś, ale skoro twoja matka ma podobne doświadczenie do mojego, mogę ci powiedzieć, jak do tego doszłam.

Programowałem w C w bardzo dużym projekcie. Był rok 1988. Wielu programistów organizujących moduły i biblioteki, z trudem unikania ingerencji w inne zadania i utrzymywania dobrego podziału obowiązków.

Doszliśmy do „rozwiązania” polegającego na umieszczeniu wszystkich powiązanych globalnych danych w strukturach, umieszczając w tych strukturach pewne wskaźniki funkcji, w których wymagane były wywołania zwrotne. Uogólniliśmy w ten sposób to, co nazwaliśmy io_mask(rodzaj okien dialogowych w trybie tekstowym) graphic_manageritp. Itd.

W 1996 r. Bardzo łatwo było odkryć, że struktury te zostały nazwane „klasami”, a wskaźniki funkcji zastąpiono funkcjami składowymi i funkcjami wirtualnymi lub łączami do innych obiektów (zwanymi zachowaniami) przez innych programistów, którzy odnowili ten stary projekt.

Zacząłem rozumieć OOP, kiedy zacząłem odczuwać potrzebę: segregacji, polimorfizmu i zachowań zdefiniowanych w środowisku wykonawczym.

Dzisiaj współpracuję z OOP, ale nie uważam tego za doktrynę, która ma służyć: po prostu „wspólny idiom” (zestaw ...), który pozwala nam rozmawiać razem bez potrzeby ciągłego podawania długich wyjaśnień i opisów . W rzeczywistości bardziej „konwencja” niż cokolwiek innego. W końcu wszystko, co robi OOP, to „ponownie” „jeśli to zrobię”: robi to po prostu „wielowarstwowo”. Stąd abstrakcja i idiomy nad idiomami.

Ignoruj ​​ich. Dopóki nie poczuje ich potrzeby, nawet nie próbuj wyjaśniać: poczuje je jako skomplikowany sposób robienia prostych rzeczy. I ma rację ... dopóki to, co robi, nie jest - w rzeczywistości - proste.

Nikt nie pomyśli o „zorganizowaniu biurka”, jeśli na górze są tylko cztery rzeczy. Ma to sens, gdy rzeczy na wierzchu zaczynają się wzajemnie zakłócać. Nadszedł czas na OOP.

Nie potrzebujesz OOP do pracy z C ++. Cała standardowa biblioteka C ++ nie jest zaprojektowana pod kątem OOP (chociaż może z nią współpracować), a C ++ nie jest Javą.

Z mojego doświadczenia wynika, że ​​najgorszymi nauczycielami C ++ i programistami C ++ są ci, którzy pochodzą z Javy, ucząc ich wszystkich uprzedzeń do wszystkiego, nie jest OOP, denaturuje język taki jak C ++, który nie jest (tylko) dla OOP.

Pozwól, że zasugeruję dobrą książkę dla tych, którzy chcą podejść do C ++: Accelerated C ++ : wprowadzi cię w idiomy C ++ bez udawania, że ​​postępujesz zgodnie ze zdefiniowaną doktryną.

Stary przyjaciel twierdził, że mam najkrótszą definicję, jaką znał programowania OO, i odkryłem, że działa on dla niektórych osób (a nie dla innych):

Programowanie obiektowe to dane z opinią. Nie poruszasz fotelem, prosisz go, aby sam się poruszył. Nie sortujesz listy, musisz ją posortować (być może z podpowiedzią). Itp.

Chodzi o to, aby osoba myślała inaczej o tym, jak rzeczy są wykonywane w ich programie.

Powiedz jej, aby pomyślała o przedmiotach takich jak przedmioty w prawdziwym świecie. Na przykład cały świat może być połączeniem programowania obiektowego (w C ++) z pewnego rodzaju programowaniem funkcjonalnym (prawdopodobnie wykonanym w boskim języku, Lisp).

Weź przedmiot, na przykład kosiarkę, ma pewne atrybuty i może coś zrobić. (obiekt i klasa)

Następnie powiedz jej o lepszej kosiarce, która jest przedłużeniem kosiarki, którą już masz. Powiedz jej, że jest lepiej, ale nadal opiera się na tym samym mechanizmie (dziedziczeniu).

Więc powiedz jej o sobie. Powiedz jej, że czasami możesz zostać ekspertem od koszenia trawników, ale tak naprawdę jesteś programistą i zarabiaj na życie. To tak, jakbyś działał jednocześnie jako dwie różne istoty. To jest polimorfizm.

Zanim to dostanie, powiedz jej, jak zaimplementować te rzeczy w języku, którego musi się nauczyć (C ++).

Następnie powiedz jej, że jeśli będzie musiała napisać symulację tego świata w świecie komputerowym, będzie musiała nauczyć się, jak to zrobić.

Kiedy wie, jak przekonwertować swoje myśli z prawdziwego świata na kod programu. nauczyłaby się programowania w obiektowym języku programowania.

Przeszedłem z asemblera i COBOL-a na Ruby.

Pomogło mi początkowo zignorowanie koncepcji tworzenia instancji przez klasy.

Po prostu zacznij od kodu. Miej klasę, ale tylko metody na poziomie klasy. W ramach metod wiele rzeczy dotyczy parametrów, zmiennych, warunków, tablic, ciągów znaków, booleanów itp. Te rzeczy powinny być znane.

W tym momencie klasa może być postrzegana jako służąca temu celowi jako miejsce do umieszczenia wszystkich powiązanych metod. Nazwij to pojemnikiem lub biblioteką, która będzie dla niej bardziej znana.

Oczywiście kod musi być podzielony na segmenty, aby był łatwy w zarządzaniu, więc będziesz mieć jeden z nich w każdym obszarze. Na przykład do zarządzania zestawem programów narzędziowych na komputerze PC może istnieć klasa kalkulatora, w której można umieścić cały kod kalkulatora w jednym miejscu. Jeśli masz tylko 1 kalkulator na komputerze, wystarczą metody na poziomie klasy.

To jest początek.

ok, teraz rozważ fakt, że chcesz otworzyć wiele kalkulatorów i zmienić wygląd każdego z nich i miejsce na ekranie. Więc teraz nie możesz mieć po prostu metody kalkulatora, takiej jak „screen_location”, ponieważ masz ich kilka, a każda instancja ma swoją lokalizację ... każda instancja ... ok, więc potrzebujemy instancji.

Uwaga: moje warunki pochodzą z Ruby, a nie z C ++, więc może być konieczne tłumaczenie.

Wyjaśniłbym to w dwóch krokach, a może czterech, w zależności od tego, jak bardzo chcesz podzielić swoje koncepcje.

Krok 1: Przedstaw ją strukturom. Jest to dość mały krok od typów danych Fortran do struktur. Krok 1a: upewnij się, że rozumie dynamiczne przydzielanie pamięci i wskaźniki.

Krok 2: dodaj procedury związane tylko z tymi strukturami. Krok 2a: dodaj dziedziczenie w oparciu o budowanie większych struktur, które „zawijają” mniejsze struktury.

Dla programisty z Fortran czynnik „wow” będzie polegał na tym, że wiele kompilatora musi śledzić. Tak. Do tego służą kompilatory ...

Gdyby napisała tę pracę dziesięć lat temu, prawdopodobnie użyłaby Fortan 90 lub 95, w którym to przypadku chodzi o to, aby porozmawiać o tym w związku z pochodnymi typami danych. Jeśli już dawno temu użyła Fortran 77, zapoznaj się z pochodnymi typami danych w Fortran 90, a następnie porozmawiaj o tym ...

Nie wchodziłbym w polimorfizm i dziedziczenie, dopóki nie złapie enkapsulacji, ponieważ można je postrzegać jako szczególne przypadki i rozszerzenia enkapsulacji. Prawdopodobnie uruchomiłbym ją w języku, który zezwala na bezpłatne funkcje lub klasy statyczne.

Kiedy zrozumie struktury, myślę, że następnym kluczowym punktem będzie uznanie, że programowanie obiektowe służy jako sposób ograniczenia zestawu metod, do których można przekazać rzecz, do zestawu metod, które można by faktycznie zastosować do tego rzecz.

W programowaniu bezorientowanym obiektowo, jeśli używa się osobnych typów danych dla drzewa i LinkedList, należałoby użyć różnych metod dodawania węzła do każdego z nich. Języki dla obiektowych byłoby generalnie skrzek jeśli ktoś próbował wymienić obie metody AddItem, ponieważ dana nazwa może odnosić się tylko do jednego sposobu, prowadząc w ten sposób na utworzenie nazwy metod, takich jak AddTreeItem, AddLinkedListItem, RemoveTreeItem, itd. Takie an prace podejście, ale to trochę brzydki. Koncepcyjnie, metody AddTreeItemi RemoveTreeItemwydają się pasować do siebie, ale nazwy nie sortują w ten sposób. Można przepisać nazwiska jak TreeAddItem, TreeRemoveItem,LinkedListAddItemitd., ale spowodowałoby to wiele „nadmiarowego hałasu” na początku każdej wywołania metody. Zdecydowana większość wywołań metod w typowym programie będzie zawierała trzy podstawowe informacje: (1) która sekcja kodu źródłowego zawiera metodę; (2) która z metod opisanych w sekcji jest stosowana; (3) na jaki rodzaj danych działa? W wielu przypadkach rodzaj przetwarzanych danych będzie wystarczający do zidentyfikowania, do której sekcji kodu należy metoda, więc część (1) powyższego jest zbędna. Łatwiej jest wizualnie zidentyfikować materiał na początku instrukcji niż materiał gdzie indziej, więc styl kodowania / nazewnictwa TreeAddItem(myTree, whatever)kończy się umieszczaniem najmniej użytecznej informacji na pierwszym miejscu.

W przeciwieństwie do tego, stosując programowanie obiektowe, należałoby skutecznie nazwać metody jako Tree.AddItemitp., A instrukcja podobna myTree.AddItem(whatever)sprawiłaby, że kompilator powiedziałby w zasadzie: „Hmm ... myTreejest typu Tree, więc ten kod powinien się wywoływać Tree.AddItem(). Nie jest konieczne określ Tree.wywołanie, AddItemponieważ kompilator zna typ myTree. Pod względem koncepcyjnym podobne zdanie myTree.AddItem(whatever)jest równoważne Tree.AddItem(myTree, whatever), a niektóre języki obiektowe mogą dopuszczać obie formy jako równoważne; w rzeczywistości większość języków pomija pierwszy parametr ze specyfikacji funkcji i zamiast tego ma metody, które są zdefiniowane w klasie jak Treeniejawnie podjąć parametru typu Treei przypisać mu nazwę jak this, selflub Me.

Zorientowane obiektowo języki programowania często zawierają szereg dodatkowych funkcji, takich jak dziedziczenie, funkcje wirtualne itp., Które są bardzo przydatne w wielu aplikacjach, ale nawet bez tych funkcji zdolność grupowania funkcji według rzeczy, na których działają, jest bardzo przydatna.

Programowanie obiektowe - w znaczeniu tutaj zorientowanym klasowo - polega na sprzężeniu reprezentacji danych z kodem, który nimi manipuluje. Ma to sens, jeśli następujące rzeczy mają sens:

• Łączenie: definiowanie operacji obok reprezentacji danych, na której działa

• Późne wiązanie: wybór kombinacji reprezentacji danych i zachowania w czasie wykonywania

• Hermetyzacja: upewnienie się, że dane są prawidłowe z założenia i nie zostaną później unieważnione

To wszystko. Jak każda technologia, jej sednem jest po prostu wygoda, z której później wynikało wiele zmian. Gdy zrozumiesz podstawy, reszta nastąpi w czasie.

Sugerowałbym pobranie BlueJ, granie z nim przez 20 minut, a następnie granie z nim przez 20 minut.

Sposób, w jaki wizualizuje klasy, interfejsy i dziedziczenie, jest tak oczywisty i intuicyjny, że naprawdę daje natychmiastowe zrozumienie, gdy coś implementujesz - cokolwiek.

Pokazuje nawet bezpośrednio różnicę między klasą a obiektem

Nie da to głębokiego wglądu w wzorce projektowe OO, ale zapewni fantastyczny przegląd koncepcji.

Chciałbym dodać mój wkład jako przypomnienie rozróżnienia między paradygmatami programowania a językami programowania, które implementują te paradygmaty.

Tak więc, moim zdaniem, najlepszym sposobem na wyjaśnienie orientacji obiektowej w C ++ dla użytkownika F77 byłoby postępowanie krokowe:

Najpierw zapoznaj użytkownika z koncepcją orientacji obiektowej w znanym otoczeniu, pokazując jej, jak rozwijać struktury podobne do obiektów w Fortran 77 - na przykład, spójrz na artykuły takie jak B. Patton „Obiektowa Fortran 77 (praktyka) zobacz) „SIGPLAN Fortran Forum 12, 2 (1993), s. 23–24 i odnośniki tam zawarte.

Następnie ustal zgodność między tymi strukturami a klasami i metodami C ++.

Na koniec omów dodatkowe funkcje oferowane przez C ++ w celu ułatwienia programowania OO.

Kiedy po raz pierwszy przeprowadziłem migrację do języka obiektowego z mojego wstępnego szkolenia w Pascal, „.” problem też był dla mnie największą przeszkodą. Przejście tego zajęło mi lata.

To naprawdę nieintuicyjne, że zmienna należy do innej zmiennej, szczególnie gdy przyzwyczajasz się do myślenia o nich jako o wskaźnikach. Utrudnieniem było dla mnie:

• Co to znaczy, że coś, co jest po prostu wskaźnikiem, ma inny wskaźnik wskazujący na to, który rozwiązuje coś innego niż wskaźnik nadrzędny?

Aha był dla mnie momentem, kiedy zdałem sobie sprawę, że wskaźnik najwyższego poziomu był w zasadzie tylko przestrzenią nazw.

Sugerowałbym, żeby napisała kilka kodów, które wymagają od przestrzeni nazw jej funkcji, najlepiej bez użycia notacji kropkowej na początek. Następnie poproś ją, aby spróbowała przepisać go za pomocą notacji kropkowej.

Wykonanie tego ćwiczenia powinno dać jej przewagę nad początkowym „Co to za czary?” przeszkoda.

Jednym kluczowym wglądem, który pomógł mi wcześniej wyjaśnić, jest fakt, że możesz mieć wiele instancji klasy. Spróbuj wyjaśnić to w kategoriach „rysunków” lub „form” i „kopii” i sprawdź, czy prowadzi to gdziekolwiek.