결국 객체 지향의 정의는 무엇입니까?

소개

객체 지향 패러다임은 확실히 프로그래밍에서 가장 관련성이 높은 주제 중 하나이며 SOLID, GoF 디자인 패턴 또는 객체 교정과 같은 업계의 여러 모범 사례는 물론 Java와 같이 매우 널리 사용되는 언어에서도 발견됩니다. , C#, Ruby, PHP, JavaScript 등 그리고 그러한 관련성을 고려할 때 온라인 토론은 물론 학계 자체에서도 여러 논쟁의 주제이기도 합니다.

패러다임을 둘러싼 주요 논쟁 중 하나는 객체 지향이 실제로 무엇인가 하는 것입니다. 그것이 의미하는 바에 대해 아무도 동의하지 않기 때문에, 이것은 다양한 유형의 인터넷 싸움에서 문제의 핵심입니다. 예를 들어 누군가는 자신의 언어가 실제로 객체 지향적이지만 다른 사람은 그렇지 않다고 주장하거나 특정 언어가 실제로 객체 지향적이지 않다고 주장하는 경우가 있습니다. 지향 등

얼핏 보면 어리석은 것처럼 보일 수도 있지만, 여기에는 숨겨진 문제가 있습니다. 즉, 객체 지향이 무엇인지에 대한 공식적인 정의가 실제로 없다는 사실입니다. 그러므로 패러다임과 관련된 어떤 것을 비판할 때, 진실이 실제로 무엇인지는 아무도 모르기 때문에 그것이 공정한지 아닌지를 실제로 확신할 수 없습니다. 이는 양측이 서로를 비난할 수 있는 논쟁으로만 이어질 것이기 때문입니다. 자신이 토론하고 있는 내용의 정의에 동의하지 않기 때문에 허수아비를 공격하여 같은 것을 이야기하려고 생각하면서 다른 것을 이야기하게 됩니다.

이는 Boehm-Jacopini 정리와 유해하다고 간주되는 Go-to 진술에서 발생하는 구조적/절차적 패러다임과 같은 논의의 주요 소스로 식별할 수 있는 공식적인 기반에서 발생하지 않기 때문에 발생합니다. 또는 람다 미적분학에서 탄생한 함수형에서 반대로 기술적으로 두 가지 다른 기원을 가지고 있어 일을 매우 어렵게 만들고 결국 어느 것이 최초의 객체 지향 언어였는지 말하기조차 어렵습니다. 시뮬라 또는 스몰토크.

이 주제에 대한 사전 접촉이 없다면 제가 여기서 설명하는 모든 것이 조금 이상하다고 느낄 수도 있습니다. 결국 우리 모두는 객체 지향에 대해 배우고 매일 의사소통을 위해 단어를 사용하며 모든 것이 정상적으로 진행되는 것 같습니다. , 소통에 소음이 없겠죠?

인터넷의 일반적인 튜토리얼, Wikipedia 등 다양한 소스를 보거나 정규 교육(예: 기술 과정 또는 대학)을 거치더라도 매우 쉽다고 생각할 수도 있습니다. 우리는 내가 부르는 것과 매우 유사한 정의를 찾을 것입니다: 객체 지향의 4가지 기둥:

• 추상화;
• 캡슐화;
• 상속;
• 다형성.

그러나 이는 사실 이야기의 일부일 뿐입니다. 앞서 지적했듯이 객체 지향 사고에는 실제로 두 가지 서로 다른 학파가 있기 때문입니다. 하나는 Simula에서 만들어진 전통에서 성장하고 C++로 개발 및 대중화된 것입니다. 스몰토크의 전통 속에서 성장한 또 하나의 제품입니다.

C++의 전통에서 역사의 승리하는 측면을 받아들일 수 있다고 하더라도(현재 OO로 간주되는 대다수의 언어가 Smalltalk의 아이디어보다 C++의 아이디어를 더 많이 따르기 때문에), 즉 4개의 기둥이 정확히 이 4개인지 아니면 실제로 4개여야 하는지에 대한 합의가 없습니다. 예:

