Jak można uczyć OO bez odwoływania się do fizycznych obiektów świata rzeczywistego? [Zamknięte]

Pamiętam, że czytałem gdzieś, że oryginalne koncepcje OO polegały na znalezieniu lepszej architektury do obsługi przesyłania danych między wieloma systemami w sposób, który chroniłby stan tych danych. Jest to prawdopodobnie kiepska parafraza, ale sprawiło, że zastanawiałem się, czy istnieje sposób uczenia OO bez analogii obiektów (Rower, Samochód, Osoba itp.), A zamiast tego koncentruje się na aspektach związanych z przesyłaniem wiadomości. Jeśli masz artykuły, linki, książki itp., Byłoby to pomocne.

Oryginalna koncepcja OO nie ma nic wspólnego z dzisiejszym OO. (Zobacz, co * miał * na myśli * Alan Kay naprawdę miał na myśli termin „obiektowy”? ). Dzisiejsze programowanie obiektowe JEST o tworzeniu obiektów takich jak metafory rowerów, domów i ludzi itp. Gorąco polecam trzymanie się ich, ponieważ celem tych metafor jest pomoc ludziom w zrozumieniu za pomocą koncepcji, którą już rozumieją. Pomóż im dostrzec korelację, a następnie pomóż im dostrzec różnice, Później zanurz się w głębsze rzeczy na temat OO.

EDYCJA: Dzisiejszy OO polega na tworzeniu w pełni samodzielnych obiektów, których właściwości i zdolności są w pełni / częściowo opisane przy użyciu różnych metod (funkcji) i atrybutów (odwołuje się do zmiennych i stałych AKA).

Możesz mówić o koncepcjach sprzężenia i spójności. Obiekty powinny składać się z atrybutów i metod o wysokiej kohezji i domyślnie wysokim sprzężeniu. Powinny one być odwzorowane na najmniej szczegółowe operacje i atrybuty potrzebne do działania systemu. Powinny również zaspokoić pragnienie, aby kod był jak najmniejszy i najprostszy, tj. Kodowanie z myślą o konserwacji i rozszerzalności.

Zapobiega to także „eksplozji obiektu”, nadmiernej uogólnieniu i błędnemu wyborowi metafory, które są powszechnymi błędami.

Nie skupiałbym się na obiektach z prawdziwego świata i nie skupiałbym się również na przesyłaniu wiadomości. Zamiast tego użyłem przykładu w grafice, w której chcesz mieć obiekty, które „potrafią się rysować”.

Jeśli pracujesz na przykład w C, który nie ma wbudowanego OO, wygodne może być przechowywanie wskaźników do funkcji wewnątrz obiektów danych. Jeśli tak, to wkraczasz do OOP.

Nie lubię odnosić się do Alana Kaya, jakby był Mojżeszem, który podaje tablice. Uważam, że był raczej szkolony z matematyki i bio. Jako matematyk prawdopodobnie znał Lambda Calculus, który był dość abstrakcyjny, niezwiązany ze sprzętem. W LC można powiedzieć, że wszystko jest „obiektem” - podobnie jak liczba 0 i liczba 1 są obiektami, które oceniają różne rzeczy po podaniu argumentu. To całkiem ładnie prowadzi do Smalltalk. Idea „wiadomości” polega na tym, że możemy uniknąć rozmowy o sprzęcie. Można powiedzieć, że gdy wywołujesz funkcję (lub metodę obiektu), wysyłasz jej wiadomość, a gdy ona powraca, wysyła wiadomość do ciebie (lub do kontynuacji). Zostało to przyjęte jako sposób opisania sposobów komunikacji między programami działającymi asynchronicznie na osobnym sprzęcie. W porządku, ale w przypadku zwykłego programowania jest to porywające. Aby uzyskać wartość idei OOP, nie musisz zaprzeczać trafności konkretnego zadania, które próbujesz wykonać, ani zaprzeczać konkretności sprzętu, na którym pracujesz. Myślę, że nauczanie o OOP w kategoriach wymyślonych analogii prowadzi ludzi do zbytniego myślenia o projektowaniu oprogramowania w kategoriach struktury danych, co prowadzi do jego nadprojektowania, co prowadzi do rozdęcia kodu i ogromnych problemów z wydajnością, które muszę poświęcić na sprzątanie, kiedy robi się wystarczająco źle.

