Jun Mukai:* とにかく、おちついてください。ここは質問に対して回答を出すサイトですが、あなたの文章は質問の域を大きく越えています。自説を開陳するのは回答者として行ってください * というか、そもそも自分のブログに書くべき内容に思いました * あなたには自説があり、それに同意してくれる専門家に現れてほしいという思いがあるように思います。ここではなくQuoraなどにもそういう質問が山程あって、率直に申し上げるといささか食傷しております * オブジェクト指向プログラミングが廃れた、という前提をお持ちのようですが、その前提は広く共有されたものではないと思います。近年に生まれたモダンな言語や、いま人気のある言語のなかで、オブジェクト指向の機能をもたない言語は非常に限られています。オブジェクト指向の機能もひろくよく使われています。廃れたとはとても考えられません * 継承による実装の共有などの個別の機能については流行り廃りがたしかにあり、様々な言語機能や考え方が発達することで超克されてしまうこともあります。それはオブジェクト指向プログラミングの衰退ではなく発展と深化であるように、私には見えます * 「オブジェクト指向プログラミング」自体が新しいパラダイムシフトによって超克され、消えていくことがあるかというと、ありえますが今のところその兆しは見えません * ところで、ときどきなにか勘違いしている人がいるのですが、オブジェクト指向プログラミングと関数的プログラミングは両立します。関数的プログラミングはオブジェクト指向プログラミングを塗り替えないでしょう * というわけで、なにかが失敗したとか間違っていたとかではなく、しかし今までとは異なる考え方によって物事が発展することがある、ということではないかなと思います * OOPがスケールしないというのは初耳です。そのような発言はありうるとは思いますが、言語やフレームワークに強く依存する話なので手放しには評価しないほうがよいでしょう。たとえばGoogle ChromeはC++でオブジェクト指向プログラミングで書かれていますが、「スケール」という点で問題になっているとは聞いたことがありません * ウェブ開発に限っても、たとえばcookpadはRuby on Railsのモノリスであると言われます。これにオブジェクト指向プログラミングが使われていないとは全く考えられませんし、オブジェクト指向プログラミングであることがスケーラビリティの問題になっているとは聞いたことがありません。同様に、RubyやPythonで書かれた大規模ウェブサービスはたくさんあり、同様の議論が可能です * 想定していたような回答とは全く異なるものでしょうが、なんにも回答がつかないのもさみしいものですし、ひとまずこんなところでいかがでしょうか

takano32:OOP は問題を解決する手段のうちのひとつであって、OOP を深く理解している方たちは「成功」だとか「失敗」などは考えておらず、目の前の問題にたいして OOP が解決の手段として優れているときに OOP をたまたま採用するだけです。 ある問題に対して OOP が適しているか、不適であるのかの判断がブレるエンジニアは OOP をよく理解していないだけではないでしょうか。OOP を深く理解しているエンジニアは OOP が適している問題領域については過去も、現在も、未来も継続して OOP を適用し続けますし、そうでない問題領域ならば他の手段で解決するだけです。 周囲で廃っているので「失敗」とされていても、その独自の見解に興味がありません。OOP の「成功」や「失敗」を考えて OOP を使っているわけではないのです。

