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

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.

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

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.

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/

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 „,