• C++ 언어 창시자는 3가지 기둥(추상화, 상속, 다형성)만 있는 정의를 직접 고려합니다.
• Eiffel 언어는 또 다른 6가지 원칙(클래스, 어설션, 일반성, 상속, 다형성 및 동적 바인딩)을 고려합니다.
• Smalltalk 언어의 창시자는 자신이 이 용어를 만들 때 의미한 바가 현재 우리가 사용하는 것과 전혀 다르다고 말하며 실제로는 3가지 원칙(메시지 전달, 캡슐화, 모든 언어의 Extreme Late 바인딩)으로 귀결된다고 설명합니다. 것들);
• Ada 언어는 3가지 원칙(캡슐화, 상속, 다형성)만 정의합니다.
• Self 언어는 다른 이름이 있음에도 불구하고 다른 정의(상속, 필드 및 메시지 교환)에서 사용되는 용어와 동일한 3가지 아이디어(프로토타입, 슬롯 및 동작)를 기반으로 합니다.
• Java 언어는 5가지 개념(캡슐화, 필드, 상속, 메소드, 객체)을 정의합니다.
• C# 언어는 4가지 원칙을 따릅니다.
• 시뮬라 언어의 창시자는 구체적인 정의가 없다는 점을 인정하지만, 객체 지향으로 간주되는 언어(객체, 클래스, 상속, 다형성)에 공통적이라고 생각하는 몇 가지 개념을 인용합니다.
• Python 언어는 객체지향이라는 4가지 개념(클래스, 객체, 상속, 다형성)을 인용합니다.
• Ruby 언어는 Smalltalk 정의를 따르며 모든 것이 객체여야 한다는 아이디어와 메시지 교환을 크게 강조합니다.
• PHP 언어에는 객체지향에 대한 공식적인 정의가 없지만 객체지향으로 제시하는 기능을 기반으로 4가지 원칙을 따른다는 것을 추론할 수 있습니다.
• Objective-C 언어에는 객체 지향에 대한 공식적인 정의가 없지만 해당 매뉴얼에서는 다음과 같은 개념의 조합을 제안합니다(모든 것은 객체, 클래스, 메시지 전달, 캡슐화, 상속 및 다형성).
• MDN 웹사이트의 JavaScript 언어 섹션에서는 3가지 개념(클래스와 객체, 상속과 캡슐화)을 고려합니다.
• Object-Oriented Analysis and Design With Application이라는 책의 저자인 Grady Booch는 7가지 원칙(추상화, 캡슐화, 모듈성, 계층 구조, 입력, 동시성 및 지속성)을 정의합니다.
• GoF(Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson 및 John Vlissides)는 자신의 저서 Design Patterns: Elements of Reusable Object-Oriented Software에서 캡슐화, 상속 및 다형성을 절차상의 "디자인 패턴"으로 인용합니다. 언어;
• Peter Van Roy는 자신의 저서 Concepts, Techiniques, and Models of Computer 프로그래밍에서 OO를 4가지 항목(추상 메커니즘, 명시적 상태, 다형성 및 상속과 같은 객체)으로 설명합니다.
• 공식 정의에 가장 가까운 ISO/IEC 2382 항목 2122503은 6가지 원칙(추상화, 캡슐화, 상속, 다형성, 메시지 교환 및 동적 바인딩)을 고려합니다.
• Yegor Bugayenko는 EOLANG 언어로 구현된 phi-calculus라는 자신이 만든 공식 모델을 통해 이를 정의합니다.
• 등...

관점 정의

이런 방식으로 Bjarne Stroustrup(C++ 창시자)이 객체 지향 정의에서 주장한 것처럼:

'객체 지향'에 대한 모든 정의는 역사적으로 수용 가능해야 합니다. 단어는 의사소통에만 유용하며, 우리가 그 의미에 동의하는 경우에만 의미가 있습니다.

~ Bjarne Stroustrup, 영어로 무료 번역됨