Twierdziłbym, że nie ma różnicy w użyciu obiektu fizycznego na przykład i użyciu obiektu niefizycznego jako przykładu. W kodzie oba mają dokładnie te same części. Jeśli użyjemy przykładu graficznego i nauczymy go za pomocą Kuli, sześcianu, cylindra, będzie on prawie taki sam jak użycie kulki, pudełka i słupa.

Więc, aby uczyć tego bez użycia przykładów fizycznych, sugerowałbym, aby w ogóle nie używać żadnych przykładów, ale nie rozumiem, dlaczego nie chcielibyście przykładów fizycznych, więc moje stanowisko w tej sprawie brzmi:

Nie, nie powinieneś tego uczyć bez fizycznych obiektów świata rzeczywistego

Nie rozumiem, jak możesz uniknąć rozpoczynania od prawdziwych metafor, ale nie chcesz tam pozostać . Jeśli dobrze robisz OOP, szybko staje się ono abstrakcyjne, ale na następnym poziomie zrozumienia uczeń powinien rozumieć przedmioty jako obiekty.

Co ciekawe, niektóre z moich ulubionych przykładów nie są przedmiotami fizycznymi. Weźmy na przykład konto bankowe. Każdy „rozumie”, dlaczego depozyt () i wypłata () powinny pobierać opłatę za usługę, zamiast polegać na kodzie telefonicznym w celu zmiany wartości salda i pamiętać o zdjęciu opłaty za usługę. Kształty na ekranie są podwójnie niematerialne, a Stroustrup powiedział mi, że klasyczny przykład „Kształty” jest jednym z dwóch najstarszych przykładów OO, które zna, sprzed 40 lat (drugi to pojazdy, które mają teraz 44 lata).

Ważne jest, aby ludzie od razu zrozumieli twoje przykłady. Windy stanowią dobry przykład tylko dla osób, które są zaznajomione z windami. Itp.

Jeśli jesteś w grupie programistycznej, zbierz kilka osób i zacznij dyskutować, w jaki sposób powiedziałbyś sobie nawzajem, aby zrobili to, czego potrzebujesz od systemu. Dosłownie przyjmuj role w systemie (możesz to zrobić sam, po prostu grając każdą rolę, ale łatwiej jest z grupą ludzi. Zabawki pomagają, jeśli jesteś sam). Skoncentruj się na tym, co każda osoba robi / zrobi, a nie na tym, jakie dane ma. Robienie tego z ludźmi pomaga skupić się na wiadomościach i rolach, ponieważ ludzie zwykle pamiętają, co robią, ale nie dane, które mają.

Zwróć uwagę na to, co musisz sobie nawzajem zrobić i jakie informacje musisz to zrobić. Chroń swoje dane, jeśli inny programista poprosi o twoje dane, powiedz „nie” i zapytaj, dlaczego ich potrzebuje (pomaga w enkapsulacji danych).

Myślę, że przydatne może być podejście oddolne / metalowe. Najpierw wyjaśnij struktury i wskaźniki w stylu C, aby pokazać, w jaki sposób można uporządkować dane, a nie tylko bezpośrednio używać prymitywów. Następnie wyjaśnij wskaźniki późnego wiązania i funkcji. Następnie wyjaśnij, że możesz ich użyć do budowy obiektów, które są właściwie dobrze zamkniętymi stertami danych i wskazują funkcje potrzebne do działania na tych danych.

Wyjaśnienie to jest sprzeczne z konwencjonalnym sposobem nauczania koncepcji matematyki / comp sci niezależnie od implementacji, ale to perspektywa sprawiła, że ​​(co prawda ktoś z inżynierią, a nie z wykształceniem inżynieryjnym) w końcu dostałem OO.