it-swarm-eu.dev

Co tedy měl Alan Kay na mysli pod pojmem „objektově orientovaný“?

Alan Kay je údajně vynálezcem pojmu „objektově orientovaný“. A on je často citován, že řekl, že to, čemu říkáme OO dnes není to, co tím myslel).

Například jsem to na Googlu našel:

Vymyslel jsem termín „objektově orientovaný“ a mohu vám říci, že jsem neměl na mysli C++

- Alan Kay, OOPSLA '97

Nejasně si vzpomínám, že jsem slyšel něco docela bystrého o tom, co znamenal dělal. Něco v řádcích „předávání zpráv“.

Víš, co tím myslel? Můžete vyplnit více podrobností o tom, co tím myslel a jak se liší od dnešního společného OO? Prosím, sdílejte nějaké reference, pokud máte nějaké.

Dík.

104
Charlie Flowers

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


Datum: St, 23. července 2003 09:33:31 -0800 Komu: Stefan Ram [odstraněn pro soukromí] Od: Alan Kay [odstraněn pro soukromí] Předmět: Re: Objasnění „objektově orientovaného“

Ahoj Stefan -

Omlouváme se za zpoždění, ale byl jsem na dovolené.

V 6:27 PM +0200 7/17/03, Stefan Ram napsal:

Vážený doktore Kay,

Chtěl bych mít nějaké autoritativní slovo o termínu „objektově orientované programování“ pro svou stránku s tutoriálem na toto téma. Jediné dva zdroje, které považuji za „autoritativní“, jsou Mezinárodní organizace pro normalizaci, která definuje „objektově orientované“ v „ISO/IEC 2382-15“, a vy, protože, jak se říká, jste tento termín vytvořili.

Jsem si jistý, že jsem to udělal.

Bohužel je obtížné najít webovou stránku nebo zdroj s vaší definicí nebo popisem tohoto termínu. Existuje několik zpráv o tom, co jste v tomto ohledu mohli říci (jako „dědičnost, polymorfismus a zapouzdření“), ale nejde o zdroje z první ruky. Jsem si také vědom toho, že později kladete větší důraz na „zasílání zpráv“ - ale stále bych chtěl vědět o „objektově orientovaném“.

Pro záznamy, mou stránku s tutoriály a další distribuci a publikaci byste mohli prosím vysvětlit:

Kdy a kde byl poprvé použit termín „objektově orientovaný“?

V Utahu někdy po 66. listopadu, kdy jsem ovlivnil Sketchpad, Simula, design pro ARPAnet, Burroughs B5000 a moje zázemí v biologii a matematice, myslel jsem na architekturu pro programování. Bylo to pravděpodobně v roce 1967, když se mě někdo zeptal, co dělám, a řekl jsem: „Je to objektově orientované programování“.