그래서 저는 전체론적 접근 방식(부분의 소리가 아닌 전체를 분석하는 것)을 채택하여 제가 정의할 때 고려해야 할 사항을 분석하고 싶습니다. 여기서는 중요도 순으로 4가지 기준에 따라 평가하겠습니다.

1. 정의된 관점에 따른 개념적 정렬
2. 역사적 관련성
3. 실제 구현(상식 인식으로도 간주됨)
4. OO에 대한 독점성(개념이 X 또는 Y 패러다임이나 보다 일반적인 개념이 아닌 객체 지향적인 것으로 식별될 수 있는 정도)

역사의 출발점을 정의하는 것부터 시작하겠습니다. 먼저 어느 쪽을 기본 소스로 선택할지 결정한 다음 정의의 기초로 작성자가 객체 지향이 무엇을 의미해야 하는지에 대한 의도를 따릅니다. 또한 어떤 원칙 세트가 그 안에 포함되는지 판단하기 위한 비교 매개변수로 사용할 수도 있습니다.

이 질문에 대해 저는 Alan Kay가 "객체 지향"을 발명했지만 "객체"는 발명하지 않았다는 견해를 좋아합니다. 따라서 객체 지향이 무엇이어야 하는지에 대한 그의 견해가 우리의 기초가 될 것입니다. 이를 몇 가지 인용문으로 요약할 수 있습니다.

저는 지난 OOPSLA에서 스몰토크가 단순한 구문이나 클래스 라이브러리도 아니고 클래스에 관한 것도 아니라는 점을 모든 사람에게 상기시키기 위해 열심히 일했다는 점을 부드럽게 상기시켜 드립니다. 이 주제에 대해 오래 전에 '물체'라는 용어를 만든 것을 후회합니다. 왜냐하면 많은 사람들이 더 작은 아이디어에 집중하게 만들기 때문입니다.

큰 아이디어는 "메시징"입니다. 이것이 바로 Smalltalk/Squeak의 핵심입니다...

~ Alan Kay, 영어를 무료 번역으로 각색

저는 메시지를 통해서만 통신할 수 있는 네트워크상의 생물학적 세포 및/또는 개별 컴퓨터와 같은 개체를 생각했습니다(그래서 메시지가 일찍 나왔습니다. 프로그래밍 언어로 메시지를 효율적으로 보내는 방법을 알아보는 데 시간이 걸렸습니다). 유용함).

데이터를 없애고 싶었어요. B5000은 거의 믿을 수 없을 만큼 뛰어난 HW 아키텍처를 통해 이를 거의 수행했습니다. 나는 전체 셀/컴퓨터 비유가 데이터를 제거할 것이며 "<-"는 단지 또 다른 메시지 토큰일 뿐이라는 것을 깨달았습니다. 절차 .

저는 수학에 대한 배경 지식을 통해 모든 물체가 그와 연관된 여러 대수를 가질 수 있고 이들의 계열이 있을 수 있으며 이것이 매우 유용할 것이라는 점을 깨달았습니다. "다형성"이라는 용어는 훨씬 나중에 부과되었으며(Peter Wegner에 의해 생각됩니다) 실제로 함수의 명명법에서 유래했기 때문에 그다지 유효하지 않으며 저는 함수보다 조금 더 많은 것을 원했습니다. 나는 거의 대수적인 방식으로 일반적인 행동을 다루기 위해 "일반성"이라는 용어를 발명했습니다.

저는 Simula I이나 Simula 67이 상속을 수행하는 방식이 마음에 들지 않았습니다(물론 Nygaard와 Dahl은 단지 엄청난 사상가이자 디자이너라고 생각했지만). 그래서 더 잘 이해할 때까지 상속을 기본 제공 기능으로 사용하지 않기로 결정했습니다.

~ Alan Kay, 영어를 무료 번역으로 각색

나에게 POO는 메시지 교환, 로컬 데이터 보존, 국가 보호 및 은폐, 모든 것의 극단적인 늦은 바인딩을 의미합니다.

~ Alan Kay, 영어를 무료 번역으로 각색

