結局のところ、オブジェクト指向の定義は何でしょうか?-＆＃＆チュートリアル-php.cn

Afinal de contas, qual a definição de Orientação a Objetos?

導入

オブジェクト指向パラダイムは、確かにプログラミングにおいて最も関連性の高いトピックの 1 つであり、SOLID、GoF デザインパターン、オブジェクトカルヒステニクスなどの業界のベストプラクティスのいくつかに見られ、さらには Java などの非常に人気のある言語にも見られます。、C#、Ruby、PHP、JavaScript など。そして、そのような関連性を考えると、これはオンラインの議論や学術界自体の両方でさえ、いくつかの議論の主題でもあります。

このパラダイムをめぐる主な論争の 1 つは、「オブジェクト指向は実際にはどうなるのか?」というものでしょう。これが何を意味するかについては誰も同意していないため、これがさまざまな種類のインターネット上の争いにおける問題の核心です。たとえば、誰かが自分の言語は真にオブジェクト指向であるが、他の言語はそうではない、と主張する場合、または特定の言語は実際にはオブジェクト指向ではない場合などです。指向性など

これは一見ばかばかしいように思えるかもしれませんが、この背後には隠れた問題があります。それは、オブジェクト指向とは何かについての正式な定義が実際には存在しないという事実です。したがって、パラダイムに関連するものを批判する場合、実際に何が真実であるか誰も知らないという事実により、それが公平であるかどうか実際には確信が持てません。これは、双方が他方を非難する議論につながるだけであるためです。議論している内容の定義に同意できないため、ストローマンを攻撃する行為。そのため、同じことについて話そうと考えながら、別のことについて話すことになります。

このようなことが起こるのは、構造化/手続き型パラダイム（ベーム・ヤコピニの定理や有害と考えられる論文のGo-Toステートメントから生じる）などの議論の主要な情報源として特定できる正式な基礎から生じていないためです。あるいは、ラムダ計算から生まれた関数型から、あるいは逆に、技術的には 2 つの異なる起源があり、それが物事を非常に難しくしています。結局のところ、どちらが最初のオブジェクト指向言語だったのかを言うことさえ困難です。 Simula または Smalltalk。

このトピックに事前に接触したことがない場合は、私がここで説明するすべてが少し奇妙に感じるかもしれません。結局のところ、私たちは皆オブジェクト指向について学び、日常のコミュニケーションに言葉を使用しており、すべてが正常に進んでいるように見えます。、通信にノイズが発生しませんね?

インターネット上の一般的なチュートリアルやウィキペディアなどのさまざまな情報源を見たり、正式な教育 (技術コースや大学など) を通したとしても、それは非常に簡単だとさえ思われるかもしれません。私がオブジェクト指向の 4 つの柱と呼ぶものと非常によく似た定義が見つかります:

抽象化;
カプセル化;
継承;
ポリモーフィズム。

しかし、これは実際には話の一部にすぎません。前に指摘したように、実際にはオブジェクト指向の考え方には 2 つの異なる流派があり、1 つは Simula で作られた伝統から発展し、C++ によって開発され普及したものです。もう 1 つは、Smalltalk によって作成された伝統の中で成長したものです。

たとえ C++ の伝統における歴史の勝利側を受け入れることができたとしても (OO とみなされる言語の大多数は、現在 Smalltalk の考えよりも C++ の考えに従っているため)、つまり、C++ で進化した Simula の遺産を受け入れることができます。 4 つの柱について、正確にこの 4 つであるかどうか、あるいは本当に 4 つであるべきかどうかについては合意がありません。例:

