procedural - 手続き型（命令型）ベースのアプリケーションを正常に設計および構築することは可能ですか？

Question

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

Answer 1

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

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

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

OOP対応のプログラミング言語で記述されているJava、C＃、またはVBコードのすべてを考えてみてください。これらのコードが、多くのOOP手法を使用している唯一の理由は、外部のライブラリまたはシステムと対話することです。一方、アプリケーション自体は、OOPフレームワークを活用しながら、設計と実装においてかなり手続き型である可能性があります。

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

Answer 2

既存のシステムを直接指摘することはできませんが、オブジェクト指向COBOLより前に作成されたレガシーエンタープライズシステムは大量にあります。多くの古典的な4GLプログラムは手続き型であり、高整合性システムエンジニアリングを目的としています。よく書かれているものもあれば、それほど多くないものもあります。

書籍には、「マイクロからメインフレームへのCOBOL」、「エンタープライズCOBOLプログラミングガイド」が含まれます。

優れた命令型コードの構造上のヒントは、OOの手法に似ています。名前を適切に付け、懸念事項を分離し、繰り返してはいけません。単一責任の原則であり、壊れたウィンドウを修正しないでください。

実際、「実用的なプログラマー」を読むことで、ほとんどの人がどのパラダイムでも正しいアイデアを得ることができると思います。

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

確かに、単純な演習では、オブジェクト指向言語を実際に使用する必要はありませんが、複雑さが増すとすぐに、オブジェクト指向言語の保守性が手続き型言語よりもオーバーヘッドが少なくなります。