kmizu:まず、現状認識として、ですが、OOPは全くもって廃れていません。たとえば、現状メジャーな言語にはC++、Java、Swift、C#、Go、JavaScript、Python、Rubyなどがありますが、この内「オブジェクト指向」の面からやや微妙なポジションなのはGoくらいでしょう。 　言語だけではありません。各言語のAPIを調べてみるとわかりますが、やはりOOP的な「オブジェクトへのメソッド呼び出し」を基本とするようなAPI設計が主流です。Java SEの標準ライブラリにしろ、.NETの標準ライブラリにしろ、JavaScriptの標準ライブラリにしろ、Rubyの標準ライブラリにしろ「オブジェクト指向的である」と言わざるを得ません。 　その点で質問者様の現状認識はあまり正しくないということは申し上げて起きたいと思います。ただし、以前より「オブジェクト指向が万能である」という風潮が薄れていることも確かです。 　たとえば、関数型プログラミング言語由来である（広義の）ラムダ式（無名関数）は今やほとんどのプログラミング言語に搭載されていますが、原理的にはオブジェクトがあればラムダ式は不要なはずであり、そのような「オブジェクトがあれば不要なはず」の機能がオブジェクト指向プログラミング言語に輸入されていることを考えても、もはやオブジェクト指向が万能ではないことは明らかなように感じます。 　それ以降についてはおっしゃりたいことが不明瞭ですが、一つ一つ分けてお答えします。 > 問題解決の方法として、データとその操作をひとまとめにするのは自然な考えで、なるべくなら静的なコードとして扱いたい欲求から、型としてのクラスを定義することも悪くないと思います。この方向性では異なるデータを結び付ける操作を扱うにはぎこちなくなる気がしますが、これは大きな欠点になりますでしょうか？ おそらくは、全く異なる種類の引数が複数あるような場合に「データと操作をひとまとめにする」考えは欠点となるのでは？という疑問かと思いますがこの点についてはオブジェクト指向の欠点と言えます。 たとえば、プログラミング言語処理では抽象構文木（AST）とそのASTを変換、あるいは解釈するコンポーネントをどうやって結びつけるかが設計上の鍵になりますが、素朴に「抽象構文木に操作をくっつける」アプローチ（Interpreterパターンと呼ばれます）は概ね保守性を悪化させます。そのためか、Intrerpreterパターンは広く採用はされておらず、Visitorパターンと呼ばれるパターンの変種を広く見かけます。Visitorパターンでは、抽象構文木には「抽象構文木をたどって、操作を行う」Visitorを受け入れるメソッドだけを定義して、Visitor側で抽象構文木をたどって操作を行うアプローチが主流です。VisitorパターンはいわゆるGoFパターンの一つで、広い意味でいえばオブジェクト指向的ですが「データと操作をひとまとめにする」をオブジェクト指向の要件とした場合、Visitorパターンはどちらかといえば「より非オブジェクト指向的な」パターンです。 > 継承によるコードの再利用性を得るという考えや、クラスをモジュールと見なしてクラス単位での再利用を狙うという考えは確かに全くの失敗で、再利用の実現方法としてはうまく行っていないでしょう。 現実を見る限り「全くの失敗」とは言えません。むしろ「ある程度の成功を収めた」が、クラス＝モジュールという考え方だけで全てをやろうとするには無理があったと言うべきでしょう。 実際、各種言語の標準ライブラリはクラスベースで定義されていることが多いですが、私たちは「現に」そのようなライブラリのソースコードを見ずに使うことができていますから、つまり再利用できているわけです。 もちろん、これは標準ライブラリやサードパーティのライブラリの場合であって、たとえば単一のWebサービスを提供するプロジェクト内部での再利用性を促進するために継承を使うというのは一般的には成功しづらいように感じます。 クラスベースで再利用可能なモジュールを作るには熟考が必要である（たとえば、どのオブジェクトがどのオブジェクトを「持つ」かというのを考えるだけでも結構な時間がかかります）のに対して、現実にはそのための十分な時間が与えられていないため、プロジェクト内部でのコード再利用にはオブジェクト指向はあまり向かないのかなとは感じます。そのようなケースでは「継承によるコードの再利用」よりもまずは関数ベースの再利用を検討し、関数ベースの再利用だけではうまくいかなくなったときにクラスベースの再利用を検討した方がいいように感じます。 > 実装の隠蔽による利益はあまり理解できない点ですが、これは現代でも奨励される作法でしょうか。例えばデータフィールドへのアクセサを定義し、そのインタフェースのみ公開することで状態の内部表現の変更に耐性を持つ こちらは典型的な誤解です。単純にデータフィールドへのアクセサを定義してしまえば、それは「実装を公開した」のとほぼ同義です。実装の隠蔽というのは「どのようなフィールドが実際にあるとかを意識しないでいい」ことなので、とにかくアクセサを定義しようというアプローチは端的に実装の隠蔽ができていません。これはある程度経験を積んだオブジェクト指向プログラマーの間では常識的な話です。 というわけで、オブジェクト指向プログラミングやオブジェクト指向的な設計に問題がないわけではないのですが、質問者様が考えられている程にはOOPは廃れていません。 ただ、最後にまとめてくださった * 異なるクラスのインスタンス同士の相互作用を書きづらい * 多相性によって実行時の動作が予測しづらくなる * 実装の継承が危険 * クラスが肥大化して再利用性や意味論を損ないがち * スケールしない（？） の内、最初の3点についてはオブジェクト指向のデメリットとしてよく挙がることも事実です。クラスの肥大化については、他の手法でも起こり得るのでオブジェクト指向特有の話とするのは無理があります。 ともあれ、ある手法の欠点が広く認識されるようになったことと、その手法が廃れることは全く別の話ですから、そこは混同されない方がいいのではないかと思います。