C++ 言語の作成者自身は、3 つの柱 (抽象化、継承、ポリモーフィズム) のみを持つ定義を検討しています。
Eiffel 言語では、別の 6 つの原則 (クラス、アサーション、ジェネリック性、継承、ポリモーフィズム、および動的バインディング) のセットが考慮されます。
Smalltalk 言語の作成者は、この用語を作ったときに意味したことは、現在私たちが使用しているものとはまったく異なると述べ、実際には 3 つの原則 (メッセージパッシング、カプセル化、およびすべての極度の遅延バインディング) に要約されると説明しています。もの);
Ada 言語は 3 つの原則 (カプセル化、継承、ポリモーフィズム) のみを定義します。
Self 言語は、他の名前があるにもかかわらず、他の定義 (継承、フィールド、メッセージ交換) で使用される用語と同等の 3 つのアイデア (プロトタイプ、スロット、および動作) に基づいています。
Java 言語は 5 つの概念 (カプセル化、フィールド、継承、メソッド、オブジェクト) を定義します。
C# 言語は 4 つの柱に従います。
Simula 言語の作成者は、具体的な定義がないことを認めていますが、オブジェクト指向とみなされる言語に共通すると考えられるいくつかの概念 (オブジェクト、クラス、継承、ポリモーフィズム) を挙げています。
Python 言語はオブジェクト指向として 4 つの概念 (クラス、オブジェクト、継承、ポリモーフィズム) を挙げています。
Ruby 言語は、すべてがオブジェクトであるべきという考えとメッセージ交換に重点を置き、Smalltalk の定義に従うと主張しています。
PHP 言語にはオブジェクト指向の正式な定義はありませんが、オブジェクト指向として示される機能に基づいて、PHP 言語が 4 つの柱のようなものに従っていることを導き出すことができます。
Objective-C 言語にはオブジェクト指向の正式な定義はありませんが、そのマニュアルでは次の概念の組み合わせ (すべてがオブジェクト、クラス、メッセージパッシング、カプセル化、継承、ポリモーフィズムです) を提案しています。
MDN Web サイトの JavaScript 言語に関するセクションでは、3 つの概念 (クラスとオブジェクト、継承とカプセル化) を考慮しています。
書籍『オブジェクト指向分析とアプリケーションによる設計』の著者である Grady Booch は、7 つの原則 (抽象化、カプセル化、モジュール性、階層、型指定、同時実行性、永続性) を定義しています。
GoF (Gang of Four: Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides) は、著書『デザインパターン: 再利用可能なオブジェクト指向ソフトウェアの要素』の中で、手続き型の「デザインパターン」としてカプセル化、継承、ポリモーフィズムを挙げています。言語;
Peter Van Roy は、著書「Concepts, Techiniques, and Models of Computer Programming」の中で、オブジェクト指向を 4 つの項目 (抽象化メカニズム、明示的な状態、ポリモーフィズム、継承などのオブジェクト) で説明しています。
ISO/IEC 2382 item 2122503 は正式な定義に最も近いもので、6 つの原則 (抽象化、カプセル化、継承、ポリモーフィズム、メッセージ交換、動的バインディング) を考慮しています。
Yegor Bugayenko は、EOLANG 言語で実装されたファイ計算と呼ばれる、彼が作成した正式なモデルを通じてそれを定義します。
etc...

視点を定義する

この方法では、Bjarne Stroustrup (C++ の作成者) がオブジェクト指向の定義で次のように主張しています。

「オブジェクト指向」の定義はどれも歴史的に受け入れられるべきです。言葉はコミュニケーションにのみ役立ち、私たちが言葉の意味について合意した場合にのみ意味を持ちます。

~ Bjarne Stroustrup、英語からの意訳

そのため、私は全体的なアプローチ（部分の音ではなく全体を分析する）を採用して、自分の定義のために何を考慮すべきかを分析したいと思います。ここでは、重要度の順に 4 つの基準に従って評価します。

歴史の出発点を定義することから始めましょう。まず、どちらの側を主要な情報源として選択するかを決定し、次に、オブジェクト指向がその作成者によって定義の基礎として何を意味するのかという意図に沿っていきます。さらに、どの原則セットをその中に含めるのが理にかなっているかを判断するための比較パラメータとして使用します。

On this question, I like the view that Alan Kay invented "object orientation" but not "objects", so our basis will be his view of what object orientation should be, which we can summarize in a few quotes:

Just a gentle reminder that I worked hard last OOPSLA to try and remind everyone that Smalltalk isn't just its syntax or class library, nor is it about classes. I regret coining the term "objects" a long time ago for this topic because it causes many people to focus on the smaller idea.

The big idea is "messaging" - that's what the core of Smalltalk/Squeak is all about...

~ Alan Kay, adapted from English in free translation

I thought of objects like biological cells and/or individual computers on a network, capable only of communicating through messages (so messages came early on - it took a while to see how to send messages in a programming language efficiently enough to be useful).

