OOPから逃れる時が来ました
OOPは、コンピューターサイエンスの頂点に立つ最大のダイヤモンドと見なされています。コードを整理するための最良の方法。すべての問題の解決策。私たちのプログラムを書く唯一の確実な方法。プログラミングの神は私たちを上から送ってくれました...ここでのみ、OOPプログラマーはあらゆる種類の抽象化の束をかき集め、すべての共有オブジェクトを追跡し、大量の「プログラミングパターン」を覚え、問題自体を解決するのではなく、これらすべてに時間とエネルギーを費やすことを余儀なくされます。
多くの人が長い間OOPを批判しており、これらの批評家の中には非常に尊敬されているプログラマーがたくさんいます。そして、Alan Kay -OOPの発明者でさえ彼らの仲間入りです！
開発者の主な目標は、信頼できるコードを書くことです。コードにバグがあり、意図したとおりに機能しない場合は、他に何も問題はありません。信頼できるコードを書くための最良の方法は何ですか？コードはシンプルにしてください。シンプルさは複雑さの反対です。したがって、開発者の主な目標は、コードの複雑さを軽減することです。
免責事項：
私はOOPファンではないので、この記事が多くの人に偏っているように見えるのは当然のことです。しかし、私は自分の立場を擁護するために議論をします。
また、OOPに対する批判は多くの人にとって非常に苦痛であることもよく理解しています。非常に多くの読者が個人的に気分を害するでしょう。しかし、私は自分が正しいと信じていることを述べるつもりです。私の目標は気分を害することではなく、OOPが抱えている問題を指摘することです。私はアランケイ
のOOPを批判していません。彼は一般的に天才です。個人的には、OOPをAlanKayが意図したとおりにしたいと思います。私が批判しているのは、C＃またはJava実装でのOOPです。
問題は、OOPがソフトウェアコードを整理するための標準と長い間考えられてきたことです。そして、ソフトウェア業界で真剣な立場にある人々を含め、非常に多くの人々が考えています。そのため、ほとんどの企業では、プログラミングに対する他のアプローチさえ考慮されていません。
OOP言語で書いたとき、私は多くの困難を克服しなければなりませんでした。そして、なぜこれらの困難が生じたのか、私はいつも疑問に思っていました。多分私はあまり良くなかったのですか？たぶん私はさらに数十の「プログラミングパターン」を学ぶ必要がありましたか？結局、私にはこれらすべてのための力が残っていませんでした。
この記事では、私がOOPから機能プログラミングに移行した10年の長い道のりについて説明します。それ以来、OOPが最適なプロジェクトに出くわしたことは覚えていません。さらに、OOPが使用されたプロジェクトは、コードの複雑さの重みで失敗しました-ある時点から、それらをさらに維持および開発することは不可能でした。
TLDR
「オブジェクト指向のプログラムは適切なプログラムの代替手段です。」
Edsger W. Dijkstra、コンピューターサイエンスのパイオニア
OOPの目的は1つでした-手続き型コードの複雑さに対処することです。言い換えると、OOPはコード編成を改善するために設計されました。しかしそれ以来、OOPが古い手続き型プログラミングよりも優れているという証拠はありません。
厳しい真実は、OOPが設計された1つのことを実行しなかったということです。紙の上ではすべてが素晴らしく見えました-動物、犬、人の厳密な階層がありました...（そしてもちろん、形：長方形、正方形、円-それらなしでどこに行くことができますか！）しかし、アプリケーションコードの複雑さが増すにつれて、OOPはそれを減らすのに役立ちませんでした、しかし逆に増加しました-必要な「プログラミングパターン」が大量にあり、プログラマーが変数の値がどこでどのように変化するかを追跡するのが困難になっています。 OOPは、リファクタリングやテストなど、一般的に使用される多くの手順を不必要に複雑にしました。
多くの人が私に同意しませんが、C＃またはJavaでのOOPの設計は科学的に考えられておらず、真剣な科学的研究の結果ではありませんでした。たとえば、ラムダ計算が確かな理論的基礎であるHaskellの機能プログラミングとは異なります。 OOPはそのようなものに基づいていません。
小規模なプロジェクトでは、OOPは非常にうまく機能します。しかし、プロジェクトが成長するとどうなりますか？ OOPは、プロジェクトコードが特定のサイズに達すると、必然的に爆発する時限爆弾です。プロジェクトは遅れ始め、締め切りは失敗し、開発者はエネルギーを使い果たし、新しい機能を追加することはほとんど不可能になります。結局、企業はそのようなコードを「廃止」としてマークし、開発者に書き直しを強いることになります。
OOPは、私たちの脳の考え方にあまり適合していません。私たちは行動に集中することに慣れています：散歩に行く、友人と話す、ピザを食べる。私たちの脳は、抽象的なオブジェクトの複雑な階層を構築することではなく、「何かをする」ことを目指して進化してきました。
OOPコードは（機能プログラミングとは異なり）非決定論的です。同じ入力データで毎回同じ結果が得られるかどうかはわかりません。これにより、プログラムがどのように機能するかを理解することが非常に困難になります。簡単な例を次に示します。2+ 2とcalculator.Add（2、2）を比較します。理論的には、最後の式は常に4を返す必要がありますが、Calculatorオブジェクトの依存関係のため、5、3、または1004を返すこともあります。 最も予測できない方法で彼の行動を変えることができます。