Jak wyjaśnić koncepcje OOP osobie nietechnicznej?

Często staram się unikać mówienia ludziom, że jestem programistą, ponieważ przez większość czasu tłumaczę im, co to naprawdę znaczy. Kiedy mówię im, że programuję w Javie, często zadają ogólne pytania na temat języka i tego, jak różni się on od xiy. Nie jestem też dobry w wyjaśnianiu rzeczy, ponieważ 1) Nie mam zbyt dużego doświadczenia w terenie i 2) Naprawdę nie lubię tłumaczyć rzeczy nietechnicznym osobom.

Mówią, że naprawdę rozumiesz rzeczy, kiedy wyjaśnisz je komuś innemu, w tym przypadku, jak wyjaśniłbyś terminologię i koncepcje OOP osobie nietechnicznej?

Zasadniczo próbuję opisywać programowanie obiektowe na podstawie przykładów z prawdziwego świata.

Na przykład, mogę powiedzieć, że klasa o nazwie Vehicleopisuje minimalne rzeczy, którymi jest pojazd. Poproszę osobę, aby powiedziała mi, co on lub ona uważa za pojazd. Czasami mówią takie rzeczy jak „Cóż, jak samochód lub ciężarówka”, a ja kiwam głową i się z nimi zgadzam. Potem zapytam, jakie są różnice między samochodem a ciężarówką. Czasami wspominają o rozmiarze, czasem o celu i innych rzeczach.

Następnie poproszę ich, aby zapomnieli o samochodzie lub ciężarówce i po prostu poproszę, aby kontynuowali opisywanie pojazdu:

„Och, dobrze się porusza”

„Ma operatora lub kierowcę”

itp...

Wkrótce wiemy, co to jest Pojazd, i powiedziałem, że w OOP zdefiniujemy pojazd, a dla argumentu stwierdzimy, że może się poruszać i dać swego rodzaju kierowcę. Więc zapytam, ok, więc co ma samochód?

„Drzwi”

„Windows”

A potem ciężarówka ....

„Drzwi” „okna” „Więcej kół!”

Wkrótce po wielu dyskusjach druga osoba ogólnie zidentyfikowała:

1) Co stanowi pojazd

2) Co stanowi samochód

3) Co stanowi ciężarówkę

4) Co stanowi samolot.

Wszystko bez żadnych szczegółów technicznych. Podzieliliśmy właściwości każdego z nich na odpowiednie obszary. Rozumieją dziedziczenie („Tak, samochód jest pojazdem, ciężarówka jest pojazdem, ale samochód nie jest ciężarówką, jest PROSTY, duh!”).

Rozumieją nawet polimorfizm: „Jasne, w zasadzie robią to samo, ale może to nieco inaczej”. Możemy mówić o zachowaniu i miejscu, w którym powinno ono mieszkać w naszym drzewie obiektów.

W zależności od wykształcenia i pochodzenia niektórzy zdobywają go szybciej niż inni. Ale gdy porównuję OOP do rzeczywistych obiektów, większość ludzi zawsze je otrzymuje. W rozmowach z osobami nietechnicznymi odnalazłem rzeczy, o których nigdy nie myślałem. Pojazdy nie muszą być na przykład obsadzone (drony), ale czy programista pomyślałby o operatorze pojazdu jako o jego własności? Nie twierdzę, że wymienienie operatora jest dobre lub złe, ale powoduje, że myślimy o tym, co modelujemy i co staramy się osiągnąć, opracowując oprogramowanie.

Teraz częściowa specjalizacja szablonów, z drugiej strony .... :)

Obiekty to rzeczowniki, metody to czasowniki.

Oto niektóre wersje mojej odpowiedzi w puszce, które przekazuję ultra nietechnicznej osobie:

Programowanie to próba stworzenia reprezentacji rzeczywistości na komputerze. Istnieje wiele narzędzi i urządzeń, które już to robią - pomyśl o tym, jak arkusz kalkulacyjny ułatwia nam reprezentowanie rachunkowości lub statystyk, lub o tym, jak prezentacja Powerpoint pozwala nam przechowywać i wyświetlać nasze prezentacje.

Czasami musimy budować niestandardowe odwzorowanie rzeczywistości w nowych lub istniejących aplikacjach, które odzwierciedlają nasze procesy biznesowe. Istnieje wiele sposobów programowania, a jednym z najczęstszych sposobów programowania jest programowanie obiektowe, gdzie budowany przez nas kod jest specjalnie zaprojektowany, aby powielać pojęcia rzeczywistości. „Rzeczy” w rzeczywistości mają atrybuty i zachowania. Na przykład człowiek często ma ręce i nogi, kolor włosów, pochodzenie etniczne i często potrafi mówić i chodzić.

