Co więc * naprawdę * Alan Kay miał na myśli, mówiąc „obiektowo”?

95

Podobno Alan Kay jest wynalazcą terminu „obiektowy”. I często jest cytowany, jak powiedział, że to, co dzisiaj nazywamy OO, nie jest tym, co miał na myśli.

Na przykład właśnie znalazłem to w Google:

Stworzyłem termin „obiektowy” i mogę powiedzieć, że nie miałem na myśli C ++

- Alan Kay, OOPSLA '97

Jak przez mgłę pamiętam coś słuchu dość wnikliwe o tym, co on miał na myśli. Coś w stylu „przekazywania wiadomości”.

Czy wiesz co miał na myśli? Czy możesz podać więcej szczegółów na temat tego, co miał na myśli i czym różni się od dzisiejszego wspólnego OO? Proszę podzielić się referencjami, jeśli masz.

Dzięki.

Charlie Flowers
źródło
Moje posty na blogu mogą być interesujące na ten temat: yegor256.com/tag/oop.html
yegor256
Sprawdź sekcję komentarzy w tym wpisie na blogu, na której sam Alan Kay odpowiada na pytania: Alan Kay był w
błędzie

Odpowiedzi:

82

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en


Data: Środa, 23 lipca 2003 09:33:31 -0800 Do: Stefan Ram [usunięty ze względu na prywatność] Od: Alan Kay [usunięty ze względu na prywatność] Temat: Re: Wyjaśnienie „obiektowego”

Cześć Stefan -

Przepraszam za opóźnienie, ale byłem na wakacjach.

O 18:27 +0200 7/17/03 Stefan Ram napisał:

Drogi Dr. Kay,

Chciałbym uzyskać wiarygodne słowo na temat „programowania obiektowego” na mojej stronie z samouczkiem na ten temat. Jedynymi dwoma źródłami, które uważam za „autorytatywne”, są Międzynarodowa Organizacja Normalizacyjna, która definiuje „zorientowany obiektowo” w „ISO / IEC 2382-15” oraz Ty, ponieważ, jak to mówią, ukułeś ten termin.

Jestem pewien, że tak.

Niestety trudno jest znaleźć stronę internetową lub źródło z definicją lub opisem tego terminu. Istnieje kilka raportów na temat tego, co mogłeś powiedzieć w tym względzie (np. „Dziedziczenie, polimorfizm i enkapsulacja”), ale nie są to źródła z pierwszej ręki. Wiem również, że później kładziecie większy nacisk na „przesyłanie wiadomości” - ale nadal chciałbym wiedzieć o „obiektowym”.

Jeśli chodzi o zapisy, moją stronę z samouczkami oraz dalszą dystrybucję i publikację, proszę wyjaśnić:

Kiedy i gdzie najpierw użyto terminu „obiektowy”?

W Utah, jakiś czas po 66 listopada, kiedy pod wpływem Sketchpada, Simuli, projektu ARPAnet, Burroughs B5000 i mojego doświadczenia w biologii i matematyce, pomyślałem o architekturze programowania. Prawdopodobnie w 1967 roku ktoś zapytał mnie, co robię, a ja powiedziałem: „Programowanie obiektowe”.

