構造化プログラミングvs OOプログラミング
私は構造指向プログラミングとオブジェクト指向プログラミングの違いを示すプレゼンテーションを作成しており、具体的に説明したいと思います理由人々はOOPを適用する例でOOPの概念により、コーディングがはるかに簡単になり、聴衆は本当に必要と感じるようになりますOOP。
何か案は ？？
このクイック ビデオブログ をご覧ください。結局のところ、構造化プログラミングとOOプログラミングの違いは、彼らが何を追加するかではなく、プログラミングから取り除くものの問題です。構造化プログラミングやオブジェクト指向プログラミングなどのソフトウェア分野は制約的であり、有効になっていません。ここにいくつかの定義があります。警告：それらを好きになることはできません。
構造化プログラミングはgoto（制御の直接転送）に課せられた規律です
オブジェクト指向プログラミングは、関数へのポインターに課せられる規律です（間接的な制御の移行）。
関数型プログラミングは、割り当て時に課せられる規律です。
最初のものは理解するのにそれほど難しくありません。 Dijkstraは、gotoがアルゴリズムで許可されている場合、正確性の一般的な証明を作成することは不可能であることを発見しました。ただし、制御構造がシーケンス、選択、反復に限定されている場合は、正確性の証明が可能でした。もちろん、私たちは現在、物事が正しいことを証明しようとさえしていませんが、構造化プログラミングのシンプルさと優雅さが好きです。
OOを理解するのは少し難しいです。私たちはしばしばOOをカプセル化、継承、およびポリモーフィズムとして定義します。これらの属性の3つすべてが達成可能であり、頻繁にがあったことを知っていますCで実現しました。実際、C++はCにコンパイルされるプリプロセッサとして開始されました。Cでカプセル化することは実際には難しくありません。また、継承をシミュレートして互いにサブセットであるデータ構造を構築することも困難ではありません。 。ただし、ポリモーフィズムは少し難しいです。Cでは、適切に管理するのが難しい関数へのポインタが必要です。C++のような言語で提供された言語は、関数へのポインタに課せられた規律でした。C++コンパイラは、vtableを構築しました。そして厳密な形式に従ってそれらの中のポインタを初期化しました。したがって、非常に現実的な意味でOOはindirect制御の移動、つまり関数へのポインタ。
構造化プログラミングとは、gotoをどのようにしないかということです。 OOは、関数へのポインタをどのようにしないかということです。そして関数型プログラミングもすべてnotto do。関数型プログラミングでは、最も厳密に制御された場合を除いて、変数を割り当てません。
つまり、結局のところ、これらのプログラミング「テクノロジー」はすべて、実際にテクノロジーを有効にするのではなく、分野を制約しているのです。彼らは私たちに何をすべきかしない私たちに何をすべきかを伝えるよりも教えて行う。つまり、ソフトウェア開発は過去40年間成長していません。むしろ、縮小しています。私たちがしてはいけないことがやるべきことをすべて学んだので、それはますます制約されています。
しないことを学ぶことは良いことです;しかし、ここで不穏な質問があります。私たちはからに新しいことを何を学びましたか？
コンピュータをプログラムするには、3つの基本的な方法があります。
- 非構造化プログラミング-古いBASICインタープリターやアセンブリ言語のように、
gotosを使用します。この方法でプログラムする人はほとんどいません。 - 構造化された命令型プログラミング-CやPascalのようなもの。
- 構造化関数型プログラミング-Haskell、ML、またはLISPのようなもの。
私の見解では、オブジェクト指向プログラミングは何か違うものです。それは、プログラムをより大規模に編成する方法についてです。上記の3つのパラダイムのいずれも置き換えたり、廃止したりすることはありません。メソッド本体内では、リストから3つのパラダイムのいずれかを選択して書き込む必要があります。
それはあなたが変化をどのように予想するかについてすべてです。
どちらの概念も再利用性に役立ちますが、OOPは変更を容易にする扉を開きます。OOPは、構造プログラミングが行うすべての再利用性を備えていますが、それを使用することもできます。少ない労力で新しい機能を作成します。
OOPは、構造プログラミングのすべての機能を継承の追加機能とともに継承します！:-D
概念は直交しています。構造化プログラミングとは、プロシージャ/関数/メソッド内でコードを構造化することです。 OOPを行うときは、クラスメソッド内で構造化プログラミングの原則に従うことは完全に可能（かつ望ましい）です。
それは一種の主観的な表現です-構造化プログラミングとOOPは問題を解決するスタイルであり、一方が他方よりも常に優れているとは限りません。数値メソッドライブラリを書くことは、入力データに対して変換を実行する構造化スタイルで行われます。ただし、ステートマシンによって駆動される単純なエージェントは、JavaまたはC++で自己完結型クラスとして簡単に表現できます。 OOPは、データ構造のストレージコンテナーを表現する自然な方法です。
情報の隠蔽とモジュール性について話すことは、スタイルとして自然にOOPをやる気にさせる良い方法です。
Steve Yegge -によって、この問題に関する興味深い見方がいくつかの方法で書かれました。これは、2つのスタイルのアプローチの違いをよりよく説明するものの1つです。
OOPは、ビジネスモデルを作成するときに理解しやすくなります。アプリケーションの要素について考えるとき、いくつかのオブジェクトとそれらの間の関係を使用します。書籍には著者、タイトル、ISBNがあります。本は図書館に入れるためのもので、学生が借りることができます。構造的プログラミングは、特定のプロセス、抽象化されていない実装について考えることを強制します。
OOPは簡単に変更できるように設計されています。構造プログラムの変更は可能ですが、コードで記述する必要があります。 OOプログラムの変更は、抽象的なモデルの変更で説明できます。
変数のスコープ：
良いプログラミングを保証するための言語の原則は、変数のスコープrestrictであると思います。 Cのような構造化言語では、スコープは主に2つのタイプからなります。
- グローバルスコープ
- ローカル/関数/メソッドのスコープ
グローバルスコープが有害であることは誰もが知っています。しかし、ローカルスコープではプログラムを実行するのに十分でない場合があります。グローバルスコープを回避すると、ポインターの使用範囲が広がり、スコープ外の変数を使用できるようになります。しかし、ポインターを理解して使用することは困難です。
OOP C++のような言語は、カプセル化によって新しいタイプのスコープを追加しますクラス/オブジェクトスコープ。このスコープは、プライベート/パブリックバリエーションによってさらに強化されます。そして、これは解決します変数のスコープに関する多くの問題。スコープはOOPでより詳細に定義されており、ポインタはあまり必要ありません。
これはOOPの優れた機能の1つです。