Mówienie i chodzenie mogą występować w różnych odmianach, na przykład w jakim języku się mówi, lub w jakim tempie lub w jakim chodzą.

Istoty ludzkie często mają interakcje z innymi rodzajami „rzeczy”, bez względu na to, czy są to zwierzęta, inni ludzie, inne żywe organizmy, czy też przedmioty nieożywione. W rzeczywistości istnieją tematy, które często wymagają reprezentacji, takie jak interakcje między „rzeczami”, kategoryzacja rzeczy itp. Rozważ procesy biznesowe zachodzące w naszej organizacji. Istnieje bardzo skomplikowana „logika biznesowa”, która musi być reprezentowana w oprogramowaniu używanym przez naszą organizację.

Programowanie obiektowe zapewnia środki do dokładnego przedstawienia „koncepcji świata rzeczywistego” i „logiki biznesowej”.

-> To stwierdzenie zwykle wystarcza, aby powstrzymać ich ciekawość (lub być może nudzi ich łzy), ale jeśli mają więcej pytań, powyższe stwierdzenie (wierzę) stanowi dobrą podstawę do tego, gdzie może pójść rozmowa. Nie sądzę, aby osoba nietechniczna zbytnio zajmowała się terminologią techniczną, taką jak „Abstrakcja”, „Kompozycja”, „Polimorfizm” itp., Ale jeśli tak, to język, którego użyłem w oświadczeniu w puszce, pozwala mi wyciągać z nich przykłady.

Zawsze uczyłem się OOP w ten sposób:

Masz zegar, który pokazuje czas - cóż, w programowaniu umieściłeś cały kod i rzeczy, które musisz zrobić wszystko razem (brzmi to dość oczywisto, ale ludzie nie robili tego w przeszłości). W każdym razie nazywa się to enkapsulacją .

Teraz masz zegar, możesz chcieć budzik - cóż, po zebraniu wszystkich rzeczy możesz dodać do niego różne rzeczy, aby zrobić więcej - na przykład ustawić alarm i włączyć dzwonek. Nazywa się to dziedziczeniem .

Ponadto patrzysz na zegar, który mam na nadgarstku, ale możesz też mieć inne zegary, które wyglądają inaczej, jak zegar dziadka lub zegar cyfrowy. Wygląda inaczej, ale wciąż jest zegarem - to się nazywa polimorfizm .

I tam masz 3 rogi programowania obiektowego. Cała reszta to tylko kodowanie.

Powiem im, żeby zapisali się na kurs OOP, jeśli naprawdę chcą to zrozumieć.

Mam na myśli wszystkie te analogie jak Car.startEngine (); są, spójrzmy prawdzie w oczy - czysty rap. Kiedy wiele lat temu po raz pierwszy znalazłem się w OOP, odkryłem, że jeszcze bardziej abstrahują domenę.

Zamiast wyjaśniać, że OOP polega na zarządzaniu złożonością języków proceduralnych, prawie 80% autorów książek programistycznych zakłada, że ​​programiści są bezsensownymi idiotami, którzy muszą być wypowiadani prostymi (patrz ironia tutaj?).

Tak, zupełnie normalne jest wyjaśnianie list i wektorów, ponieważ z tym głównie współpracujemy, a nie z Car.Engine i PoliceMan.Arrest (chyba że jesteś programistą, ale z drugiej strony, nadal musisz mieć swój udział w były).

Wracając do tematu, powiem im tylko, że tworzę nienamacalne przedmioty, które istnieją wyłącznie w umyśle programisty, w celu przetwarzania płac / gry / nawigacji wahadłowca itp.

Jeśli nadal mają pytania, przestań dyskutować, bo to nie jest tego warte. Większość ludzi nie wyobraża sobie abstrakcyjnych pojęć i potrzebuje przykładów na wszystko (co w rzeczywistości oznacza więcej uproszczenia / specjalizacji danego tematu).

Mówiłem o rozmowie z żoną na ten temat, w tej odpowiedzi tutaj: /software/45464/how-to-convince-non-programmer-his-notions-about- komputery są błędne / 45467 # 45467

EDYCJA: Pytanie, na które odpowiedziałem, zostało usunięte, więc powtórzę tutaj moją odpowiedź.

Siedząc w restauracji z żoną, zapytała mnie „Co oznacza obiekt zorientowany?”

Zacząłem obwieszczać na temat ponownego użycia kodu, enkapsulacji i polimorfizmu, i w pewnym momencie zdałem sobie sprawę, że jej oczy były śmiertelnie oszklone.

Więc wyciągnąłem pakiet Splenda z pojemnika. Powiedziałem: „Oto obiekt. Jakie są jego właściwości?”