Původní koncepce měla následující části.

  • Myslel jsem, že objekty jsou jako biologické buňky a/nebo jednotlivé počítače v síti, schopné komunikovat pouze se zprávami (takže zasílání zpráv přišlo na samém začátku - chvíli trvalo, než jsem viděl, jak posílat zprávy v programovacím jazyce dostatečně účinně, aby být užitečný).

  • Chtěl jsem se zbavit dat. B5000 to téměř dosáhlo díky téměř neuvěřitelné HW architektuře. Uvědomil jsem si, že metafora buněk/celých počítačů se zbaví dat, a že „<-“ by byl jen dalším tokenem zprávy (trvalo mi chvilku, než jsem si to vymyslel, protože jsem opravdu myslel na všechny tyto symboly jako na názvy pro funkce a postupy.

  • Moje matematické pozadí mě přimělo uvědomit si, že s každým objektem může být spojeno několik algebras, a mohou existovat jejich rodiny, které by byly velmi užitečné. Termín „polymorfismus“ byl zaveden mnohem později (myslím Peterem Wegnerem) a není zcela platný, protože ve skutečnosti pochází z nomenklatury funkcí a chtěl jsem trochu víc než funkce. Vymyslel jsem termín „obecnost“ pro řešení druhových chování v kvazi-algebraické podobě.

  • Nelíbilo se mi, jak dělaly dědictví Simula I nebo Simula 67 (i když jsem si myslel, že Nygaard a Dahl byli prostě ohromní myslitelé a návrháři). Takže jsem se rozhodl vynechat dědičnost jako vestavěný prvek, dokud jsem tomu nerozuměl lépe.

Moje původní experimenty s touto architekturou byly provedeny za použití modelu, který jsem upravil z „Generalizace ALGOL“ a Wirthova Eulera z Van Wijngaarten a Wirth. Oba byli spíše LISP, ale s konvenčnější čitelnou syntaxí. Tehdy jsem nerozuměl představě monstrum LISP o hmatatelném metajazyku, ale dostal jsem trochu blízko k představám o rozšiřitelných jazycích čerpaných z různých zdrojů, včetně Ironsovy IMP.

Druhou fází bylo nakonec pochopit LISP a poté pomocí tohoto porozumění učinit mnohem hezčí a menší a silnější a pozdější vazby. Dave Fisherova práce byla zpracována ve stylu „McCarthy“ a jeho představy o rozšiřitelných řídících strukturách byly velmi užitečné. Dalším velkým vlivem v této době byl PLANNER Carla Hewitta (který nikdy nezískal uznání, které si zaslouží, vzhledem k tomu, jak dobře a jak dříve dokázal Prolog předvídat).

Původní Smalltalk v Xerox PARC vyšel z výše uvedeného. Následující Smalltalk's si stěžují na konci kapitoly Historie: ustupují směrem k Simule a nenahrazují prodlužovací mechanismy bezpečnějšími, které byly kdekoli poblíž tak užitečné.

Co pro vás znamená „objektově orientované programování“? (Není třeba úvodní tutoriál, pouze krátké vysvětlení [jako je "programování s dědičností, polymorfismus a enkapsulace"), pokud jde o další pojmy, které čtenář s nimi obeznámil, pokud je to možné. Není také nutné vysvětlit "objekt" “, protože už mám zdroje s vaším vysvětlením„ objektu “z„ Early History of Smalltalk “.)

(Nejsem proti typům, ale nevím o žádných typových systémech, které nejsou úplné bolesti, takže stále mám ráda dynamické psaní.)

OOP pro mě znamená pouze zasílání zpráv, lokální retenci a ochranu a skrytí státního procesu a extrémní zpoždění všech věcí. Lze to provést v Smalltalk a LISP. Jsou možná i jiné systémy, ve kterých je to možné, ale nevím o nich.

[Také] Jedna z věcí, které jsem měl zmínit, je to, že existovaly dvě hlavní cesty, které katalyzovala Simula. Prvním (jen náhodou) byla cesta bez postupu k bio/netu, kterou jsem použil. Druhý, který přišel o něco později jako předmět studia, byly abstraktní datové typy, a to se stalo mnohem více hrou.

Podíváme-li se na celou historii, vidíme, že proto-OOP věci začaly ADT, měly malou vidličku k tomu, čemu jsem říkal „objekty“ - to vedlo k Smalltalk atd. - ale po malé vidličce Zřízení CS do značné míry provedlo ADT a chtělo se držet paradigmatu postupu při zpracování dat. Historicky stojí za to se podívat na souborový systém USAF Burroughs 220 (který jsem popsal v historii Smalltalk), ranou práci Douga Rossa na MIT (AED a dřívější)), v níž obhajoval proceduru vkládání ukazatele v datových strukturách, Sketchpad (který měl plný polymorfismus - kde např. stejný offset ve své datové struktuře znamenal „zobrazení“ a tam by byl ukazatel na příslušnou rutinu pro typ objektu, který struktura představovala, atd., a Burroughs B5000, jehož referenční tabulky programu byly pravdivé „velké objekty“ a obsahovaly ukazatele jak na „data“, tak na „procedury“, ale často dokázal udělat správnou věc, pokud se pokoušel jít za daty a našel ukazatel procedur. A úplně první problémy, které jsem vyřešil s mým ranním Utahem, bylo „mizení dat“ pomocí pouze metod a objektů. Na konci 60. let (myslím) Bob Balzer napsal pěkně šikovný dokument s názvem „Dataless Programming“ a krátce nato napsal John Reynolds stejně šikovný papír "Gede." anken “(myslím v roce 1970), ve kterém ukázal, že použití lamdových výrazů správným způsobem by umožnilo abstrakci dat procedurami.

Počet lidí, kteří měli rádi objekty jako ne-data, byl menší, a zahrnovali mě, Carla Hewitta, Dave Reeda a několik dalších - skoro celá tato skupina byla z komunity ARPA a tak či onak se podíleli na návrhu ARPAnet → Internet, ve kterém základní výpočetní jednotkou byl celý počítač. Ale jen abych ukázal, jak tvrdohlavě může nápad zůstat, po sedmdesátých a osmdesátých letech bylo mnoho lidí, kteří pokusil se obejít pomocí "Remote Procedure Call" místo přemýšlení o objektech a zprávách. Sic tranzitní gloria mundi.

Na zdraví,

Alan Kay

90
Manoj

Většina, ne-li všechno, co Alan Kay myslel objektovou orientací , je ztělesněna v jazyce Smalltalk.

Také od http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

Alan Kay tvrdil, že předávání zpráv je důležitější než objekty v OOP a že samotné objekty jsou často příliš zdůrazněny. Programovací model živých distribuovaných objektů staví na tomto pozorování; používá koncept distribuovaného toku dat k charakterizaci chování komplexního distribuovaného systému, pokud jde o vzory zpráv, za použití specifikací na vysoké úrovni, funkčního stylu.
23
Mark Cidade

Většina, ne-li všechno, co Alan Kay myslel objektovou orientací, je ztělesněna v jazyce Smalltalk.

„V PARC jsme vůbec nenaplnili všechny myšlenky. Mnoho nápadů herců Carla Hewitta, které vyvolaly původní Smalltalk, bylo více v duchu OOP než následných Smalltalks.) Významné části of Erlang jsou spíš jako skutečný OOP současný Smalltalk a určitě jazyky založené na C, které byly vymalovány „OOP Paint“.)