I wanted to get rid of the data. The B5000 almost did this through its almost unbelievable HW architecture. I realized that the whole cell/computer metaphor would eliminate the data, and that "<-" would be just another message token (it took me a while to think about this because I actually thought of all these symbols as names for functions and procedures .

My background in mathematics made me realize that every object could have several algebras associated with it, and there could be families of these, and that these would be very useful. The term "polymorphism" was imposed much later (I think by Peter Wegner) and is not very valid, as it actually comes from the nomenclature of functions, and I wanted a little more than functions. I invented a term "genericity" to deal with generic behaviors in an almost algebraic way.

I didn't like the way Simula I or Simula 67 did inheritance (although I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better.

~ Alan Kay, adapted from English in free translation

POO to me just means message exchange, local data retention and state protection and hiding, and extreme late binding of all things.

~ Alan Kay, adapted from English in free translation

With this we can conclude that the perspective from which we see an object-oriented program using Kay's definitions is as follows:

A program is seen as a network of objects communicating through the exchange of messages, in which the aim is to program by avoiding data, focusing on interactions, so that a message can carry several meanings.

Speaking of perspective, this is the section used by the creators of Simula in their book Object-Oriented Programming in the BETA Programming Language to describe the conceptual framework of a framework, that is, a description of how we see the structure of a program written in a certain paradigm, for example in the case of procedural programming, they describe it as:

The execution of a program is considered a (partially ordered) sequence of procedure calls that manipulate variables.

~ Nygaard at all, adapted from English in free translation

In the case of functional:

A program is considered a mathematical function, which describes a relationship between input and output.

~ Nygaard at all, adapted from English in free translation

And for object orientation:

The execution of a program is considered a physical model, simulating the behavior of a real or imaginary part of the world.

~ Nygaard at all, adapted from English in free translation

So, even if our focus is on Alan Kay's definition, given the great contributions of Krysten Nygaard and Ole-Johan Dahl (creators of Simula) regarding the functionalities found in object-oriented languages, and how well his perspective has aged over time, given that almost every modern tutorial still follows this story that objects represent real-world concepts, even being formalized as part of the definition of abstraction, I would say it is appropriate to incorporate his views into our final definition.

Thus, where an argument can be made for reconciling the two traditions into a unified definition, thus respecting our approach to a holistic analysis, I will try.

Therefore, as it is not necessarily exclusive to our current definition, we can increase it with the following:

A program is seen as a network of objects, these being representations of domain concepts, communicating through the exchange of messages, in which the aim is to program avoiding data, focusing on interactions, so that a message can carry several meanings. Its general structure is something similar to a simulation of the behavior of a real or imaginary part of the world.

One consideration that can be made is that this may direct people to focus on the "smaller idea", but just as we admitted before it is necessary to recognize how ideas evolve over time as a word only has value if people understand it what it wants to communicate, therefore I believe that this perspective finds enough balance between maintaining Alan Kay's initial objectives, and incorporating the values of Nygaard and Dahl's object system.

Defining concepts

With the current text of the definition, I could already be satisfied, this being my answer to the question presented in this article, but I believe that a complete definition of a paradigm should include both its "perspective" of what it represents the execution of a program, as well as a set of principles associated with it.

Therefore, we can say that we are halfway there, and now we can go back to that extensive list of definitions that I gave earlier to look for which principles suit our perspective while not betraying our base vision ( focus on exchanging messages).

For this, again, let's go back to our primary source, Smalltalk's OO principles:

Exchange messages;
Local data retention, along with state protection and hiding;
Extreme late binding.

If we use the historical relevance criterion again, it could be argued that as these terms are no longer used today (with the exception of messaging), we should consider using the 4 pillars instead, and again, I believe that using a conciliatory approach here would be the best of both worlds without contradictions:

Exchange messages;
Polymorphism;
Encapsulation;
Abstraction;
Inheritance;

There is an explanation for choosing these 5 principles:

Exchange of messages

The exchange of messages is something non-negotiable within the original context of OO, after all Alan Kay claims to be the big idea of the paradigm, its most important concept, which is why all other concepts must have something to do with it.

Its adoption in practice is quite considerable, since languages with historical relevance such as Self, Objective-C, and Ruby maintain a strong connection with this concept, and Ruby itself is considered a mainstream language nowadays, with great applications built on it like github itself, in addition to having a very active community.

And I would say that along with inheritance and encapsulation, it is one of the concepts that most carries the identity of OO, since the other two instances (purposeful joke) where the term is used would be in the Actor Model, which is a mathematical model formal logic that basically has almost the same ideas as Alan Kay, but is completely based on concurrency (something like OO was 100% async for you JS devs to understand).

Polymorphism

This is a concept that meets all the criteria of our analysis, since, as noted by Nygaard and Dahl, it is present in practically all languages that implement the paradigm, even if implicitly (if it supports inheritance , support for polymorphism is implicitly supported as well).

It is super aligned with the idea of exchanging messages too, as it is a natural benefit of its use. Besides, it is present in Alan Kay's definition (although he says he prefers the term genericity) after all late binding is the name of the process present in languages
of programming that allows them not to relate a call to a function with a specific code, but rather to execute it based on the context (which in the case of OO is the object that receives the message), which is exactly the definition of polymorphism.

In terms of public perception, it would be the most important concept of the 5 listed, being even defined as the essence of OO by Uncle Bob, moreover, even in situations where one does not plan to program exactly in object orientation, this is considered principle as a fundamental block for the construction of some ideas such as hexagonal architecture or clean architecture.

However, the concept is not unique to OO, being a more general concept present throughout several paradigms, often with implementations of different types in the same language. Despite this, it can be argued that specifically subtype polymorphism is unique to OO, as it is a type dependent on the language's ability to perform inheritance.

Encapsulation

If you've read our article on the subject (yes, we like to talk about definitions around here), you'll know that saying "Local data retention, along with state protection and hiding" is basically the complete definition of encapsulation , so the conceptual alignment side, like the previous ones, is 100% on this principle here.

Although some languages do not mention encapsulation as a principle, the concept is present in them even in half, the fact of having objects (or as in the case of Java and Self, emphasizing the concept of fields in objects) shows that they have a mechanism to keep data only being operated in a local context along with its functions (the object itself), on the other hand, languages such as C++ and Eiffel present mechanisms for protecting and hiding the state in the form of access modifiers (C++) or assertions, preconditions, postconditions, and invariants (Eiffel). In Java we even have one of the most famous articles on object orientation that discusses exactly the application of encapsulation: Why getters and setters are evil.

So I would say that it is a principle that has matured very well in the test of time, although it can still suffer from the same criticisms as polymorphism since it is not a concept exclusively associated with OO, since it is possible to realize it with modules (which would be similar to having a singleton object), or closures, since they can act as poor man's objects, however, just as in the case of polymorphism, the concept is applied "with a unique flavor" in OO, since the Local data retention mechanism is the object, and information hiding occurs through access modifiers, a functionality widely associated with the paradigm.

Abstraction

It does not appear as much as the rest of the 4 pillars, however, similar to encapsulation, its presence can still be felt implicitly rather than explicitly, since, with the exception of Self, all languages mentioned have a mechanism of data abstraction in the form of classes.

Going into the issue of the Self, he places great emphasis on the objects themselves and on the exchange of messages, which we can take advantage of to analyze the issue of conceptual alignment, which in this case, I would say that programming with the exchange of messages, in more modern words (although the concepts are not exactly the same thing) would be the same as "programming for an interface", that is, programming only with abstractions, without worrying about what the final implementation will actually be like, a method that is very good described in the book Smalltalk by Example: The Developer's Guide, by Alec Sharp, as being "the object-oriented way to program".

The idea of abstraction in conjunction with polymorphism that allows every message exchange metaphor to work, as the idea is that there is no way to know what the result of executing the code will be just by looking at the messages, after all they are abstractions (in the same sense that you can't know how things will execute when reading the methods of an interface in modern OO), and the result depends on their concrete implementations that are found in the objects themselves, so the execution may vary depending on which object responds to that message.

Of all the principles, I would say that abstraction is the weakest in the exclusivity criterion, since data abstraction is a general principle, above the concept of paradigms as stated by Peter Van Roy in his article Programming Paradigms for Dummies, Despite this, again, we are in a similar situation to the other principles in which it uses an extremely characteristic mechanism in the form of classes, which are widely recognized as an OO functionality, so recognized that many people think that the paradigm is limited to programming with classes (even forgetting the objects, and even worse, the messages in the process).

Heritage

She is here for the opposite reason to exchanging messages, if the exchanging messages has a low public perception score, but the highest in conceptual alignment, the inheritance has the lowest conceptual alignment of the selected concepts (which can be confirmed with the quote that Alan Kay only added heritage to Smalltalk because he didn't really know what it was going to be used for, but thought it might be useful), but it has the greatest public perception, in addition to very high historical contributions.

To begin with, it was one of the main features of Simula, it was considered the essence of OO, in the post-Smalltalk era, although this was completely reversed after the idea of composition instead of inheritance was published by GoF.

Despite this, it is the only concept exclusively associated with OO, being a functionality whose presence would be enough to differentiate a language as object-oriented in many cases. The only arguments that could go against this are Hoare's idea of records, but it was what gave rise to inheritance in Simula, and product types, but this is a very different subject from inheritance, and neither if you suffer from the same problems and controversies.

Conclusion

Finally we have both the perspective and the principles, so our final definition is:

An object-oriented program is seen as a network of objects, these being representations of domain concepts, communicating through the exchange of messages, in which the aim is to program avoiding data, focusing on interactions, so that a message can carry several meanings. The principles of which are message exchange, polymorphism, encapsulation, abstraction, and inheritance. Having as its general structure something similar to a simulation of the behavior of a real or imaginary part of the world.

Anyway, this is my final answer to the question presented in the title of the article, this whole research took a lot of work, so I hope the text may have at least taught you something new, or led to some reflections.

If you agree or disagree with my definition, don't forget to share your opinion in the comments, and see you next time!