手続き型（命令型）ベースのアプリケーションを正常に設計および構築できますか？

Question

手続き型で、高レベルの整合性と効率性を維持している今日のアプリケーションの例を提供できますか？命令型システムを正常に構築および保守する方法の例を提供する書籍、チュートリアル、またはリンクはありますか？この分野でガイダンスを提供する場合、どのように構成すべきかについてどのようなヒントを提供しますか？ OOPは手続き型プログラミングの自然な進行として提示されることが多いため、お願いしますが、それが常に当てはまるとは信じられません。

Answer 1

手続き型アプリケーションの成功例??

たとえば、Linuxカーネルのようなものですか？ BSDカーネル？ Apache Webサーバー？ Unixユーザーランドユーティリティの大部分は？そのようなアプリケーション？

もちろん、OOP手法は、ソフトウェア内の組織、保守性、および抽象化において価値がありますが、今日でも、OOPは今日書かれたすべてのコードおよびアプリケーションの少数のサブセットである可能性があります。

すべてのJavaまたはC＃またはVBコードを検討してください。OOP対応のプログラミング言語で記述されているにもかかわらず、OOPテクニックを多く使用している唯一の理由は、外部ライブラリまたはシステムと対話するためです。一方、アプリケーション自体は、OOPフレームワークを活用しながら、設計と実装において非常に手続き的です。

OOPは素晴らしいパラダイムですが、実際には、多くのシステムのロジックの大部分に実際には必要ありません。

Answer 2

既存のシステムを直接指すことはできませんが、OO COBOL以前のバージョンで記述された大量のレガシーエンタープライズシステムがあります。多くの古典的な4GLプログラムは手続き型であり、高整合性システムエンジニアリングを目的としています。よく書かれたものとそうでないものがあります。

書籍には、「Micro to MainframesからのCOBOL」、「Enterprise COBOLプログラミングガイド」が含まれています。

優れた命令型コードの構造的なヒントは、オブジェクト指向のテクニックに似ています：物事に名前を付け、懸念を分離し、繰り返さないでください、単一の責任原則、壊れたウィンドウを修正しないでください

実際には、「Pragmatic Programmer」を読むことをお勧めします。どんなパラダイムでもほとんどの人に正しい考えを与えるでしょう。

ビジネス指向のアプリケーションのためにオブジェクト指向に移行する説得力のある理由に関して。手続き型言語ではドメインロジックへのトランザクションスクリプトアプローチが可能ですが、OO言語ではドメインモデルアプローチ。

確かに簡単な演習では、OO言語を使用する必要はありませんが、複雑さが増すとすぐに、OO言語の保守性が手続き型言語の低オーバーヘッドよりも優先されます。