이를 통해 Kay의 정의를 사용하여 객체지향 프로그램을 보는 관점은 다음과 같다는 결론을 내릴 수 있습니다.

프로그램은 메시지 교환을 통해 통신하는 개체의 네트워크로 간주되며, 여기서 목표는 데이터를 피하고 상호 작용에 중점을 두어 메시지가 여러 가지 의미를 전달할 수 있도록 프로그래밍하는 것입니다.

관점에 대해 말하자면, 이것은 Simula 제작자가 저서 Object-Oriented 프로그래밍 in the BETA 프로그래밍 언어에서 프레임워크의 개념적 프레임워크, 즉 프레임워크의 구조를 보는 방법을 설명하기 위해 사용한 섹션입니다. 특정 패러다임으로 작성된 프로그램(예: 절차적 프로그래밍의 경우)은 다음과 같이 설명됩니다.

프로그램 실행은 변수를 조작하는 (부분적으로 순서가 지정된) 일련의 프로시저 호출로 간주됩니다.

~ Nygaard 전혀, 영어에서 무료 번역으로 각색

기능적인 경우:

프로그램은 입력과 출력의 관계를 설명하는 수학 함수로 간주됩니다.

~ Nygaard 전혀, 영어에서 무료 번역으로 각색

객체 지향의 경우:

프로그램 실행은 실제 또는 가상 세계의 동작을 시뮬레이션하는 물리적 모델로 간주됩니다.

~ Nygaard 전혀, 영어에서 무료 번역으로 각색

따라서 우리의 초점이 Alan Kay의 정의에 맞춰져 있다고 하더라도 객체 지향 언어의 기능과 관련하여 Krysten Nygaard와 Ole-Johan Dahl(Simula 제작자)의 큰 공헌과 그의 관점이 얼마나 오래되었는지를 고려하면 거의 모든 현대 튜토리얼이 추상화 정의의 일부로 공식화되어도 객체가 실제 개념을 나타낸다는 이 이야기를 여전히 따르고 있다는 점을 고려하면 그의 견해를 최종 정의에 포함시키는 것이 적절하다고 말하고 싶습니다.

따라서 두 전통을 하나의 통일된 정의로 조화시켜 전체론적 분석에 대한 우리의 접근 방식을 존중하는 주장이 나올 수 있도록 노력하겠습니다.

따라서 현재 정의에만 국한되지는 않으므로 다음과 같이 늘릴 수 있습니다.

Un programme est vu comme un réseau d'objets, ceux-ci étant des représentations de concepts de domaine, communiquant par l'échange de messages, dans lequel le but est de programmer en évitant les données, en se concentrant sur les interactions, afin qu'un message puisse véhiculer plusieurs significations. Sa structure générale s'apparente à une simulation du comportement d'une partie réelle ou imaginaire du monde.

Une considération qui peut être faite est que cela peut inciter les gens à se concentrer sur la « plus petite idée », mais comme nous l'avons admis auparavant, il est nécessaire de reconnaître comment les idées évoluent au fil du temps, car un mot n'a de valeur que si les gens le comprennent. ce qu'il veut communiquer, je pense donc que cette perspective trouve un équilibre suffisant entre le maintien des objectifs initiaux d'Alan Kay et l'intégration des valeurs du système d'objets de Nygaard et Dahl.

Définir des concepts

Avec le texte actuel de la définition, je pourrais déjà être satisfait, ceci étant ma réponse à la question présentée dans cet article, mais je crois qu'une définition complète d'un paradigme devrait inclure à la fois sa « perspective » de ce qu'il représente l'exécution d'un programme, ainsi qu'un ensemble de principes qui y sont associés.

Par conséquent, nous pouvons dire que nous sommes à mi-chemin, et maintenant nous pouvons revenir à cette longue liste de définitions que j'ai donnée plus tôt pour chercher quels principes conviennent à notre point de vue sans trahir notre vision de base (se concentrer sur l'échange de messages) .

Pour cela, encore une fois, revenons à notre source principale, les principes OO de Smalltalk :