Převzato z komentáře Alan Kay na:

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

6
Thiago Silva

Jedním z hlavních bodů, které jsem si všiml při sledování prací Alana Kaye a dalších, jako je Jim Coplien, je to, že skutečné „objektové“ programování je o modelování počítačů a softwaru, pokud jde o mentální modely HUMAN/USER, než abych byl jen nástroj pro programátory.

Jak to chápu, Alanova vize OOP) dělala z počítače nástroj, který umožňuje lidskému uživateli dělat, co chtějí: veškeré možnosti počítače jsou přímo vystaveny koncovému uživateli prostřednictvím intuitivní interaktivní model. Měl bych být schopen prohlížet a vyřezávat runtime objekty a interakce PŘÍMO, nejen prostřednictvím kódu.

Zde je příspěvek o mých plánech pokusit se o nějakou verzi tohoto v JavaScriptu jako důkaz konceptu: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

Z pohledu vývoje/programování softwaru Jim Coplien hovoří o tom, jak kód může a Měl by se podobat mentálnímu modelu uživatele. To znamená, že kód čte téměř stejným způsobem, jak by to znělo osobou popisující jeho chování. Toho je do značné míry dosaženo přemýšlením, pokud jde o OBJEKTY, spíše než z hlediska TŘÍD a TYPŮ. Chování je popsáno na základě ROLŮ, které hrají objekty, nikoli jako součást definice IDENTITY objektu. Měli byste být schopni modelovat interakce na základě objektů, které jsou identifikovány rolí, kterou hrají v interakci. Takto fungují lidské mentální modely: Číšník, Zákazník, Pokladník, Zdrojový účet, Cílový účet, ... Toto jsou ROLE, NE TYPY, a chcete definovat metody pro „jakýkoli objekt v tuto chvíli hraje tuto roli ", protože toto chování je součástí systémové interakce mezi mnoha měnícími se objekty, spíše než součástí definice některého TYPE.

6
user1270393