構造およびオブジェクトプログラミングパラダイムのみがあります

この記事は、ブリッジパターンについての議論の中で作成しましたが、公開しませんでした。 Domain Driven Designが言及されたように、彼らはそれを理解したと思い、OOPスタイルでの設計とプログラミングの必要性に異議を唱える人はいないようでした。 しかし、それでも時間の経過とともに、誤解に出会いました。 これは、純粋に歴史的な理論上の記事になります。 もちろん、トピックの全容を把握しようとせずとも。 しかし、これは、いわば、トップを読み、どの原則とルールを自分に固執するか、プライマリとセカンダリを選択できない若い開発者へのメッセージです。



多くの人にとってこのトピックのタイトルは非常に物議をかもします（そして意図的に挑発的ですが、ビジネスでは:)）。 それでも、ここでそれを正当化し、プログラミングパラダイムがパラダイムと呼ばれる資格を得るために必要なプロパティを理解しようとします。



あなたが斜めに読むかどうかだけ尋ねます-コメントは抑制されました。







フロイドはパラダイムについて何を教えてくれますか？



「プログラミングパラダイム」という用語は、ロバートフロイド（ '' RWフロイド。 '' [Http://www.ias.ac.in/resonance/May2005/pdf/May2005Classics.pdfプログラミングのパラダイム] '' ACMのコミュニケーション ' '、22（8）：455-460、1979。本のロシア語訳を参照：チューリング賞受賞者の最初の20年（1966-1985年）、モスクワ：MIR、1993年）。 1979年の彼の講義では、彼は次のことについて語っています。

プログラミングパラダイムのよく知られた例は、構造プログラミングです。これは、プログラミング方法論の主要なパラダイムと思われます。 2つのフェーズに分かれています。 最初のフェーズであるトップダウン設計では、問題は少数の単純な副問題に分割されます。 この段階的な階層的分解は、強調表示されたサブ問題が発生するまで継続します。 構造プログラミングパラダイムの第2フェーズでは、特定のオブジェクトと機能から、より抽象的なオブジェクトと機能へと上向きに作業する必要があり、トップダウン設計で作成されたモジュールのどこでも使用されます。 しかし、構造プログラミングのパラダイムは普遍的ではありません。 彼女の最も熱心なディフェンダーでさえ、一人でいるだけではすべての複雑な問題を簡単にするのに十分ではないと認めるでしょう。 より特殊なタイプの他の高レベルのパラダイムは引き続き重要です。 （これは正確な翻訳ではありませんが、R。Floydの講義に基づく著者の編集ですが、可能な限り彼の言葉に忠実です。言葉遣いは変更され、R。Floydの主要なアイデアと彼の明確なプレゼンテーションを強調するためにのみ配置されました。）

彼はさらに動的プログラミングと論理プログラミングに言及し、それらをパラダイムとも呼んでいます。 しかし、それらの機能は、それらが専門分野から開発され、いくつかの成功したアルゴリズムが見つかり、対応するソフトウェアシステムが構築されたことです。 彼はさらに、プログラミング言語はプログラミングパラダイムをサポートする必要があると述べています。 同時に、構造プログラミングのパラダイムはより高いレベルのパラダイムであることを示しています。

「構造プログラミングパラダイム」よりも高いレベルの抽象化のパラダイム「偶数」は、言語の階層の構築であり、最高レベルの言語のプログラムは抽象オブジェクトで動作し、それらを次の下位の言語のプログラムに翻訳しますレベル。

高レベルのパラダイムの機能



現時点では、考えられるすべてのパラダイムは、ソフトウェアを作成する際に考えられる代替案と同じレベルにあると考える傾向があります。 しかし、これはそうではありません。 パラダイムは交換できません。



ご覧のように、R。フロイドは、パラダイムをより高レベルでより専門的なものに区別しました。 パラダイムのどの機能が、それらがより高レベルであると言うことができますか？ もちろん、これはさまざまな客観的なタスクへの適用の可能性です。 しかし、パラダイムをさまざまな主題のタスクに適用できるのはなぜですか？ もちろん、ここでの問題は客観的な問題の特徴ではなく、いずれかのアプローチで解決できます。 アルゴリズムを1つまたは別の特殊な方法で作成することを提案するすべてのパラダイムは、パラダイムではありません。これは、高レベルのパラダイムのフレームワーク内の特別なアプローチです。



そして、高レベルのパラダイムは2つだけです。構造プログラミングと、より高レベルのオブジェクト指向プログラミングです。 さらに、高レベルのこれら2つのパラダイムは互いに矛盾し、低レベルでは、アルゴリズムの構築レベルが一致します。 そして、論理的、動的、機能的などの既にアプローチ（低レベルのパラダイム）は、構造プログラミングパラダイムのフレームワーク内で使用される可能性があり、出現したいくつかの専門分野-アスペクト、エージェント指向、イベント指向は、オブジェクト指向プログラミングパラダイムのフレームワーク内で使用されます。 したがって、これはプログラマーが1つまたは2つの高レベルのパラダイムを知っているだけでなく、より専門的な低レベルの問題を解決するときに他のアプローチの知識も役立つことを意味します。 しかし同時に、ソフトウェアを設計しなければならないときは、より高いレベルのパラダイムから始め、必要に応じてより低いレベルのパラダイムに移行する必要があります。 しかし、どの原則を優先するかを選択するという問題が生じた場合、低レベルのパラダイムの原則が高レベルのパラダイムの原則より優先されることはありません。 そのため、たとえば、構造プログラミングの原則はオブジェクト指向プログラミングの原則を損なうものではありません。また、機能的プログラミングまたは論理プログラミングの原則は構造プログラミングの原則に違反してはなりません。 唯一の例外は、アルゴリズムのパフォーマンスです。これは、コンパイラーによるコード最適化の問題です。 しかし、完璧なコンパイラは常に構築できるわけではなく、高レベルのパラダイムの解釈は低レベルのパラダイムよりも確かに複雑であるため、高レベルのパラダイムの原則を無視しなければならない場合があります。



しかし、私たちの質問に戻りましょう：パラダイムをさまざまな主題のタスクに適用できるのはなぜですか？ しかし、それに答えるためには、歴史的な遠足をする必要があります。



構造プログラミングのパラダイムの基礎



E.ダイクストラが1965年に報告した後、GOTO演算子の拒否を正当化した後、構造プログラミングに関するアイデアが生まれたことを知っています。 プログラムを構造化されていないもの（スパゲッティコード）に変えたのはこの演算子であり、ダイクストラはこの演算子を使用せずにプログラムを記述できることを証明しました。その結果、プログラムは構造的になります。



しかし、理論は一つのことであり、実践は別のことです。 この意味で、1975年までに状況がどうなっていたかを考慮することは興味深いことです。 これは、E。Yodanの本（[http://www.az-design.ru/index.shtml?Projects&AzBook&src/005/02YE000 Yodan E.プログラムの構造設計と構築、1975年]）に明確に見られます。 これを検討することは重要です。30年以上経った今、その原則はすでによく知られ、再発見され、新しいランクに引き上げられているからです。 しかし、同時に、歴史的背景は失われ、これらの原則の重要性の階層は、第一のものと第二のものです。 この不定形の状況は、プログラミングの現在の状態を非常によく説明しています。



しかし、その後どうなりましたか？ Yodanが説明するように、それはすべて「良いプログラムを書くことはどういう意味ですか？」という質問に対する答えから始まります。 ここに、高レベルのプログラミングパラダイムが答えるべき質問の最初の基準があります。 この質問に直接答えないが、プログラムの興味深い特性を取得する方法を教えてくれるのであれば、低レベルのパラダイム、つまりプログラミングへのアプローチを扱っています。



プログラミングの夜明けには、プログラムの作成速度でプログラマーを評価するというアプローチがありました。 これは、彼が良いプログラムを書いているということですか？ 彼は管理の特別な気質と尊敬を楽しんでいますか？ 最後の質問への答えが肯定的である場合、プログラミングの改善に関するすべての質問は、学術的関心の対象となる可能性が高くなります。 しかし、経営者は、一部のスーパープログラマーがプログラムを非常に迅速に作成したり、非常に効率的なプログラムを作成したりすることにも気付く場合がありますが、これらのプログラムは未形成のままであり、理解、保守、または変更できません。 また、後者も時間がかかります。



注目に値する、プログラマー間のかなり特徴的な論争：

*プログラマA：「私のプログラムはあなたのプログラムの10倍高速であり、必要なメモリは3倍少ない！」

*プログラマーB：「はい、しかしあなたのプログラムは機能しておらず、私のものは機能しています！」



しかし、プログラムは常により複雑になっているため、プログラムが機能するだけでは不十分です。 プログラムとプログラマの正しい動作を確認する特定の方法が必要です。 さらに、これはプログラムをテストするのではなく、内部組織という意味でプログラムの正当性を検証するための体系的な手順を実行しています。 つまり、それでも、現代の言語で話すと、彼らはコード改訂（コードレビュー）について話しました。



さらに、それでもプログラムの柔軟性、つまり変更、拡張、修正の単純さについて話しました。 これを行うには、特定の種類の質問に常に答える必要があります。 「このテーブルを拡張したい場合はどうなりますか？」、「いつか新しい変更プログラムを定義したい場合はどうなりますか？」、「そのような出力のフォーマットを変更する必要がある場合はどうなりますか？」、「誰かが別の方法でプログラムにデータを入力することに決めますか？」



また、インターフェース仕様の重要性についても話しました。 各モジュールで実装する必要がある入力、関数、および出力の仕様に対する正式なアプローチ。



さらに、モジュールのサイズと不変性に重点が置かれました。 さらに、モジュールの不変性に関しては、モジュール全体ではなく、個々の要因の割り当てを考慮しました。

1.プログラムの論理構造、すなわち アルゴリズム。 プログラム全体が何らかの特別なアプローチに依存している場合、アルゴリズムを変更するときに変更を加える必要があるモジュールの数は？

2.モジュールの引数、またはパラメーター。 つまり インターフェイス仕様の変更

3.内部テーブル変数と定数。 多くのモジュールは共通のテーブルに依存しています。そのようなテーブルの構造が変更されると、モジュールも変更されることが予想されます。

4.データベースの構造と形式。 大部分は、この依存関係は、前述の一般的な変数やテーブルへの依存関係に似ていますが、実際的な観点からは、プログラムとは無関係にデータベースを検討する方が便利です。

5.プログラム管理のモジュール構造。 一部の人々は、実際にそれがどのように使用されるかを考えずにモジュールを書きます。 ただし、要件が変更された場合。 モジュールの論理構造のどの部分を変更する必要がありますか？



これらおよびその他の多くの側面（ここでは考慮していません）は一般に、構造プログラミングのアイデアを定式化します。 これらの側面に配慮することで、構造プログラミングは高レベルのパラダイムになります。



オブジェクト指向プログラミングパラダイムの基礎



ご覧のとおり、優れたプログラムを編成するすべての原則は、構造プログラミングで考慮されています。 優れたプログラムを作成するための別の、またはこれまで知られていなかった原則のグループの出現は、パラダイムを変えることができますか？ いや 構造化されたプログラムを書く方法とイデオロギーを拡大するだけです。 構造プログラミングのパラダイム。



しかし、高レベルのパラダイムが優れたプログラムの作成方法の質問に答えるように設計されており、新しい技術的手法の出現、または新しい要因の検討が、構造プログラミングの境界を越えない場合（技術や要因の数に関係なく、構造的なままであるため）それでは、このパラダイムの境界を越えることができます。 実際、一般的な科学から知られているように、パラダイムはそれほど速く変化しません。 先行するパラダイムが、実際には、利用可能な理論的観点から、発生する現象を単に説明できない場合、科学革命はめったに起こりません。 パラダイムが構造からオブジェクト指向に変わるときも、同様の状況があります。



オブジェクト指向のパラダイムが出現した理由は、ますます複雑なプログラムを作成する必要があることであることがすでに認識されていますが、構造プログラミングのパラダイムには一定の制限があり、その後はプログラムの開発が耐え難いほど難しくなります。 たとえば、G。Schildtは次のように書いています。

プログラミング開発の各段階で、メソッドとツールはプログラムの複雑さを「抑制」するように見えました。 そして、そのような各段階で、新しいアプローチは以前のアプローチから最高のものを吸収し、プログラミングの進歩を示しました。 OOPについても同じことが言えます。 OOPの前に、多くのプロジェクトがプログラミングの構造的アプローチが機能しないことが判明した限界に達しました（そしてそれを超えることもありました）。 したがって、プログラムの複雑化に伴う困難を克服するために、OOPの必要性が生じました。 （[http://www.williamspublishing.com/Books/978-5-8459-1684-6.html Herbert Schildt、C＃4.0 Complete Guide、2011]）

オブジェクト指向プログラミングがより複雑なプログラムを記述し、複雑性制限の発生の問題を事実上排除できる理由を理解するために、OOPの創設者の一人であるGrady Buchu（[http://www.helloworld.ru/texts/comp/other /oop/index.htm Grady Butch、オブジェクト指向分析および設計]）。 彼は、OOPの説明を、複雑さの意味と、複雑であると見なされるシステムから始めます。 つまり、意図的に複雑なプログラムを作成する問題にアプローチします。 次に、この複雑さを理解するために、複雑さと人間の能力の接続の問題に移ります。

別の主な問題があります：複雑なシステムで作業するときの人の能力の物理的な制限。 複雑なソフトウェアシステムの分析を開始すると、さまざまな方法で相互作用する多くのコンポーネントが明らかになり、システムの一部も相互作用する方法も類似性を示しません。 これは、組織化されていない複雑さの例です。 設計の過程でシステムを編成し始めるとき、すぐに多くのことを考える必要があります。 残念ながら、1人でこのすべてを同時に行うことはできません。 ミラーなどの心理学者による実験では、人間の脳が同時に監視できる情報の構造単位の最大数は約7プラスまたはマイナス2であることが示されています。 したがって、私たちは深刻なジレンマに直面しました。 ''「ソフトウェアシステムの複雑さは増していますが、この複雑さを処理する脳の能力は限られています。 どうすればこの苦境から抜け出すことができますか？ '' '

それから彼は分解について話します：

分解：アルゴリズム指向かオブジェクト指向か？ アルゴリズムまたはオブジェクトに応じて、複雑なシステムのどの分解がより正確ですか？ この質問にはキャッチがあり、それに対する正しい答えがあります。両方の側面が重要です。 アルゴリズムによる分離は、イベントの順序に焦点を当てており、オブジェクトによる分離は、オブジェクトまたはアクションの対象であるエージェントに特に重要です。 ただし、2つの方法で同時に複雑なシステムを構築することはできません。 アルゴリズムまたはオブジェクトのいずれかでシステムを分割し始め、次に、結果の構造を使用して、別の観点から問題を検討する必要があります。 経験から、オブジェクトの分解から始める方が有益であることが示されています。 この始まりは、ソフトウェアシステムの複雑さの組織によりうまく対処するのに役立ちます。

したがって、彼はまた、構造原則よりもオブジェクト指向の原則を支持していますが、両方の重要性を強調しています。 言い換えると、人間の脳が発生するタスクの複雑さに対処できるように、構造原則はオブジェクト指向の原則に従う必要があります。 彼はさらに、モデルの重要性を強調しています。

モデルを構築することの重要性。 モデリングは、分解、抽象化、および階層の原則を実装しているため、すべてのエンジニアリング分野で広く普及しています。 各モデルは、検討中のシステムの特定の部分を記述し、それから、古いモデルに基づいて新しいモデルを構築します。 モデルにより、障害を制御できます。 通常および異常な状況での各モデルの動作を評価し、満足できないものがある場合は適切な改善を実施します。 サブジェクト領域自体にあるオブジェクトに焦点を合わせ、オブジェクト指向分解と呼ばれるものを形成するようなモデルを作成することが最も便利です。

さて、よく見ると、オブジェクト指向のパラダイムは一般的なモデリングに過ぎず、S。Lemの最も重要な側面が最も明確に表現されていることがわかります。

モデリングは、その特性をほとんど考慮せずに、自然を模倣したものです。 なぜわずかなのですか？ 私たちの無能のため？ いや 第一に、過剰な情報から身を守る必要があるからです。 ただし、このような過剰は、アクセスできないことも意味します。 アーティストは絵を描きますが、私たちは彼と話をすることはできますが、彼がどのように彼の作品を作成するかはわかりません。 彼は絵を描くとき、​​彼の脳で何が起こっているのか分からない。 これに関する情報は彼の頭の中にありますが、私たちはそれを利用できません。 モデリングは単純化する必要があります。非常にささやかな絵を書くことができる機械は、双子の兄弟のような完璧な「モデル」よりも、素材、つまり脳、絵画の原理について多くを教えてくれます。 モデリングの実践には、いくつかの変数を考慮に入れ、他の変数を放棄することが含まれます。 モデルとオリジナルは、それらで発生するプロセスが一致した場合に同一になります。 これは起きていません。 モデル開発の結果は、実際の開発とは異なります。 この違いに影響する要因は3つあります。元のモデルと比較したモデルの単純さ、元のモデルとは異なるモデルのプロパティ、最後に元のモデル自体の不確実性です。 （作品「Sum of technology」の断片、スタニスラフ・レム、1967）

したがって、S。Lemは抽象化をモデリングの基礎として語っています。 同時に、抽象化はオブジェクト指向のパラダイムの主要な機能です。 Buch氏はこれについて次のように書いています。

合理的な分類は、間違いなく科学の一部です。 MichalskiとSteppは次のように主張します。 このような分類は、主な問題の理解と科学理論のさらなる発展を大いに促進します。」 分類がそれほど複雑なのはなぜですか？ もちろん、一部の分類は他の分類よりも優れていますが、これは「完全な」分類がないためです。 クームス、ラフィア、スラーは、「科学者がこの仕事を引き受けるのと同じくらい多くの方法で世界をオブジェクトシステムに分割する方法がある」と主張します。 分類は対象の視点に依存します。 洪水とカーソンの例：「イギリス...経済学者は経済機関、社会学者は社会、環境保護主義者は自然の死角、アメリカの観光客は観光名所、ソビエトの指導者は軍事的脅威、そして最後に私たちの中で最もロマンチック、英国-彼らの故郷の緑の牧草地のように。」

そして、彼は私たちが必要とする主要な抽象化の選択について話します。

'' 'キー抽象化の検索と選択' ''キー抽象化は、問題領域の辞書に含まれるクラスまたはオブジェクトです。 ''「主要な抽象化の主な価値は、問題の境界を定義することです」 ''：システムに含まれ、それゆえ私たちにとって重要なものを強調し、不要なものを排除します。 このような抽象化を強調するタスクは、問題領域に固有です。 ゴールドバーグによると、「オブジェクトの正しい選択は、アプリケーションの目的と処理された情報の詳細度に依存します。」



すでに述べたように、主要な抽象化の定義には、発見と発明という2つのプロセスが含まれます。 主題分野の専門家に耳を傾けることで抽象化を発見します。専門家がそれについて話す場合、この抽象化は通常非常に重要です。 , , , . , «, , »; — . , , , , , , . , .



— .

そのため、オブジェクト指向のパラダイムは高レベルのパラダイムになり、構造プログラミングパラダイムの原理を支配し、モデリングリアリティに従事し、これらの分野の専門家の言語でドメインモデルを構築します。明確なインターフェースと独立したモジュールを持つ、簡単に修正、拡張できるプログラムを作成するためにこれを怠ると、構造化プログラミングパラダイムのレベルに戻ります。あなたのプログラムは誰にとっても良いでしょうが、現実には対応していないため、理解することはできません。あなたにしか知られていない用語で説明され、主題分野を知っている専門家はあなたの助けなしにプログラムを理解することはできません。最終的に、難易度は非常に狭い範囲で減少し、良いプログラムを組織しましたが。しかし、それはプログラムであり、モデルではありません。モデルが存在しない、またはモデルの表面的な表現があれば、優れたプログラムを内部から「爆破」し、将来、それをさらに開発して同行することはできません。抽象概念が存在しないクラスを導入するとき、これらのクラスが純粋に体系的でサブジェクトエリアとは無関係であるとき、他のクラスの相互作用フローを単純化するためだけに導入されるとき、ソフトウェアは「ひげあり」になり、リファクタリングが行われない場合そのような領域を超えて、ある日あなたのソフトウェアの開発が停止し、それは不可能になります-あなたは構造プログラミングの限界に達するでしょう（そしてクラスとオブジェクトを使用してもあなたを脅かすことはないように思われましたか？）または表面的な表現であり、あなたの良いプログラムを内側から「爆破」し、将来的にはそれをさらに開発および保守することはできません。抽象概念が存在しないクラスを導入するとき、これらのクラスが純粋に体系的でサブジェクトエリアとは無関係であるとき、他のクラスの相互作用フローを単純化するためだけに導入されるとき、ソフトウェアは「ひげあり」になり、リファクタリングが行われない場合そのような領域を超えて、ある日あなたのソフトウェアの開発が停止し、それは不可能になります-あなたは構造プログラミングの限界に達するでしょう（そしてクラスとオブジェクトを使用してもあなたを脅かすことはないように思われましたか？）または表面的な表現であり、あなたの良いプログラムを内側から「爆破」し、将来的にはそれをさらに開発および保守することはできません。抽象概念が存在しないクラスを導入するとき、これらのクラスが純粋に体系的でサブジェクトエリアとは無関係であるとき、他のクラスの相互作用フローを単純化するためだけに導入されるとき、ソフトウェアは「ひげあり」になり、リファクタリングが行われない場合そのような領域を超えて、ある日あなたのソフトウェアの開発が停止し、それは不可能になります-あなたは構造プログラミングの限界に達するでしょう（そしてクラスとオブジェクトを使用してもあなたを脅かすことはないように思われましたか？）これらのクラスが純粋に体系的で、サブジェクト領域とは関係がない場合、他のクラスの相互作用フローを単純化するためだけに導入された場合、ソフトウェアは「ひげあり」になり、リファクタリングがそのような領域を一時的に監視しない場合、ソフトウェア開発停止し、不可能になります-構造プログラミングの限界に達します（クラスとオブジェクトを使用しても脅威にならないように思われます）。これらのクラスが純粋に体系的で、サブジェクト領域とは関係がない場合、他のクラスの相互作用フローを単純化するためだけに導入された場合、ソフトウェアは「ひげあり」になり、リファクタリングがそのような領域を一時的に監視しない場合、ソフトウェア開発停止し、不可能になります-構造プログラミングの限界に達します（クラスとオブジェクトを使用しても脅威にならないように思われます）。クラスとオブジェクトを使用しても脅威になりませんか？）。クラスとオブジェクトを使用しても脅威になりませんか？）。



更新しました。私はここで、トピックは鋭く、コメントしないと思いました。記事で事実を述べましたが、ホリバーのレベルにまで下がりたくありません。これが考えられなかった場合-さて、それは今回は運がないことを意味します。確かに、それは建設的です-別の記事で反論を書く場合。私は大衆のステレオタイプを破壊するとは思わない。



はい、また、明確にするために、ここでの議論の後に公開することにしました。Rosenblattパーセプトロンをプログラムしましょう。 , , . , — , . ( ) , , . , — , , ?