近年、ソフトウェア開発の現場においてオブジェクト指向はもう古いのではないかという議論が再び活発になっています。
かつては設計の標準的なパラダイムとして広く受け入れられていたオブジェクト指向ですが、クラウドネイティブ開発や関数型プログラミングの台頭、さらにはマイクロサービスアーキテクチャの普及によって、その前提が揺らぎ始めているのが現実です。
特に、現代のシステムは単一の巨大なオブジェクトモデルで表現するよりも、疎結合で独立した機能単位の組み合わせとして設計される傾向が強くなっています。
その結果、オブジェクトが持つ状態と振る舞いを一体化するという従来の思想が、必ずしも最適解ではなくなってきているのです。
また、以下のような技術的背景が「オワコン説」を後押ししていると考えられます。
- 関数型プログラミングの実用性向上による状態管理パラダイムの変化
- 分散システム前提のアーキテクチャ設計の一般化
- コンテナ技術によるプロセス分離の標準化
- 宣言的UIフレームワークの普及
- 型システムと静的解析の高度化による設計思想の変化
ただし、ここで重要なのは「オブジェクト指向が完全に不要になった」という単純な結論ではありません。
むしろ、適用領域がより明確に分化し、適材適所での使い分けが求められるフェーズに入ったと捉えるべきです。
本記事では、こうした技術的背景を整理しながら、オブジェクト指向の現在地を論理的に再評価していきます。
オブジェクト指向は本当にオワコンなのか？再評価される背景
オブジェクト指向は長らくソフトウェア設計の中心的なパラダイムとして扱われてきましたが、近年になって「オワコンではないか」という議論が散見されるようになっています。
ただし、この議論は単純な流行廃りではなく、ソフトウェア開発の前提条件そのものが変化していることに起因しています。
結論から言えば、オブジェクト指向が完全に不要になったわけではありません。
むしろ、適用領域が明確に限定されつつあり、設計思想の一つとして再定義されている段階と捉えるのが妥当です。
その背景を理解するためには、まず従来のオブジェクト指向が前提としていた世界観を整理する必要があります。
オブジェクト指向は本質的に「状態」と「振る舞い」を一体化し、現実世界のモデリングをソフトウェアに写像するアプローチです。
この思想は単一アプリケーションやモノリシックなシステムにおいては非常に強力でした。
しかし現代のシステムは、以下のように構造が大きく変化しています。
- 分散システムの標準化
- マイクロサービスアーキテクチャの普及
- クラウドネイティブ環境への移行
- フロントエンドとバックエンドの分離
これらの変化により、「一つの巨大なオブジェクトモデルで世界を表現する」というアプローチが必ずしも合理的ではなくなってきています。
特に重要なのは、状態の所在がアプリケーション内部から外部へ移動している点です。
例えばクラウド環境では、状態はデータベースや分散ストレージに保持され、アプリケーションはステートレスに設計されることが一般的です。
この時点で、オブジェクトが内部に状態を抱えるという設計思想は相対的に重要性を下げます。
簡単な例として、従来型のオブジェクト指向設計を考えます。
class User:
def __init__(self, name):
self.name = name
def rename(self, new_name):
self.name = new_name
このような設計は直感的ですが、分散環境では「状態変更の追跡」「並行更新」「整合性管理」といった問題が顕在化します。
その結果、状態を持つオブジェクトよりも、不変データと関数の組み合わせが選好されるケースが増えています。
さらに関数型プログラミングの影響も無視できません。
純粋関数とイミュータブルなデータ構造は、副作用を排除し、システムの予測可能性を高めます。
これは大規模分散システムにおいて極めて重要な性質です。
また、開発ツールやフレームワークの進化もこの流れを後押ししています。
TypeScriptやRustのような言語は、オブジェクト指向的な表現を許容しつつも、型システムや関数的な抽象化を強く取り入れています。
結果として、開発者は「クラス中心」ではなく「データフロー中心」で設計を考えるようになってきています。
このように見ていくと、「オブジェクト指向は終わった」というよりも、単一の支配的パラダイムではなくなったという表現がより正確です。
現代のソフトウェア設計では、オブジェクト指向、関数型、イベント駆動などが状況に応じて使い分けられています。
重要なのは思想の優劣ではなく、問題領域に対する適合性です。
オブジェクト指向は依然としてGUIアプリケーションやドメインモデルの表現において有効ですが、クラウドネイティブや大規模分散システムでは他のアプローチと組み合わせて使うことが前提になっています。
したがって本質的な問いは「オブジェクト指向は古いか」ではなく、「どの文脈でどのパラダイムを選択すべきか」という設計判断の問題に移行していると言えます。
マイクロサービスアーキテクチャが変えるソフトウェア設計とオブジェクト指向の役割
マイクロサービスアーキテクチャの普及は、ソフトウェア設計における前提条件を大きく変化させました。
従来のオブジェクト指向は、単一のアプリケーション内部で整合性の取れたドメインモデルを構築することに強みを持っていましたが、現在のシステムはそれとは異なる方向に進化しています。
特にクラウド環境やコンテナ技術の普及により、アプリケーションは「一枚岩」としてではなく、複数の独立したサービスの集合として設計されるようになっています。
この変化の本質は、単なる技術トレンドではなく、設計単位そのものの再定義にあります。
オブジェクト指向がクラスやオブジェクトを最小単位としていたのに対し、マイクロサービスではサービスそのものが最小の独立単位になります。
その結果、設計の焦点は「内部構造のモデリング」から「サービス間の通信設計」へと移行しています。
単一システムから分散システムへの移行
従来のモノリシックアーキテクチャでは、アプリケーション全体が一つのプロセスまたは単一のデプロイ単位として動作していました。
この場合、オブジェクト指向は非常に自然な抽象化手段であり、クラス設計を中心にシステム全体を構築することが可能でした。
しかし分散システムでは状況が根本的に異なります。
各機能が独立したサービスとして動作し、ネットワーク越しに通信することが前提となるため、内部のオブジェクト構造よりも外部インターフェースの設計が重要になります。
この変化を整理すると、以下のような対比になります。
| 観点 | モノリシック | マイクロサービス |
|---|---|---|
| 設計単位 | クラス・オブジェクト | サービス |
| 状態管理 | アプリ内部 | 外部ストレージ |
| 結合度 | 高い | 低い |
| スケーリング | 全体単位 | 個別単位 |
このように比較すると、オブジェクト指向が前提としていた「密結合な内部構造」は、分散環境ではむしろ制約になり得ることが分かります。
また、分散システムではネットワーク遅延や部分障害といった問題が常に存在するため、設計思想そのものが変わります。
例えば、あるサービスの内部でオブジェクト指向的に完結していたロジックも、今ではAPI越しに分割され、非同期処理やイベント駆動の形に再構築されることが一般的です。
このような環境では、オブジェクト指向は「内部実装の一部」としては依然として有効ですが、システム全体を統合する主軸ではなくなっています。
むしろ、サービス内部のドメインロジックを整理するための手段として位置付けられることが多いです。
したがって、マイクロサービスアーキテクチャの普及はオブジェクト指向を否定するものではなく、その適用範囲を明確に限定し、役割を再定義する動きであると理解するのが適切です。
関数型プログラミングの台頭とオブジェクト指向の相対的な立ち位置
関数型プログラミングの普及は、ソフトウェア設計における思考様式そのものを大きく変えつつあります。
従来のオブジェクト指向が「状態」と「振る舞い」を一体化してモデル化するのに対し、関数型プログラミングは状態を極力排除し、入力から出力への変換として処理を定義する点に特徴があります。
この違いは単なる構文上の差異ではなく、システムの複雑性をどう制御するかという設計哲学の違いに直結しています。
特に大規模なシステムや分散環境においては、状態の共有と変更がバグの主要因となりやすく、その管理コストが急激に増大します。
そのため、状態を局所化または排除する関数型のアプローチは、予測可能性とテスト容易性の観点から高く評価されるようになっています。
状態を持たない設計思想のメリット
状態を持たない設計思想、いわゆるステートレスなアプローチの最大の利点は、システムの振る舞いが入力のみで決定される点にあります。
これにより、関数の出力は常に同じ入力に対して同じ結果を返すため、再現性が極めて高くなります。
これはデバッグやテストの観点で非常に重要な性質です。
例えば、次のような純粋関数を考えます。
def add_tax(price):
return price * 1.1
この関数は外部状態に依存しないため、どの環境でも同じ結果を保証します。
一方でオブジェクト指向的な設計では、インスタンス変数や外部サービスに依存するケースがあり、同じメソッド呼び出しでも結果が変わる可能性があります。
この差異が、大規模システムにおける複雑性の差として蓄積されていきます。
さらに、状態を持たない設計は並列処理との相性が非常に良いという利点があります。
複数のスレッドやプロセスが同時に関数を実行しても、共有状態が存在しないため競合状態が発生しにくくなります。
これはクラウド環境や分散処理基盤において特に重要な特性です。
また、関数型プログラミングではデータの不変性が重視されます。
不変データ構造を用いることで、ある処理が他の処理に副作用を及ぼすリスクを排除できます。
この設計はコードの安全性を高めるだけでなく、システム全体の推論可能性を向上させます。
オブジェクト指向が持つ状態中心の設計は、ドメインモデリングには適していますが、状態が複雑に絡み合う現代的な分散システムでは、その管理が難しくなる傾向があります。
そのため、関数型プログラミングの思想は単なる代替手段ではなく、複雑性を制御するための補完的なアプローチとして重要性を増しています。
結果として、現代のソフトウェア設計ではオブジェクト指向と関数型のどちらかを選択するのではなく、それぞれの特性を理解した上で適切に組み合わせることが求められています。
コンテナ技術とクラウドネイティブ開発がもたらす設計思想の変化
コンテナ技術とクラウドネイティブ開発の普及は、ソフトウェア設計の前提を根本から変えています。
従来のオブジェクト指向は、単一アプリケーション内部での構造化に強みを持っていましたが、現在ではアプリケーションそのものが「どのように実行されるか」という観点から再設計されるようになっています。
特にコンテナによる実行環境の標準化は、開発と運用の境界を大きく曖昧にしました。
この変化の本質は、コードの構造ではなく実行環境の一貫性にあります。
どの環境でも同一の動作を保証するために、コンテナは依存関係やランタイムを含めた完全な実行単位として扱われます。
その結果、従来のようにアプリケーション内部のオブジェクト設計に過度に依存する必要性が相対的に低下しています。
AWSなどクラウド基盤における実行環境の標準化
クラウド基盤、特にAWSのような大規模クラウドプロバイダの登場は、実行環境の標準化を加速させました。
かつてはサーバーごとに異なるOS設定やライブラリ依存が問題となり、アプリケーションは環境差異を吸収する必要がありました。
しかし現在では、コンテナオーケストレーションを前提とすることで、実行環境はほぼ均質化されています。
この標準化の影響は設計思想にも及びます。
アプリケーションは「特定のサーバー上で動作するもの」ではなく、「どのノードでも同一に起動できる単位」として扱われるようになりました。
その結果、オブジェクト指向的な内部構造よりも、デプロイ可能性やスケーラビリティが設計の優先順位として上位に来るようになっています。
例えば、クラウド環境では以下のような構成が一般的です。
API Gateway → コンテナ化されたサービス → データベース
このような構造では、各サービスは独立したコンテナとして動作し、必要に応じて自動スケーリングされます。
このとき重要なのは内部のクラス設計ではなく、サービス単位での責務分離とインターフェース設計です。
さらに、AWSのようなクラウド基盤ではインフラ管理の多くが抽象化されています。
これにより開発者はサーバー管理から解放され、アプリケーションロジックの設計に集中できる一方で、システム全体の設計はより抽象度の高いレイヤーで考える必要が出てきます。
このような環境では、オブジェクト指向は依然としてアプリケーション内部のモデリング手法として有効ですが、インフラ全体を設計する主要なパラダイムではなくなっています。
むしろコンテナとクラウドの抽象化レイヤーの上で、どのようにサービスを分割し、どのようにスケールさせるかという問題の方が重要になっています。
結果として、クラウドネイティブ開発の進展は、ソフトウェア設計の重心を「コードの構造」から「実行と運用の構造」へと移動させたと言えます。
宣言的UIとフロントエンド開発におけるパラダイムシフト
フロントエンド開発はここ数年で大きなパラダイムシフトを経験しています。
その中心にあるのが、命令型UIから宣言的UIへの移行です。
従来のオブジェクト指向的なフロントエンド開発では、DOM操作を逐次的に記述し、状態の変化に応じて画面を手続き的に更新する設計が一般的でした。
しかしこの方法は、状態の複雑化に伴ってコードの可読性と保守性が急速に低下するという問題を抱えていました。
一方で現代のフレームワークは、UIを「状態の関数」として定義する宣言的アプローチを採用しています。
この変化は単なる書き方の違いではなく、UI設計の抽象度そのものを引き上げるものです。
命令型から宣言型への移行がもたらす影響
命令型UIでは、開発者は「どのように変更するか」を逐一記述する必要がありました。
例えばDOMを直接操作するコードは、状態変化ごとに細かな手続きが必要となり、変更の影響範囲が局所化しにくいという問題があります。
const button = document.createElement("button");
button.textContent = "Click";
button.onclick = () => {
document.body.style.backgroundColor = "blue";
};
document.body.appendChild(button);
このようなコードは直感的ではありますが、アプリケーションが大規模化すると状態管理が破綻しやすくなります。
特に複数のUI要素が相互に依存する場合、変更の追跡が困難になります。
これに対して宣言的UIでは、「何を表示したいか」を記述し、「どのように更新するか」はフレームワークに委譲されます。
例えばReactのような仕組みでは、UIは状態の関数として定義されます。
function App({ isActive }) {
return (
<div style={{ backgroundColor: isActive ? "blue" : "white" }}>
Hello World
</div>
);
}
このアプローチの本質は、UI更新の責務を開発者から切り離し、状態と描画の関係を宣言的に表現する点にあります。
その結果、コードはより予測可能になり、変更の影響範囲も明確になります。
さらに重要なのは、この変化がオブジェクト指向的なUI設計の役割を変えた点です。
従来はUIコンポーネントをクラスとして設計し、内部に状態と振る舞いを持たせることが一般的でした。
しかし宣言的UIでは、状態管理は外部化され、コンポーネントは純粋なレンダリング関数として扱われる傾向が強まっています。
この構造の変化は、設計思想としてのオブジェクト指向を完全に否定するものではありませんが、UIレイヤーにおける適用範囲を明確に縮小しています。
結果として、フロントエンド開発では「クラスで設計するUI」から「状態駆動の関数としてのUI」へと重心が移動していると言えます。
この移行は単なる技術的進化ではなく、複雑なUIを扱うための認知的負荷を下げるための必然的な進化であり、現代のフロントエンド設計においては不可逆的な流れになっています。
静的型付けと型システムの進化が設計に与える影響
静的型付けと型システムの進化は、ソフトウェア設計の品質そのものに直接的な影響を与える要素として再評価されています。
従来のオブジェクト指向においても型の概念は存在していましたが、その役割は主にデータ構造の制約やインターフェースの定義に限定されていました。
しかし現代の型システムはそれよりもはるかに高度であり、設計段階そのものに介入するレベルに進化しています。
特にTypeScriptやRustのような言語では、型は単なるエラー検出の仕組みではなく、設計そのものを駆動する中心的な要素として機能しています。
これにより、コードを書く前に構造的な誤りを排除できるため、設計の初期段階から品質が担保されるようになっています。
型安全性と設計品質の関係性
型安全性とは、プログラムが実行時ではなくコンパイル時に整合性を検証できる性質を指します。
この性質は単なるバグ防止にとどまらず、設計そのものの健全性を保証する役割を持っています。
特に大規模なシステムにおいては、型の不整合は致命的な障害につながるため、その重要性は非常に高いです。
例えば、以下のようなTypeScriptのコードを考えます。
type User = {
id: number;
name: string;
};
function greet(user: User) {
return `Hello, ${user.name}`;
}
このように型を明示することで、関数が期待する入力と出力が明確になり、誤ったデータの流入をコンパイル時に防ぐことができます。
これはオブジェクト指向における動的なメソッド呼び出しと比較すると、設計の透明性が大きく向上していることを意味します。
型安全性のもう一つの重要な側面は、リファクタリングの容易さです。
型システムが存在することで、変更の影響範囲が静的に解析可能となり、予期しない副作用を未然に防ぐことができます。
これは長期運用されるシステムにおいて極めて重要な性質です。
また、現代の型システムは単純なプリミティブ型のチェックにとどまらず、ジェネリクスや代数的データ型、さらには型レベル計算といった高度な機能を備えています。
これにより、設計そのものを型で表現することが可能になりつつあります。
このような進化により、設計品質は経験則やレビューに依存するものから、型によって機械的に保証されるものへと変化しています。
その結果、オブジェクト指向的な「設計の正しさを人間が判断するモデル」から、「型システムが制約として設計を導くモデル」へと重心が移動しています。
最終的に重要なのは、型は単なる安全装置ではなく、設計そのものを構造化する言語であるという認識です。
この視点に立つことで、ソフトウェア設計の質は大きく向上し、複雑なシステムにおいても一貫性を保つことが可能になります。
モノリスから分散システムへ：アーキテクチャの分裂と再統合
ソフトウェアアーキテクチャは、モノリシックな構造から分散システムへと大きく移行してきました。
この変化は単なる実装方式の違いではなく、設計思想そのものの転換を意味しています。
従来のモノリスでは、アプリケーションは単一のプロセス内で完結し、オブジェクト指向を中心とした内部設計がそのままシステム全体の構造を規定していました。
しかし現代では、機能ごとに独立したサービスへと分割され、それぞれがネットワーク越しに連携する形が主流になっています。
この変化の背景には、スケーラビリティ要求の増大と、クラウド環境の標準化があります。
特にトラフィックの変動が激しいサービスでは、全体をスケールさせるよりも、特定の機能単位でスケールさせる方が効率的です。
そのため、アーキテクチャは必然的に分割方向へ進化しました。
データベースとサービス分割の新しい関係
分散システムへの移行において最も重要な変化の一つが、データベースとサービスの関係性の再定義です。
モノリシックな構成では、単一のデータベースを複数のモジュールが共有することが一般的でした。
しかしマイクロサービスアーキテクチャでは、各サービスが独立したデータストアを持つ設計が推奨されるようになっています。
この変化は単なる技術的な分離ではなく、責務の明確化という設計原則に基づいています。
各サービスが独自のデータベースを持つことで、データの所有権が明確になり、変更の影響範囲を局所化できます。
一方で、分散トランザクションやデータ整合性の問題が新たな課題として浮上します。
例えば従来型の設計では以下のような構造が一般的でした。
ユーザーサービス
注文サービス
決済サービス
→ 単一データベースを共有
この構造では整合性は取りやすいものの、スケーリングや変更の影響範囲が大きくなるという問題があります。
一方で分散システムでは次のような構造になります。
ユーザーサービス → ユーザーデータベース
注文サービス → 注文データベース
決済サービス → 決済データベース
この構造により各サービスは独立性を獲得しますが、その代償としてデータの一貫性はネットワーク越しの同期やイベント駆動設計に依存することになります。
この変化はオブジェクト指向の観点から見ると重要な意味を持ちます。
従来はオブジェクト間の関係性として表現されていたものが、現在ではサービス間通信として再定義されています。
つまり、設計の中心はオブジェクトからサービスへ、そしてインメモリの関係性からネットワーク越しの関係性へと移行しています。
結果として、データベース設計はもはや単一アプリケーションの内部構造ではなく、システム全体のアーキテクチャ設計の一部として扱われるようになっています。
この視点の変化こそが、モノリスから分散システムへの移行における本質的な転換点であると言えます。
現場でのオブジェクト指向の実用性と限界のリアル
オブジェクト指向は長い間、実務システム開発の中心的な設計パラダイムとして機能してきました。
現場レベルで見ても、その有用性は依然として明確に存在します。
特にドメイン駆動設計のように、現実世界の概念をソフトウェア上にマッピングするアプローチでは、オブジェクト指向の「責務分離」や「カプセル化」といった概念は非常に有効です。
しかし一方で、現代的な開発環境においては、その限界もまた明確になりつつあります。
まず実務におけるオブジェクト指向の強みは、コードの構造化能力にあります。
複雑な業務ロジックをクラス単位で分割し、関連するデータと振る舞いをまとめることで、一定の可読性と保守性を確保できます。
これは特に中規模程度のアプリケーションにおいて効果を発揮します。
例えば典型的なドメインモデルは以下のように表現されます。
class Order:
def __init__(self, items):
self.items = items
self.status = "pending"
def confirm(self):
self.status = "confirmed"
このような設計は直感的であり、業務要件との対応関係も明確です。
そのためチーム開発においても理解の共有がしやすいという利点があります。
しかし、システムが大規模化し、分散化が進むにつれて状況は変化します。
オブジェクト指向の問題は、状態と振る舞いを密結合させる点にあります。
単一プロセス内であれば問題にならなかった状態管理が、分散環境では複雑な同期問題や整合性の課題を引き起こします。
特にクラウドネイティブ環境では、アプリケーションはステートレスであることが前提となるため、オブジェクト内部に状態を保持する設計はそのままでは適用しづらくなります。
このギャップが、現場での設計思想の揺れを生み出しています。
また、テスト容易性の観点でも課題があります。
オブジェクト指向設計では、依存関係がオブジェクト内部に隠蔽されるため、ユニットテストの際にモックやスタブが複雑化する傾向があります。
これはテストコードの可読性と保守性を低下させる要因となります。
さらに、現代の開発ではフロントエンドとバックエンドが分離され、API中心の設計が主流となっています。
この環境では、オブジェクトの内部構造よりもデータ転送単位としての設計が重要になります。
その結果、オブジェクト指向の中心概念である「オブジェクト内部に責務を閉じる」という発想は相対的に重要性を失いつつあります。
ただし重要なのは、オブジェクト指向が不要になったわけではないという点です。
むしろ現場では、適用範囲が明確に整理されてきています。
ビジネスロジックの表現やドメインモデリングには依然として有効であり、特に複雑なルールを持つシステムでは欠かせない手法です。
一方で、インフラ層や分散システム設計においては、関数型的なアプローチやイベント駆動設計の方が適しているケースが増えています。
つまり現場の実態としては、オブジェクト指向は「万能な設計思想」ではなく、「特定領域に強い設計手法」として再定義されていると言えます。
最終的に重要なのは、思想に依存するのではなく、問題領域に応じて適切な設計パラダイムを選択する能力です。
その意味で、オブジェクト指向の実用性は依然として高い一方で、その限界もまた明確に理解されるべき段階に来ていると考えられます。
まとめ：オブジェクト指向は終わったのか、それとも形を変えただけなのか
オブジェクト指向が「終わったのか」という問いは、実務経験と現代アーキテクチャの変化を踏まえると、単純な二択では説明できない性質を持っています。
結論から言えば、オブジェクト指向は消滅したのではなく、その役割と適用領域が再定義され、他のパラダイムと共存する形へと進化しています。
かつてオブジェクト指向は、ソフトウェア設計の中心原理として機能していました。
クラス設計を通じて現実世界の概念をモデル化し、状態と振る舞いを統合することで複雑性を制御するというアプローチは、単一システムやモノリシックアーキテクチャにおいて非常に有効でした。
しかし現代では、クラウドネイティブ化、分散システムの標準化、関数型プログラミングの普及といった複数の要因により、設計の重心が大きく移動しています。
特に重要なのは、システムの基本単位がクラスからサービスへと移行した点です。
この変化により、オブジェクト内部で完結していた責務は、ネットワーク越しに分散されるようになりました。
その結果、オブジェクト指向の強みであったカプセル化や局所的な状態管理は、システム全体ではなく、サービス内部の局所的な最適化手段として再位置付けされています。
また、現代の開発環境では以下のような複数のパラダイムが併存しています。
- オブジェクト指向によるドメインモデリング
- 関数型による状態排除と純粋性の確保
- イベント駆動による非同期処理の制御
- コンテナベースのインフラ抽象化
このように、単一の思想で全てを設計する時代はすでに終わり、複数の設計思想を適材適所で組み合わせることが前提となっています。
ここで重要なのは、オブジェクト指向を「古い」と評価することではなく、その適用範囲を正確に理解することです。
例えばビジネスロジックの複雑なドメインモデリングにおいては、依然としてオブジェクト指向は有効です。
一方で、分散トランザクションや高スケーラビリティを要求される領域では、関数型やイベント駆動の方が合理的であるケースが増えています。
この違いを整理すると、設計パラダイムは優劣ではなく「抽象化のレベル」と「問題領域との適合性」によって評価されるべきであることが分かります。
オブジェクト指向はその中で、ローカルなモデリング手法としての価値を維持し続けていると言えます。
つまり本質的な答えは、オブジェクト指向は終わったのではなく、単一支配的な立場を失い、より広い設計エコシステムの一部へと再配置されたということです。
この変化は衰退ではなく、ソフトウェア工学の成熟の一形態と捉えるのが妥当です。
今後の設計において重要になるのは、特定の思想に依存することではなく、それぞれのパラダイムの特性を理解し、問題に応じて適切に選択できる判断力です。
その意味で、オブジェクト指向は今なお有効なツールであり続けていますが、それ単体で完結する時代はすでに過去のものになったと言えます。
コメント