私はかなり強いオブジェクト指向のバックグラウンドを持っています。OODとOOPの利点は私にとって第二の性質ですが、最近、手続き型プログラミングの習慣に縛られた開発ショップにいることに気づきました。実装言語にはいくつかのOOP機能があり、それらは最適な方法で使用されません。
更新：私と同じように、誰もがこのトピックについて意見を持っているようですが、質問は次のとおりです。
手続き型プログラミング言語とオブジェクト指向言語を使用したソフトウェア開発のコストを対比する優れた比較研究はありますか？
一部のコメント提供者は、リンゴとオレンジを比較しようとすることの疑わしい性質を指摘しており、正確に測定することは非常に難しいが、おそらく完全に不可能ではないことに同意します。
これらの質問のほとんどすべては、個々のプログラマーの生産性が 1 桁以上異なるという問題によって混乱しています。たまたま生産性 x のグループの 1 つである OO プログラマーと、10x プログラマーである「手続き型」プログラマーがいる場合、OO が何らかの意味で高速であっても、手続き型プログラマーが勝つ可能性があります。
また、現実的なプロジェクトでは、コーディングの生産性は通常、総作業量の 10 ～ 20% に過ぎないという問題もあります。仮に 10 倍のプログラマー、または無限に高速なプログラマーでさえ、全体の労力を 10 ～ 20% 以上削減することはできません。
Fred Brooks の論文「No Silver Bullet」を見たことがあるかもしれません。
Google をいじった後、この論文を見つけました。私が使用した検索用語は、生産性オブジェクト指向です。
冒頭の段落は続けて言います
オブジェクト指向テクノロジの導入は、新しい大規模な商用プロジェクトの全体的な生産性を妨げないように見えますが、最初の 2 つの製品世代では改善されないようにも見えます。実際には、支配的な影響力はビジネス ワークフローであり、方法論ではありません。
特定の状況ではオブジェクト指向プログラミングの方が優れているが、それ以外の状況では中立であることがわかると思います。会社の CAD/CAM アプリケーションをオブジェクト指向フレームワークに変換することで上司を納得させたのは、それが役立つ正確な領域を正確に示したことです。焦点は方法論全体ではなく、私たちが抱えていた特定の問題を解決するのにどのように役立つかということでした. 私たちにとっては、シェイプ、レポート、およびマシン コントローラーを追加し、コレクションを使用して古い設計のメモリ制限を取り除くための拡張可能なフレームワークが必要でした。
オブジェクト指向または手続き型は、異なる開発方法を提供しますが、どちらも管理が不十分な場合、コストがかかる可能性があります。
どちらも一番いい人がやってくれるとすれば、コスト的には同じくらいの結果になるのではないかと思います。
コストの違いは、機能を追加して現在の機能を変更する必要があるメンテナンス フェーズをどのようにするかによると思います。手続き型プロジェクトは、自動テストが難しく、他の部分に影響を与えずに拡張できる可能性が低く、部分ごとに概念を理解するのがより困難です (まとまりのある部分は必要に応じてグループ化されていないため)。
したがって、OO コストは長期的にはプロシージャルに比べて低くなると思います。
S.Lott は「反復不可能な実験」現象について言及していたと思います。つまり、アプリケーション X を手続き的に記述してから、時間を巻き戻して OO と記述して、違いを確認することはできません。
同じアプリを 2 つの異なる方法で 2 回作成することもできますが、
したがって、実際には比較の直接的な根拠はありません
同様の理由で、実験的研究も同様に役に立たない - 異なるアプリケーション、異なるチームなど.
パラダイム シフトは困難であり、ごく一部のプログラマーは決して移行できない可能性があります
あなたが自分のやり方で自由に開発できるなら、解決策は簡単です: あなたのやり方で物事を開発し、同僚があなたが彼らの周りで円を描いてコードを書いていることに気づき、あなたのコードがそれほど頻繁に壊れないなど、彼らがあなたに尋ねたとき.次に、OOP を教えます (TDD やその他の適切なプラクティスを使用することもできます)。
そうでない場合は、履歴書を磨く時が来るかもしれません... ;-)
良いアイデア。直接比較。アプリケーションXを手続き型スタイルとオブジェクト指向スタイルで記述し、何かを測定します。開発コスト。投資収益率。
同じアプリケーションを2つのスタイルで作成するとはどういう意味ですか？別のアプリケーションになりますね。手続き型の人々は、オブジェクト指向の人々が継承、メッセージング、またはカプセル化を使用したときに不正行為をしていることを躊躇します。
そのような比較はあり得ません。アプリケーションの2つの「バージョン」を比較する根拠はありません。それは、リンゴやオレンジが果物であることに費用対効果が高いかどうかを尋ねるようなものです。
そうは言っても、他の人が実際に見ることができるものに焦点を当てる必要があります。
うまくいくものを作る時が来ました。
バグと問題の割合。
あなたのアプローチがより良い場合、あなたは成功するでしょう、そして人々はその理由を知りたがるでしょう。
あなたがOOがあなたの成功につながると説明するとき...まあ...あなたは議論に勝ちました。
鍵は時間です。新しい機能を追加したり、既存の機能を修正したりするために、会社がデザインを変更するのにどのくらいの時間がかかりますか。あなたが行う研究は、その分野に焦点を当てるべきです。
私の会社では、90 年代半ばに VB3 を使用して作成された CAM ソフトウェアのイベント ドリブン プロシージャ指向の設計を行っていました。ソフトウェアを新しいマシンに適応させるには長い時間がかかりました。バグ修正と新機能の効果をテストするための長い時間。
VB6 の登場により、現在の設計と、テストと適応の問題を修正した新しい設計をグラフ化することができました。非技術系の上司は、私がやろうとしていることをすぐに把握しました。
重要なのは、なぜ OOP がプロジェクトに利益をもたらすのかを説明することです。Fowler によるリファクタリングやデザイン パターンなどを使用して、新しいデザインが作業時間を短縮する方法を示します。ポイント A からポイント B に移動する方法も含めます。