• Échanger des messages ;
• Conservation des données locales, ainsi que protection et masquage de l'État ;
• Extrême reliure tardive.

Si on utilise à nouveau le critère de pertinence historique, on pourrait avancer que comme ces termes ne sont plus utilisés aujourd'hui (à l'exception de l'échange de messages), on devrait plutôt envisager d'utiliser les 4 piliers, et encore une fois, je crois qu'en utilisant une approche conciliante serait ici le meilleur des deux mondes sans contradictions :

• Échanger des messages ;
• Polymorphisme ;
• Encapsulation ;
• Abstraction;
• Héritage ;

Il y a une explication pour le choix de ces 5 principes :

Échange de messages

L'échange de messages est quelque chose de non négociable dans le contexte original de l'OO, après tout Alan Kay prétend être la grande idée du paradigme, son concept le plus important, c'est pourquoi tous les autres concepts doivent avoir quelque chose à voir. faire avec.

Son adoption dans la pratique est assez considérable, car les langages ayant une pertinence historique tels que Self, Objective-C et Ruby entretiennent un lien fort avec ce concept, et Ruby lui-même est considéré comme un langage grand public de nos jours, avec d'excellentes applications construites. dessus comme github lui-même, en plus d'avoir une communauté très active.

Et je dirais qu'avec l'héritage et l'encapsulation, c'est l'un des concepts qui porte le plus l'identité d'OO, puisque les deux autres instances (blague intentionnelle) où le terme est utilisé seraient dans le modèle d'acteur, qui est un modèle mathématique de logique formelle qui a fondamentalement presque les mêmes idées qu'Alan Kay, mais est entièrement basé sur la concurrence (quelque chose comme OO était 100 % asynchrone pour que vous, les développeurs JS, puissiez le comprendre).

Polymorphisme

C'est un concept qui répond à tous les critères de notre analyse, puisque, comme le notent Nygaard et Dahl, il est présent dans pratiquement tous les langages qui implémentent le paradigme, même implicitement (s'il prend en charge l'héritage, le support de le polymorphisme est également implicitement pris en charge).

Il est également très en phase avec l'idée d'échanger des messages, car c'est un avantage naturel de son utilisation. D'ailleurs, il est présent dans la définition d'Alan Kay (même s'il dit préférer le terme de généricité) après tout liaison tardive est le nom du processus présent dans les langues
de programmation qui leur permet de ne pas relier un appel à une fonction avec un code spécifique, mais plutôt de l'exécuter en fonction du contexte (qui dans le cas de OO est l'objet qui reçoit le message), ce qui est exactement la définition du polymorphisme .

En terme de perception du public, ce serait le concept le plus important des 5 listés, étant même défini comme l'essence de l'OO par Oncle Bob, d'ailleurs, même dans des situations où l'on n'envisage pas de programmer exactement en orientation objet, ceci est considéré comme un principe fondamental pour la construction de certaines idées telles que l'architecture hexagonale ou l'architecture propre.

Cependant, le concept n'est pas propre à OO, il s'agit d'un concept plus général présent dans plusieurs paradigmes, souvent avec des implémentations de différents types dans le même langage. Malgré cela, on peut affirmer que le polymorphisme de sous-type spécifique est unique à OO, car il s'agit d'un type dépendant de la capacité du langage à effectuer l'héritage.

Encapsulation

Si vous avez lu notre article sur le sujet (oui, nous aimons parler de définitions ici), vous saurez que dire « Conservation des données locales, ainsi que protection et masquage de l'État » est fondamentalement la définition complète de encapsulation , donc le côté alignement conceptuel, comme les précédents, est ici à 100% sur ce principe.

Bien que certains langages ne mentionnent pas l'encapsulation comme principe, le concept y est présent même à moitié, le fait d'avoir des objets (ou comme dans le cas de Java et Self, en mettant l'accent sur le concept de champs dans les objets) montre qu'ils disposent d'un mécanisme pour que les données ne soient exploitées que dans un contexte local avec leurs fonctions (l'objet lui-même), par contre, des langages tels que C++ et Eiffel présentent des mécanismes pour protéger et masquer l'état sous la forme de modificateurs d'accès (C++) ou d'assertions, de préconditions, de postconditions et d'invariants (Eiffel). En Java, nous avons même l'un des articles les plus célèbres sur l'orientation objet qui traite exactement de l'application de l'encapsulation : Pourquoi les getters et les setters sont mauvais.