Powiedziała: „Jest prostokątna, wykonana z papieru, zawiera splendę, jest niebieska, ma nadruk”.

Wziąłem paczkę cukru. „Co to ma wspólnego z tym?”

Powiedziała: „Prostokątność, papier, że jest druk”.

Powiedziałem: „A co, że oba zawierają coś słodkiego?”

Powiedziała „Jasne”.

Powiedziałem: „Więc są to oba przypadki tego, co moglibyśmy nazwać abstrakcyjnym pakietem słodzika. Jeśli chcesz, to platoniczny idealny pakiet słodzika”.

Powiedziała „Jasne”.

Powiedziałem: „Każdy z nich ma właściwości odziedziczone z pakietu abstrakcyjnego, a następnie odmiany tego, które są specyficzne dla jego rodzaju rzeczy”.

Powiedziała: „Racja. Och! A gdybym chciała zrobić, na przykład, saszetkę, wzięłabym tę ogólną i ustaliłam szczegóły na temat sacharyny, a potem miałabym to!”

Powiedziałem: „Bingo: programowanie obiektowe”.

Ty i ja wiemy, że po prostu intuicyjnie wdrożyła się do wzoru fabrycznego. Cokolwiek. Ilustruje dziedziczenie, hermetyzację, tożsamość klasy obiektu ... Dobre rzeczy.

To pytanie wydaje się być kandydatem do zamknięcia, jednak ...

Jak większość rzeczy, OOP jest w rzeczywistości bardzo proste do wyjaśnienia na poziomie koncepcyjnym. Programiści modelują obiekty; i:

• obiekty mają stan (pola / elementy danych)
• obiekty mają akcje (metody / funkcje)
• obiekty budują się na sobie (dziedziczenie)

Z pewnością są to setki drobniejszych szczegółów. Ale jeśli próbujesz przedstawić komuś 10-sekundowy przegląd, myślę, że to dobry początek. Czy jest więcej szczegółowych pojęć, które trudno ci wyjaśnić?

Przykład telefonu komórkowego:

Wyobraź sobie, że jesteś właścicielem fabryki, chcesz opisać ogólny telefon

• Krok 1: Wymień ogólne właściwości telefonu , np .: wzrost, wagę, kolor itp
• Krok 2: Wymień ogólne funkcje telefonu, np .: nawiąż połączenie, odbierz połączenie, wyślij sms itp

Teraz, gdy masz już swój ogólny „plan”, utwórz mi następujące telefony:

Telefon 1:

• Wysokość-> 102 mm

• Waga-> 85g

• Kolor-> Różowy

Telefon 2:

• Wysokość-> 125 mm

• Waga-> 96g

• Kolor-> Czerwony

Myślę, że najlepszym sposobem na wyjaśnienie nietechnicznemu typowi OOP jest odniesienie go do nich.

Zasadniczo OOD i OOP chcą, abyś pomyślał o systemie, który projektujesz i wdrażasz jako świecie interakcji.

Więc, ze względu na kłótnię (która nigdy nie idzie dobrze w Internecie), powiedzmy, że wyjaśniasz kolektorowi śmieci na temat OOD i P. Nazywa się Bob. Chodziłeś z nim do szkoły 15 lat temu, wpadłeś na niego w barze i oboje udajecie zainteresowanie sobą.

„Więc, John, mówisz, że jesteś programistą. Mój siostrzeniec jest w tym nonsensie. Ciągle chodzi o programowanie obiektowe lub coś w tym rodzaju. O co w tym wszystkim chodzi?” Zauważ, że Bob jest Brytyjczykiem ze względu na sposób, w jaki popełnił błędy pisowni.

„Cóż, Bob”, odpowiadasz, kuląc się zorientowany. „To naprawdę bardzo proste. Zbierasz śmieci, prawda? Co ogólnie robisz w swojej pracy?”

„Cóż, podążam za furgonetką po mieście, zbierając śmieci i wkładając je do furgonetki”, odpowiada pytająco Bob.

i będziesz musiał tego wysłuchać. To są nasze zachowania. To właściwie wszystko, czego potrzebujesz do projektu. Programowanie obiektowe jest zasadniczo sposobem implementacji projektu. Różni się w zależności od języka ”.

Bob zasnął w swoim piwie. Odchodzisz.

Podoba mi się przykład samochodu do wyjaśniania dziedziczenia (zwykle używam zwierząt zamiast pojazdów, ale to ten sam pomysł), ale do wyjaśniania, jak działa program obiektowy, odnoszę się do analogii, którą kiedyś czytałem na stronie Chrisa Crawforda: program jest jak naprawdę skuteczna biurokracja. Wszystkie różne obiekty w programie są jak różne działy biurokracji; każdy dział ma swoje wyznaczone zadania, ma dobrze zdefiniowane dane wejściowe (z kim rozmawiać i jakie formularze do wypełnienia), a inne działy często nie wiedzą zbyt wiele o tym, co dzieje się w środku. HR jest jak abstrakcyjna fabryka, IT to singleton itp.