Jego pierwotna koncepcja składała się z następujących części.

  • Pomyślałem o obiektach będących komórkami biologicznymi i / lub pojedynczymi komputerami w sieci, które mogą komunikować się tylko z wiadomościami (więc wysyłanie wiadomości pojawiło się na samym początku - zajęło trochę czasu, aby zobaczyć, jak robić wiadomości w języku programowania wystarczająco wydajnym, aby być użytecznym).

  • Chciałem pozbyć się danych. B5000 prawie to zrobił dzięki prawie niewiarygodnej architekturze sprzętu. Uświadomiłem sobie, że metafora komórka / cały komputer pozbyłaby się danych, a „<-” byłoby tylko kolejnym tokenem wiadomości (zajęło mi to sporo czasu, aby to przemyśleć, ponieważ tak naprawdę myślałem o tych wszystkich symbolach jako nazwach funkcje i procedury.

  • Moje pochodzenie matematyczne uświadomiło mi, że z każdym obiektem może być powiązanych kilka algebr, a mogą istnieć ich rodziny i że będą one bardzo, bardzo przydatne. Termin „polimorfizm” został narzucony znacznie później (myślę, że Peter Wegner) i nie jest całkiem poprawny, ponieważ tak naprawdę pochodzi z nomenklatury funkcji, a ja chciałem czegoś więcej niż funkcji. Stworzyłem termin „ogólność” do radzenia sobie z rodzajowymi zachowaniami w formie quasi-algebraicznej.

  • Nie podobało mi się to, że Simula I lub Simula 67 dziedziczyły (chociaż myślałem, że Nygaard i Dahl byli po prostu wspaniałymi myślicielami i projektantami). Postanowiłem więc pominąć dziedziczenie jako funkcję wbudowaną, dopóki nie zrozumiałem go lepiej.

Moje oryginalne eksperymenty z tą architekturą zostały wykonane przy użyciu modelu, który zaadaptowałem z „Generalizacji Algolu” van Wijngaarten i Wirtha oraz Eulera Wirtha. Oba były raczej podobne do LISP, ale miały bardziej konwencjonalną czytelną składnię. Nie rozumiałem wtedy potwornego pomysłu LISP na namacalny metaljęzyk, ale zbliżyłem się do pomysłów na temat języków rozszerzalnych czerpanych z różnych źródeł, w tym IMP Ironsa.

Drugim etapem tego było zrozumienie LISP, a następnie wykorzystanie tego zrozumienia do stworzenia znacznie ładniejszych i mniejszych oraz mocniejszych i opóźnionych konstrukcji podziemnych. Teza Dave'a Fishera została wykonana w stylu „McCarthy'ego”, a jego pomysły dotyczące rozszerzalnych struktur kontrolnych były bardzo pomocne. Innym dużym wpływem w tym czasie był PLANER Carla Hewitta (który nigdy nie zyskał uznania, na jakie zasługuje, biorąc pod uwagę, jak dobrze i jak wcześniej mógł przewidzieć Prolog).

Oryginalny Smalltalk w Xerox PARC wyszedł z powyższego. Na kolejnych Smalltalk narzekano pod koniec rozdziału Historia: cofnęli się w kierunku Simuli i nie zastąpili mechanizmów rozszerzenia bezpieczniejszymi, które były prawie tak przydatne.

Co oznacza dla Ciebie „programowanie obiektowe”? (Nie jest potrzebne wprowadzenie przypominające samouczek, wystarczy krótkie wyjaśnienie [jak „programowanie z dziedziczeniem, polimorfizmem i enkapsulacją”] w kategoriach innych pojęć dla czytelnika znającego je, jeśli to możliwe. Ponadto nie jest konieczne wyjaśnianie „obiektu ”, ponieważ mam już źródła z wyjaśnieniem„ obiektu ”z„ Early History of Smalltalk ”).

(Nie jestem przeciw typom, ale nie znam żadnych systemów typów, które nie są kompletnym bólem, więc nadal lubię dynamiczne pisanie.)

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

[Także] Jedną z rzeczy, o których powinienem wspomnieć, jest to, że istniały dwie główne ścieżki, które były katalizowane przez Simulę. Wczesna (przypadkowo) była drogą, którą wybrałem metodą bio / net bez procedury danych. Drugim, który pojawił się nieco później jako przedmiot badań, były abstrakcyjne typy danych, co znacznie się poprawiło.

Jeśli spojrzymy na całą historię, zobaczymy, że proto-OOP zaczęło się od ADT, miał mały rozwidlenie w kierunku tego, co nazwałem „obiektami” - co doprowadziło do Smalltalk itp. - - ale po małym rozwidleniu Zakładanie CS prawie zrobiło ADT i chciało trzymać się paradygmatu procedury danych. Historycznie warto przyjrzeć się systemowi plików USAF Burroughs 220 (który opisałem w historii Smalltalk), wczesnej pracy Douga Rossa z MIT (AED i wcześniejszych), w której zalecał osadzanie wskaźników procedur w strukturach danych, Sketchpad (który miał pełny polimorfizm - gdzie np. to samo przesunięcie w jego strukturze danych oznaczało „wyświetlanie” i byłby wskaźnik do odpowiedniej procedury dla typu obiektu reprezentowanego przez strukturę itp. oraz Burroughsa B5000, których tabele odwołań do programu były prawdziwymi „dużymi obiektami” i zawierały wskaźniki zarówno do „danych”, jak i „procedur”, ale często mogły zrobić coś dobrego, jeśli próbowały szukać danych i znalazły wskaźnik procedury. A pierwszymi problemami, które rozwiązałem we wczesnych latach w Utah, były „znikanie danych” przy użyciu tylko metod i obiektów. Pod koniec lat 60. (chyba) Bob Balzer napisał całkiem sprytny artykuł o nazwie „Programowanie bez danych”, a wkrótce potem John Reynolds napisał równie sprytny artykuł „Gedanken” (myślę, że w 1970 roku), w którym pokazał, że używając lamdy wyrażenia we właściwy sposób umożliwiłyby wyodrębnienie danych za pomocą procedur. ale często może zrobić coś dobrego, jeśli próbuje podążać za danymi i znaleźć wskaźnik procedury. A pierwszymi problemami, które rozwiązałem we wczesnych latach w Utah, były „znikanie danych” przy użyciu tylko metod i obiektów. Pod koniec lat 60. (chyba) Bob Balzer napisał całkiem sprytny artykuł o nazwie „Programowanie bez danych”, a wkrótce potem John Reynolds napisał równie sprytny artykuł „Gedanken” (myślę, że w 1970 roku), w którym pokazał, że używając lamdy wyrażenia we właściwy sposób umożliwiłyby wyodrębnienie danych za pomocą procedur. ale często może zrobić coś dobrego, jeśli próbuje podążać za danymi i znaleźć wskaźnik procedury. A pierwszymi problemami, które rozwiązałem we wczesnych latach w Utah, były „znikanie danych” przy użyciu tylko metod i obiektów. Pod koniec lat 60. (chyba) Bob Balzer napisał całkiem sprytny artykuł o nazwie „Programowanie bez danych”, a wkrótce potem John Reynolds napisał równie sprytny artykuł „Gedanken” (myślę, że w 1970 roku), w którym pokazał, że używając lamdy wyrażenia we właściwy sposób umożliwiłyby wyodrębnienie danych za pomocą procedur.

Ludzi, którzy lubili obiekty jako nie-dane, było mniej i obejmowali mnie, Carla Hewitta, Dave'a Reeda i kilku innych - prawie cała ta grupa pochodziła ze społeczności ARPA i w ten czy inny sposób była zaangażowana w projekt ARPAnet → Internet, w którym podstawową jednostką obliczeniową był cały komputer. Ale żeby pokazać, jak uparcie pomysł może się utrzymać, przez lata siedemdziesiąte i osiemdziesiąte, wielu ludzi próbowało przetrwać dzięki „zdalnemu wywoływaniu procedury” zamiast myśleć o przedmiotach i komunikatach. Sic tranzyt gloria mundi.

Twoje zdrowie,

Alan Kay

Manoj
źródło
1
Odmowa dostępu HTTP / 1.1 403.
Job
1
Byłem w stanie uzyskać do niego dostęp, więc musiał to być przejściowy problem. Dzięki za ten link, Manoj.
David Conrad
2
@ Job środa (16 marca, dzień, w którym najwyraźniej wystąpił błąd 403) to miesięczny dzień usługi administratora domeny pod adresem userpage.fu-berlin.de). Raz w miesiącu rutynowo wyłączają części sieci offline. Uh, tak, nie pytaj…
Konrad Rudolph
Czy możesz / ktoś wyjaśnić, co oznacza „chciałem pozbyć się danych”? Dane są integralną częścią OO (tj. Często są enkapsulowane w klasie lub przekazywane do / z klas), i bez względu na zastosowany paradygmat, nie można obejść się bez danych w obliczeniach, więc pozbycie się danych nie ma dla mnie sensu .
Dennis
1
<- był pierwotnym operatorem przypisania
smalltalk
22

Większość, jeśli nie wszystko, co Alan Kay rozumiał przez orientację obiektową, zawarte jest w języku Smalltalk.

Ponadto z http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay argumentował, że przekazywanie wiadomości jest ważniejsze niż obiekty w OOP i że same obiekty są często nadmiernie podkreślane. Model programowania obiektów rozproszonych na żywo opiera się na tej obserwacji; wykorzystuje koncepcję rozproszonego przepływu danych, aby scharakteryzować zachowanie złożonego systemu rozproszonego pod względem wzorców komunikatów, przy użyciu specyfikacji wysokiego poziomu, funkcjonalnych.
Mark Cidade
źródło
18
Następnie zastanawia się, dlaczego nazwał to „zorientowanym obiektowo”, a nie „zorientowanym na wiadomości”.
David Thornley,
@David Thornley: Czyli to zorientowałoby się na metodę C ++?
back2dos
60
W latach 60. byłem zbyt pochopny z tym terminem i powinienem był wybrać coś w rodzaju „zorientowanego na wiadomości”
Alan Kay
1
Ale czym zatem jest „zorientowanie na wiadomości”? (Mogę myśleć o wywołaniach asynchronicznych (być może), ale tak naprawdę nie znam żadnego języka, który nie implementuje mniej lub bardziej „normalnych” metod; jest też pewna wartość zwracanych wartości, ale można to oszukać za pomocą sortowania „ parametry „ref” / „out” lub coś w tym rodzaju)
mlvljr,
1
„zorientowany na komunikat” jest zasadniczo późnym wiązaniem / dynamicznym typowaniem - wiadomość przekazywana do obiektu jest analizowana (przez ten obiekt) w czasie wykonywania.
Mark Cidade,
6

Większość, jeśli nie wszystko, co Alan Kay rozumiał przez orientację obiektową, zawarte jest w języku Smalltalk.

„Nie zrealizowaliśmy nawet całego pomysłu w PARC. Wiele pomysłów aktorskich Carla Hewitta, które zostały zainspirowane oryginalnym Smalltalk, były bardziej w duchu OOP niż kolejne Smalltalks. Znaczące części Erlang są bardziej jak prawdziwy język OOP obecny Smalltalk, a na pewno języki oparte na C, które zostały namalowane „farbą OOP”. ”

Zaczerpnięte z komentarza Alana Kaya na:

http://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/

Thiago Silva
źródło
Musisz przewinąć długą drogę w dół komentarzy, tutaj jest bezpośredni link do komentarza Alana Kaya: computinged.wordpress.com/2010/09/11/…
icc97
Ten cały komentarz jest bardzo przydatny, zaczyna się od potencjalnej odpowiedzi na to pytanie: „Dobry przykład dużego systemu, który uważam za„ obiektowy ”, to Internet. Ma miliardy całkowicie zamkniętych obiektów (same komputery) i używa czysty system komunikacyjny „żądań, a nie poleceń” itp. ”
icc97
5

Jednym z głównych punktów, które podniosłem na podstawie prac Alana Kay i innych, takich jak Jim Coplien, jest to, że prawdziwe programowanie zorientowane obiektowo polega na modelowaniu komputerów i oprogramowania w kategoriach modeli mentalnych LUDZKIEGO / UŻYTKOWNIKA, a nie byciu tylko narzędzie dla PROGRAMATORÓW.

Jak rozumiem, wizja OOP firmy Alan polegała na tym, aby komputer był narzędziem, które pozwala użytkownikom tworzyć, co chcą: pełne możliwości komputera są bezpośrednio udostępniane użytkownikowi końcowemu za pomocą intuicyjnego modelu interaktywnego. Powinienem być w stanie wyświetlać i rzeźbić obiekty wykonawcze i interakcje BEZPOŚREDNIO, nie tylko za pomocą kodu.

Oto post o moich planach wypróbowania jakiejś wersji tego kodu w JavaScript jako dowodu koncepcji: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

Z perspektywy rozwoju / programowania oprogramowania, Jim Coplien mówi o tym, jak kod może i POWINIEN przypominać jego mentalny model. Oznacza to, że kod czyta się tak samo, jak brzmiałaby osoba opisująca swoje zachowanie. Jest to w dużej mierze osiągnięte poprzez myślenie w kategoriach OBIEKTÓW, a nie w kategoriach KLAS i RODZAJÓW. Zachowanie jest opisane w kategoriach ROL odgrywanych przez obiekty, a nie w ramach definicji TOŻSAMOŚCI obiektu. Powinieneś być w stanie modelować interakcje na podstawie obiektów, które są identyfikowane przez ROLĘ, jaką odgrywają w interakcji. Oto jak działają ludzkie modele mentalne: kelner, klient, kasjer, konto źródłowe, konto docelowe ... Są to ROLE, a nie TYPY, a Ty chcesz mieć możliwość zdefiniowania metod dla „dowolnego obiektu pełniącego tę rolę w tym czasie „,

użytkownik1270393
źródło
DDD stosuje podobne koncepcje. Prawdopodobnie masz rację. :-)
inf3rno