Je dirais donc que c'est un principe qui a très bien mûri à l'épreuve du temps, même s'il peut encore souffrir des mêmes critiques que le polymorphisme puisque ce n'est pas un concept exclusivement associé à l'OO, puisqu'il est possible de réalisez-le avec des modules (ce qui serait similaire à avoir un objet singleton), ou des fermetures, puisqu'ils peuvent agir comme des objets du pauvre, cependant, tout comme dans le cas du polymorphisme, le concept est appliqué "avec une saveur unique" dans OO , puisque le mécanisme de conservation des données locales est l'objet et que la dissimulation des informations se produit via des modificateurs d'accès, une fonctionnalité largement associée au paradigme.

Abstraction

Il n'apparaît pas autant que le reste des 4 piliers, cependant, à l'instar de l'encapsulation, sa présence peut quand même être ressentie implicitement plutôt qu'explicitement, puisque, à l'exception de Self, tous les langages mentionnés ont un mécanisme d'abstraction de données sous forme de classes.

En abordant la question du Soi, il accorde une grande importance aux objets eux-mêmes et à l'échange de messages, dont on peut profiter pour analyser la question de l'alignement conceptuel, qui dans ce cas, je dirais que la programmation avec l'échange de messages, en termes plus modernes (bien que les concepts ne soient pas exactement les mêmes), ce serait la même chose que "programmer pour une interface", c'est-à-dire programmer uniquement avec des abstractions, sans se soucier de ce que sera réellement l'implémentation finale. be like, une méthode qui est très bien décrite dans le livre Smalltalk by Sample: The Developer's Guide, d'Alec Sharp, comme étant "la manière de programmer orientée objet".

L'idée d'abstraction en conjonction avec le polymorphisme qui permet à chaque métaphore d'échange de messages de fonctionner, car l'idée est qu'il n'y a aucun moyen de savoir quel sera le résultat de l'exécution du code simplement en regardant les messages, après ce sont toutes des abstractions (dans le même sens que vous ne pouvez pas savoir comment les choses vont s'exécuter en lisant les méthodes d'une interface dans l'OO moderne), et le résultat dépend de leurs implémentations concrètes qui se trouvent dans les objets eux-mêmes, donc l'exécution peut varier en fonction de l'objet qui répond à ce message.

De tous les principes, je dirais que l'abstraction est le plus faible dans le critère d'exclusivité, puisque l'abstraction des données est un principe général, au dessus de la notion de paradigmes comme l'énonce Peter Van Roy dans son article Programming Paradigms for Dummies, Malgré cela , encore une fois, nous sommes dans une situation similaire aux autres principes dans lesquels il utilise un mécanisme extrêmement caractéristique sous forme de classes, qui sont largement reconnus comme une fonctionnalité OO, si reconnue que beaucoup de gens pensent que le paradigme se limite à la programmation avec cours (en oubliant même les objets, et pire encore, les messages au passage).

Patrimoine

Elle est ici pour la raison opposée à l'échange de messages, si l'échange de messages a un faible score de perception du public, mais le plus élevé en alignement conceptuel, l'héritage a le plus faible alignement conceptuel des concepts sélectionnés (ce qui peut être confirmé avec le Je cite qu'Alan Kay n'a ajouté du patrimoine à Smalltalk que parce qu'il ne savait pas vraiment à quoi il allait être utilisé, mais pensait que cela pourrait être utile), mais il a la plus grande perception du public, en plus de contributions historiques très élevées.

Au début, c'était l'une des principales caractéristiques de Simula, elle était considérée comme l'essence de l'OO, dans l'ère post-Smalltalk, bien que cela ait été complètement inversé après la publication de l'idée de composition au lieu d'héritage par GoF.