Otrzymanie komunikatu o błędzie, ponieważ wpisałeś niewłaściwą rzecz w programie komputerowym, dokładnie przypomina wypełnienie złego formularza w celu przesłania go do biura.

OOP jest rażącym uproszczeniem, jeśli w ogóle - abstrakcją - ludzkiego procesu myślowego i zrozumienia świata w celu przekształcenia funkcjonalności w cyfrową „pustkę” w celu cyfrowego naśladowania znanych procesów i klasyfikacji. Pod wieloma względami chodzi bardziej o nasz prymitywny stan języka niż o „myślenie bardziej jak komputery”.

Gdyby programowanie naśladowało rzeczywistość lub ludzką myśl, byłoby to o wiele bardziej organiczne, chaotyczne i przypadkowe z natury - nawet boczne. Zamiast tego upraszczamy rzeczywistość w dziecinne kroki, „logikę 2 + 2”, surowe kategorie, małe narzędzia wielokrotnego użytku i prehistoryczne rozumowanie.

Wciąż próbujemy znaleźć sposób, aby pobrać nasze myśli i pragnienia do protokołu i wspólnego języka, a ja, na przykład, myślę, że historycy będą zafascynowani jego wyrafinowaną niegrzecznością pewnego dnia - tak jak teraz widzimy hieroglify. To wcale nie jest „sprytne” - po prostu podkreśla, że ​​nie możemy łatwo wyjaśnić, w jaki sposób decydujemy lub rozumiemy nawet najprostsze rzeczy. Informatyka wciąż jest na poziomie „pies jest psem, ponieważ nie jest kotem” na poziomie ewolucji myśli - to tysiące lat za nawet podstawowym językiem mówionym.

Istnieją dwa rodzaje czarodziejów. Jest facet, który sprawia, że ​​coś się dzieje z magicznymi słowami. Ma słowo na przywołanie ognia. Ma słowo, które sprawia, że ​​mrożony kurczak pojawia się z powietrza. I jeszcze jedno słowo na określenie garnka siły (wolę swoją siłę, zielonego, błyszczącego i półprzezroczystego) pełnego krzewiastej dobroci. Przy odpowiednim zastosowaniu jego słów może wyprodukować smażonego kurczaka.

A potem jest kreator OOP. Kto przywołuje impa, który wie, jak iść do sklepu spożywczego, kupić kurczaka (lub składniki innego jedzenia, które ma przygotować), ugotować go i podać ci obiad. Kreator OOP nie musi mówić imp, jak to zrobić. Musi tylko powiedzieć mu, czego chce, czyli w tym przypadku smażonego kurczaka. Mało tego, czarodziej OOP może wezwać inne stwory, aby powiedzieć swojemu szefowi kuchni, co ma robić.

Facet inkantacyjny robi wrażenie na przyjęciach, ale kreator OOP jest tym, którego chcesz, gdy zamierzasz otworzyć magiczną restaurację z grupą postaci (np. Wkurzony kelner jednorożca i menedżer podłogi trolli), którzy wszyscy muszę współpracować. Jeśli spróbujesz przywołać każdy krok problemu rozwiązania „restauracji”, możesz łatwo zaplątać się w szczegóły i bardzo łatwo popełnić błędy. Czarnoksiężnik z klasy OOP przygotowuje swoich stworów do uporządkowania szczegółów, aby mógł skupić się na rozwiązaniu większego problemu poprzez interakcję swoich ludzi.

Nie wspominając, że łatwiej jest ponownie użyć swojego szefa kuchni do rozwiązania problemu z kafeterią w szkole podstawowej, to jest oddzielenie wszystkich śmieci, których możesz lub nie możesz ponownie użyć, gdy robisz to wszystko krok po kroku, wywołując słowa i słowa, które wywołują inne zestawy słów (które będą coraz liczniejsze, gdy będziesz musiał poradzić sobie z większą różnorodnością problemów).

Szczerze mówiąc, przy bardzo, bardzo ostrożnej aplikacji, kreator inkantacji może to wszystko zrobić tak szybko, jak kreator OOP. Potrafi rozbić wszystko we właściwy sposób, tak więc wywoływanie odpowiednich zaklęć nie wymaga więcej pracy z jego strony niż kreator OOP. Ale praca jest znacznie trudniejsza do zrozumienia lub powielenia i znacznie trudniejsza do ponownego użycia dużych części, ponieważ wszystko jest powiązane razem dla jednego konkretnego złożonego problemu.