最近、「OOPはクールvs手続き型プログラミングは悪い」、「OOPは悪いvs手続き型プログラミングは悪い」、「OOPと手続き型は悪いvs XYZ原理の未来」というトピックに関する記事に気付きました。
これらの記事で最もおもしろいのは、多くの人がO ++をC ++で規定された原則として理解していることです。 また、OOPが何であるかを本当に理解する人はほとんどいません。 突然、プログラマーの99％がOOPが何であるかを一般的に理解していないように思われました。 しかし、多分私は間違っている？ 見てみましょう...
この記事の目的は、holivarではなく、OOPの概念に関する異なる視点を実現する試みです。 視点は私のものではなく、著者です。 最悪のことは、私の視点は著者のどこかに近いが、ほとんどのプログラマーがこの用語で理解していることとは程遠いということです。
OOPの文言を見てみましょう
OOP =オブジェクト指向プログラミング。 つまり、特定のオブジェクトの作成に基づいたプログラミング。 そして、誰かがクラスについて話していると決めました。 しかし、誰がこれを決めましたか？ いつ？ そして、なぜですか？
学生のベンチから話を進めると、OOPの原則を実装して大衆に公開した最初の人の1人がC ++であることがわかります。
さらに進んだものはすべて、この概念を正確に継承しました。 すべては何もありませんが、1つの問題があります。 誰もが、C ++がOOPをサポートし、OOPに関連付けられていると考えていますが、OOPの概念の著者は例外です。
彼の引用は次のとおりです。
「オブジェクト指向」という用語を作り出しました。C++を意味するものではないことを保証します
-アラン・ケイ
彼のリンクからより多くの興味深い引用：
1.Habréに関する興味深い記事は
こちら2. 15の引用符の選択
。そのうちのいくつかは
ここで非常に興味深い
これらの引用のいくつかは、後で意識を変えるために使用されます。
C ++が作者が念頭に置いていたOOPでない場合、どれですか？
著者は、これがSmallTalkに似たものであると主張しています。 そして、誰もがLISPを学ぶことを奨励します。 しかし、これらの言語に精通している読者は何人いますか？ これらの言語に精通し、実際に適用された問題を解決した経験のある人がいれば、この記事に関するコメントを喜んでいます。
しかし、私の話題はこのトピックに関する彼の多くの引用に夢中になりました。
1.何年も前に「オブジェクト」という用語を作り出したことを後悔しています。なぜなら、人々が小さなアイデアに集中するからです。 本当に大きなアイデアはメッセージです。」
2. 「大規模で拡張可能なシステムを作成するための鍵は、モジュールが相互にどのように通信するかを考えることであり、内部プロパティと動作を気にしないことです。」
3. 「オブジェクトを生きた細胞、またはメッセージを交換するネットワーク上の別個のコンピューターと考えました。」
4. 「重要なアイデアの1つは、テスト中、特に変更中に機能し続けるシステムを作成することです。 大規模な変更であっても、増分する必要があり、有効になるまでに1秒しかかかりません。
5. OOPは、メッセージ、ローカルの保持と保護、状態の隠蔽、すべての遅延バインディングです。 これは、SmalltalkおよびLISPで実行できます。
そして、思考のプレッシャーのための別のシリーズ：
ずっと前に、このトピックに「オブジェクト」という用語を使用していたことを残念に思います。これは、多くの人々がより少ないアイデアに集中しているためです。 現代の静的に型付けされたオブジェクト指向言語にはない大きなアイデア：大きなアイデアは「メッセージ」です。 優れたスケーラブルなシステムを作成するための鍵は、モジュールの通信メカニズムを解明することであり、内部のプロパティと動作を解明することではありません。
これらの引用文では、次の機能に注意してください。
1.これはプログラミング言語に関するものではなく、アプローチに関するものです。
2.焦点はオブジェクトではなく、オブジェクトは一般に受け入れられているものではありません
3.オブジェクトはモジュールまたはシステムコンポーネントです（コンピューターとサーバーが別々であることもあります）
4.ポイントはオブジェクト自体ではなく、これらのセルがメッセージを介して相互に通信する能力にあります
そして今、私たちはOOPの概念の本質を変えることに近づきました。
OOPはアプリケーションアーキテクチャです
プログラミング言語ではありません。 そして、システムがオブジェクトを作成し、それらと相互作用の間の効果的なメッセージングを提供する能力について。 また、原則としてそのような言語は存在しないという考えに注目する価値があります。 このイデオロギーに一部近づくことができたプラットフォームのみがあります。
私は、要件が日々変化する大規模で複雑なシステムを管理するのに十分な柔軟性を備えたプラットフォームを探していたときに、このアイデアの本質を理解したように思えました。
そして、私はそれをやった。
このプラットフォームには、著者のバージョンのOOPの概念に対する多くの対応があります。
1.このシステムでは、コンポーネントは相互にメッセージを交換するため、相互の動作を変更できます。 1つのコンポーネントは、他のコンポーネントの動作を変更できます。 （一致する引用＃1）。
2.このプラットフォームの全体的なポイントは、モジュールが相互に対話できることです。 さらに、モジュール自体の内部には、愚かな後輩のひどく曲がった手を書くことができます（引用番号2に一致）。 また、このプラットフォームには、他のプラットフォームに比べて世界で最も多くのモジュールがあります。 おそらく、このプラットフォームでは、この原則が他のどこよりも優れているためです。
3.このシステムのコンポーネントは、一瞬で追加または削除できるセルのようなものです。 それらは何万人もいます。 それらからシステムを構築します。 さらに、そのような各セルは他のセルとメッセージを交換できます。
4.同時に、各コンポーネントは非常に自律的であり、多くの場合、システム全体を停止せずに切断および修復できます。 （一致する引用＃4）。 オンザフライで数秒で更新できます。 システム内には、100を超えるこのようなコンポーネントが存在する場合があり、各コンポーネントは個別の開発チームによって更新されます。
5.システムには、最初にメッセージチャネルが含まれています。 そして、彼らの束は後であるかもしれません。 必要なときにいつでも。 今日、私はそれがどのくらい遅く、いつ、どこで、どのコンポーネントを将来変更する必要があるかを知りません。 しかし、私はこれをできる可能性が高いと理解しています。 変更する必要があるコンポーネントの状態と動作を理解したらすぐに、これを非常に簡単または比較的簡単に行うことができます。
このプラットフォームは、OOPの概念に最も近いように思えました。 おそらくこの理由で、このプラットフォームは市場を獲得しました。 多くの指標で世界でナンバーワンになりました。 世界およびロシア連邦のサイトの25％以上がこのプラットフォームで動作しています。 これは絶対的な世界記録です。 私は多くがすでにそれが何であったかを推測していると思う:)これはWordPressです。
世界には、コンセプトの作者が見た方法に近いOOPの原則を実装することができた他のプラットフォームがあると思います。 しかし、WPの市場シェアから判断すると、これは明らかに成功を示しました。 phpは単なるプログラミング言語です。 それ自体では、彼はOOPを与えません。 OOPは、コンポーネント（またはコンセプトの作成者のコンセプト内のオブジェクト）の相互作用に必要なメソッドを提供するレイヤーを介してのみ形成されます
これらの機能を備えていると思われた別のプラットフォームは、Backbone.jsです。 JavaScriptは、phpと同様、OOPに必要なメソッドを提供しませんが、Backbone.jsは既に提供しています。 また、オブジェクトを作成し、それらの間で効率的なメッセージングを提供できます。
または、RESTfull APIとWebhookを介して通信する最新のマイクロサービスシステムを利用してください。 このような各Webサービスは、作成者が見るとおり、本質的にOOPの概念のオブジェクトです。
まとめ
これは、自分の観点を課そうとする試みではありません。 これは、誰がどのようにこのイデオロギーを見ているかを理解しようとする試みです。 PHPで受け入れられているOOPが大好きです。 クラスを使用します。 同時に、手続き型プログラミングに反対ではなく、これは多くのタスクに適していると思います。 REST APIとwebhookを使用したアプローチを尊重します。 しかし、私はそれぞれの方法を絶対的な真実とは考えず、それぞれのツールがその意図された目的に使用されていることを評価しています。
さらに私はWordPressフックシステムが好きです。これにより、数百のコンポーネントを持つ真に複雑なシステムを作成でき、各コンポーネントはシステム開発のどの段階でも追加または削除できます。 したがって、多くのプロセスと人の組織でビジネスプロセスまたはアグリゲーターを管理するための非常に複雑なシステムを作成することができました。 市場で見つけるのが難しい非常に複雑なアナログ。 そして、OOPコンセプトの作者からの引用から判断すると、WordPressのフックとフィルターのメカニズムは、通常phpやC ++でクラスとして記述されているものよりも、OOPの元のコンセプトに非常に近いものです。
誰がこれについて考えますか？ このOOPの理解は誰に近いですか？ なんで？ 誰がこのナンセンスを考慮しますか？ なんで？ 私に話してください... :)
更新しました。 20160811
おっと ここですでに説明したことはすべてよく知られており、Wikipedia-
proofにも存在します。
そして、OOPがクラス指向プログラミングとコンポーネント指向プログラミングに分かれているという事実ですらあります。 言い換えれば、彼らが通常意味するOOPはクラス指向であり、これはC ++で発明されたものであり、記事で説明されているものはコンポーネント指向であり、これはAlain Kayによって発明されたものです。
この記事では、プログラマーの99％がOOPが何であるかを知らないと言って間違えました。 この考えがナンセンスであると決定した人々は、コメントで間違っていました。 そのようなもの。