Malgré cela, c'est le seul concept exclusivement associé à OO, étant une fonctionnalité dont la présence suffirait à différencier un langage comme orienté objet dans de nombreux cas. Les seuls arguments qui pourraient aller à l'encontre de cela sont l'idée de Hoare des enregistrements, mais c'est ce qui a donné naissance à l'héritage dans Simula, et aux types de produits, mais c'est un sujet très différent de l'héritage, et ni si vous souffrez des mêmes problèmes et controverses.

Conclusion

Enfin, nous avons à la fois la perspective et les principes, donc notre définition finale est :

Un programme orienté objet est vu comme un réseau d'objets, ceux-ci étant des représentations de concepts de domaine, communiquant par l'échange de messages, dans lequel le but est de programmer en évitant les données, en se concentrant sur les interactions, afin qu'un message puisse véhiculer plusieurs significations. Dont les principes sont l'échange de messages, le polymorphisme, l'encapsulation, l'abstraction et l'héritage. Ayant pour structure générale quelque chose de similaire à une simulation du comportement d'une partie réelle ou imaginaire du monde.

Quoi qu'il en soit, c'est ma réponse finale à la question présentée dans le titre de l'article, toute cette recherche a demandé beaucoup de travail, donc j'espère que le texte vous aura au moins appris quelque chose de nouveau, ou conduit à quelques réflexions.

Si vous êtes d'accord ou pas d'accord avec ma définition, n'oubliez pas de partager votre avis dans les commentaires, et à la prochaine fois !

Liens qui pourraient vous intéresser

• Wikipédia sur les paradigmes de programmation ;
• Wikipédia sur le polymorphisme ;
• C2 Wiki - Personne n'est d'accord sur ce qu'est OO ;
• Wiki C2 - Programmation Orientée Objet ;
• Stackoverflow - Signification de la terminologie « Orienté objet » ;
• EOLANG et Phi-Calcul ;
• Concepts, techniques et modèles de programmation informatique ;
• Paradigmes de programmation pour les nuls ;
• Smalltalk par exemple ;
• Programmation orientée objet dans le langage de programmation BETA ;
• Pourquoi C++ n'est pas seulement un langage de programmation orienté objet ;
• Dr Alan Kay sur la signification de la « programmation orientée objet » ;
• La naissance de l'orientation objet : les langages Simula ;
• Deux grandes écoles de Programmation Orientée Objet ;
• ISO/CEI 2382:2015 ;
• Modèle d'objet automatique ;
• Le manuel de soi ;
• Soi : le pouvoir de la simplicité ;
• Dynamique vs. Envoi statique ;
• (Fausses) interprétations de la POO ;
• Objets émergents Construire un système d'objets simple à partir de fermetures ;
• MOPping up Construire un protocole méta-objet simple ;
• Interface de répartition ;
• Alan Kay et programmation OO ;
• Alan Kay n'a pas inventé d'objets ;
• prototypes vs classes était : Re : Sun's HotSpot ;
• Sur l'avenir de la spécification et de l'organisation des programmes informatiques ;
• Programmation sans données ;
• La première histoire de Smalltalk ;
• Déclaration incontournable considérée comme nuisible ;
• Théorème de Boehm-Jacopini ;
• Eiffel à propos d'OO;
• Devmedia sur OO ;
• Wikipédia sur le calcul lambda ;
• Ada à propos d'OO ;
• Spécification Java 3e édition ;
• C# sur OO ;
• Python sur OO ;
• PHP sur OO ;
• Ruby Doc;
• MDN sur OO ;
• Analyse et conception orientées objet avec applications ;
• Livre de modèles de conception ;
• Pourquoi les getters et les setters sont mauvais ;
• Blog Clean Coder - FP vs. OO;
• Wikipédia sur le modèle d'acteur ;
• Akka (langage de programmation) à propos du modèle d'acteur ;
• Majestueux à propos du modèle d'acteur ;

Cul : Soutien fatigué

위 내용은 결국 객체 지향의 정의는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!