ソフトウェアプロジェクトとOOPの進化

ソフトウェアプロジェクトの効果的な開発のためのレシピを習得し、SOLIDアーキテクチャの開発の原則を使用するのに役立つ理由を自分で見つけようとしました（SOLIDアーキテクチャの開発の原則を理解しない方法 ）。

これらの原則の分析により、開発に存在するいくつかの重要なパターンと基本要素を特定することができました。 ソフトウェアプロジェクトの実際の作業でSOLIDを説明、理解、実装することができました。

OOPなど、一般に受け入れられているプログラミングパラダイムに対するこれらの概念の適用性の分析を実行することは興味深いものになりました。 まあ、もしこの仕事の結果があなたにとって役に立つなら。

今日、ソフトウェアプロジェクトの設計とその後の実装には多くのアプローチがあります。 大規模なソフトウェアプロジェクトでの作業で最も要求されるのは、 構造プログラミング 、 関数型プログラミング 、 オブジェクト指向プログラミングです。

私にとって、これらの設計アプローチの原因を分析することは興味深いものになりました。 そして分析の過程で、予想外の発見は、それらがすべて暗黙的に次の前提に基づいているという事実でした：

          ,      .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソフトウェアプロジェクト開発

開発の必要がないプロジェクトとは何ですか？ このようなプロジェクトはめったに見られず、主にプログラマー側のその後の義務を伴わない素早い一括払いが特徴です。

• 1つのアプローチで作成できる小さなプロジェクト。
• 構造的に複雑なコードがなく、多数の関係を抱えるプロジェクト。
• サポートやユーザーサポートを必要としないソフトウェア製品。

そのような状況では、たとえばオブジェクト指向のアプローチを維持するためのプログラマーの努力が無駄になります。 このプロジェクトで4年生のテキストを書くと15分間遅れて結果に近づかなかったことに突然気付いたとき、ワンタイムコンソールユーティリティの開発中に、このような無意味なレッスンに自分自身を見つけることがよくあります。 最も悲しいことは、そのようなプロジェクトでほとんど書かれていなかったすべてのクラスは忘れられ、再利用されないということです。つまり、将来の作業を促進しないということです。

他のすべての状況では、プログラマは作業を最小限に抑えながら、構造的に複雑なプロジェクトを開発する必要があります。つまり、

• コードを分析し、これらのエラーが生成される場所を見つけることにより、エラーを修正します。
• 以前に利用可能なすべての機能の機能を維持しながら、新しい機能を導入します。 その際、これらの新しいタスクの実装で既存のコード（作成およびテスト済み）を使用します。
• ソフトウェア製品の使用に関するサポートを提供します。
• プロジェクトのすべてのバージョンの機能の説明と調整を実行します。
• プロジェクトで使用されているすべてのデータ形式（古くなったものも含む）を操作可能にしてください。
• また、フレームワークの変更や古いOSのサポートの終了により、競合他社との対立に見られる他の多くのタスクを実行します...

ソフトウェアプロジェクトの開発との類似点を探すと、生物種の進化を思い出すことができます。

      "".     -       .       -  .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラマーの仕事は簡単ではありませんが、プログラマーには「ヘルパー」がいます。 このヘルパーは、私たちの世界の構造のどこかに深く隠されています。そこには2つの機能があります。

• 1つの有用なアルゴリズムを記述し、多くの同様のタスクに使用する機能
• ソリューションに類似した非常に多くのタスクの存在。

多くの分野で役立つこのアルゴリズムは、簡潔にするために汎用アルゴリズムと呼ばれます。 狭い応用分野で使用するためのアルゴリズムを改良するプロセスは、生体内の細胞の進化的特殊化に似ているため、特定の応用分野への実装は特殊化と呼ぶことができます。

明らかに、アルゴリズムを作成するには、アルゴリズムの適用性を保証する機能を識別する必要があります。 これらの兆候は、入力データと初期状況の説明（コンテキスト）で検索する必要があります。 汎用アルゴリズムを作成するには、データと状況の兆候の独自のセットを持つ各サブジェクト領域で、すべての領域で同一の適用可能性の兆候を識別する必要があります。 適用可能性を提供しない他のすべての兆候は、 汎用アルゴリズムによって無視されます。 普遍的なアルゴリズムを形式化するために、 抽象化を使用する必要が生じました。これは、OOPの最も重要な原則の1つです。 さらに、OOPの特徴はデータの抽象化のみにあります。

ここでは、さまざまな領域からの抽象化の使用例を書き出そうとします。

抽象化	アルゴリズム	応用分野
自然数	定量的計算アルゴリズム	経済的価値の会計処理のタスク
材料本体の質量特性	物質の量を比較するためのアルゴリズム	説明不可能な製品の価値を比較するタスク
要素のコレクションの操作とのインターフェース：フルクロール、比較、位置の交換	コレクションソートアルゴリズム	プログラミング
ツリー内の「エンドノード」と「ブランチノード」に対する同じ操作のインターフェイス	レイアウト設計パターンに基づくアルゴリズム	複雑なソフトウェアプロジェクトの開発
キーコンセプト「従業員」	「雇用契約」セクションの文言	労働法

ソフトウェアプロジェクトの構成要素

プログラマーは、さまざまな抽象化技術を使用して、アルゴリズムをコードのセクションの形式で実装します。これは、彼の仕事の独立した完全な要素です。 この要素は、使用するプログラミング言語に応じて、関数、オブジェクト、一連の命令になります。 さらなる議論の便宜上、このコードフラグメントを「 コンポーネント 」という単語と呼びます。

コンポーネント -コード（手順、クラス、展開コンポーネントなど）：

• 特定の初期状況と特定の入力データで機能する完全なアルゴリズムを実装し、
• 1つのプロジェクトで複数回使用できます（異なるプロジェクトで何度も使用できます）。
• 開発環境で追加の検索操作を行うことなく、すべての指示が近くに表示され、表示されます。
• プログラマが残りのコードに対して比較的独立して実行する変更。

ソフトウェアプロジェクトの開発パターン

コンポーネントという用語を使用すると、ソフトウェアプロジェクトの開発に存在する一連の単純な法則を定式化することが可能になります。 これらのパターンを次のステートメントの形式で提示し、3つのカテゴリーに分けます。

1. コンポーネントのプロパティを説明するステートメント。
   
   1.1。 正しく記述されたコンポーネントが必ず使用され、より頻繁に数回使用されます 。
   
   1.2。 コンポーネントの使用の各場所では、変更されていない動作が期待され、結果が繰り返し可能になります。
   
   1.3。 複数の場所でコンポーネントを使用する場合、結果は各使用場所を満たす必要があります。
   
   1.4。 コンポーネントに埋め込まれた動作により、このコンポーネントの使用場所に制限が生じます 。
   
   1.5。 コンポーネントの使用の各場所では、そのすべての制限が関係する可能性があります。
   
   1.6。 コンポーネントを変更すると、その制限が変更され、使用するすべての場所の検証が必要になり、プログラマーは時間を無駄にします。
   
   1.7。 コンポーネントをコードの形で1つのインスタンスに記述することをお勧めします。つまり、同じコードの重複を排除する必要があります。 これにより、 コンポーネントに変更を加える際の編集回数が減ります 。
2. プログラマーによる新しいタスクの実装のパターンを説明するステートメント。
   
   2.1プログラマが費やす時間を最小限に抑えながら、新しいタスクを実装するオプションを選択することをお勧めします。
   
   2.2。 新しいタスクを実装するために、プログラマは新しいコンポーネントを追加したり、古いコンポーネントの動作を変更したりできます 。
   
   2.3。 コンポーネントの追加は、基本的に新規使用の場所でのみ検証が必要であり、プログラマーの時間を最小限に抑えます。
   
   2.4。 ステートメント[1.6]によると、新しいタスクによって引き起こされるコンポーネントの動作の変更には、新しい使用の場所と古い使用のすべての場所での検証が必要です。 公開されたコンポーネントの場合、変更されたコンポーネントを使用するすべてのプログラマーの作業が必要です 。
3. ユニバーサルアルゴリズムとその専門化の相互作用のパターンを説明するステートメント：
   
   3.1。 基本 コンポーネントを作成する機会があります （名前は基本クラスとの類推によって導入され、簡潔にするために「 base 」という単語を使用します）。 ベースは、 ユニバーサルアルゴリズムの最も重要な機能のみを実行します。
   
   3.2。 コンポーネント-特殊化（以下、簡潔にするために「 特殊化 」という用語を使用します）を記述することができます。 特殊化は、 データベースの 汎用アルゴリズムを補完し、特定の使用分野に適用できるようにします。
   
   3.3。 ステートメント[3.1]、[3.2]からわかるように、 baseは 、 specializationよりも複雑さが少なく、アプリケーションの制限が少ない。
   
   3.4。 声明[1.7]によると、 データベースからのユニバーサルアルゴリズムのコードを複製せずに専門化を開発することをお勧めします 。
   
   3.5。 データベースの使用場所は、正しく形成されたスペシャライゼーションに変更を加えた後、検証を必要としません。

オブジェクト指向プログラミングの概念

上記のステートメントを使用して、オブジェクト指向プログラミングの基本概念の分析を試みます。 この分析は、 抽象化の概念をバイパスします。これは、 ユニバーサルアルゴリズムの構築方法の形式化で既に説明したとおりです。

クラス、オブジェクト

これらのOOPの概念は、いくつかの内部データとこれらのデータを操作する方法の組み合わせによって記述される特別なタイプのコンポーネントを使用する可能性を強化します。 グループ[1]および[2]のすべてのステートメントはOOPに変換されます。このため、 コンポーネントという用語はclassの概念に置き換えられます。

同時に、一見すると、 クラスとオブジェクトの関係はステートメントのグループ[3]によって使い果たされ、 ベースはクラスの概念に置き換えられ、 実装はオブジェクトの概念に置き換えられます 。 さらに、 実装は動的であることがわかりました。つまり、プログラムの実行中に変更可能です。

カプセル化

「 カプセル化 」の概念は、2つの「側面」から考えることができます。

「 カプセル化 」の概念の最初の側面は、 コンポーネントをコードの他の部分から分離することです。 このプロパティを使用すると、プログラマは、 コンポーネントに変更を加えるために「近く」にあるコードの領域で操作を行うことができます 。 つまり、プログラマーが費やす時間を最小限に抑えるために、プログラムのさまざまな相互作用要素の検索と分析を作業から除外します。 この側は、その定義に従ってコンポーネントのプロパティによって定義されます。

" カプセル化 "の概念の2番目の側面はコンポーネントの内部実装の隠蔽です 。 この隠蔽は、ステートメントのグループ[3]で説明されているベースと実装の概念を使用して可能です。 これを行うために、 クラスのパブリックメソッドはbaseで識別され、プライベートおよび保護されたクラスメソッドは implementationで識別されます。 使用場所では、 ベースによって形成される制限が使用されるため、 基本的な制限に関係しない実装の変更を行うことが可能になります。 また、 実装のこれらの変更は、 ベースが使用されている場所で確認する必要はありません[3.5]。これにより、プログラマの労力を最小限に抑えることができます。

「 カプセル化 」の概念が生物学に類似していることは注目に値します。 この最初のプロセスは、「 細胞膜 」の生物学的機能に似ています。

継承

「 継承 」の概念は、 ベース + 実装バンドルを使用することの重要性を強化し続けています。 このため、ステートメントのグループ[3]では、親クラスのメソッドをbaseで識別し、後継クラスのメソッドをimplementationで識別する必要があります 。

その実装では、「 継承 」の概念により、ステートメント[2.3]を使用できます。つまり、コードを変更および複製する代わりに、コードの追加を使用できます。 この場合、 基本アルゴリズムの重複を除外する必要があります。 ただし、 継承を使用してユニバーサルアルゴリズムを特化するアプローチには大きなマイナスがあります。 この欠点は、2つの強く接続されたコンポーネントが存在することです。これらのコンポーネントは 、個別に変更することは困難です。 これらの依存関係は、親子関係によって生成されます。

ベース + 実装バンドルを使用する多くの代替方法があります。 このような方法の例をさらに示します。

ベース	実装	応用分野
パブリッククラスメソッド	プライベートクラスメソッド	カプセル化
親クラスの保護されたメソッド	継承クラスのメソッド	継承
動的ライブラリインターフェイス	動的ライブラリ機能	コンポーネント =動的ライブラリ
テンプレート（汎用）メソッドとクラス（テンプレート、汎用）	引数を指定してテンプレートをインスタンス化する	一般的なプログラミング
デリゲートを受け入れる汎用メソッド	特定の処理手順を示すメソッドの専門化	要素の順序を評価する方法を示す、ツリーのソートまたは形成の手順
訪問者テンプレートとの対話を許可するクラス	必要な機能を備えた「訪問者」の形成	訪問者のデザインパターン
NPPコントロールパネル	原子力発電所の自動化と設備のセット	NPPオペレーターからのシステムの複雑さの隠蔽

同時に、PLOからの「 継承 」の概念についても、生物学的進化のプロセスに類似性があることがわかります。 生物学では、「 遺伝 」という用語がこれに使用されます。

多型

私の意見では、「 ポリモーフィズム 」の概念は、 普遍的なアルゴリズムを作成する手順を見るときの第2の側面です。 最初の側面（ 抽象化 ）は、 ユニバーサルアルゴリズムを作成する方法の観点からのビューです。 同時に、 普遍的なアルゴリズムをユーザーの観点から見ると、 ポリモーフィズムの概念の記録が得られます。 つまり、 ポリモーフィズムは、さまざまなタイプのデータを処理する関数（ コンポーネント ）の有用な機能です。 この概念をOOPに追加すると、ソフトウェアプロジェクトの開発で汎用アルゴリズムを使用する有用性が強化されます。

異なるプログラミング言語でのポリモーフィズムの実装は非常に異なります。 ポリモーフィズムに関するWikipediaの記事には、その実装に応じて、パラメトリック、包含（またはサブタイプ）、オーバーロード、型キャストの4つのサブタイプがあります。 これらの実装には大きな違いがありますが、それらはすべて1つの目標によって結合されています。これは、特定の特殊化のために複製する必要のない普遍的なアルゴリズムを記述しています。

そして今回、彼はほとんど驚くことなく、生物学における「 多型 」の概念との類似性を見つけました。 この生物学的用語の名前は、OOPの概念と完全に一致しています。 「 多型 」-異なる内部構造または異なる外部形態を持つ状態に存在する1つの生物の能力。

おわりに

したがって、OOPのほぼすべての基本概念は、ソフトウェアプロジェクトの開発の法則に基づいて形成された一連の単純なステートメントとして表すことができます。 さらに、OOPの場合、 コンポーネントという用語は クラスの概念で識別されます。 コンポーネントなどの用語の異なる意味、たとえば関数を選択すると、 関数 型プログラミングの基本概念を定式化することが可能になります 。

記事を書く過程で、プログラミングで使用される概念の生物学的類似性が見つかりました。 これらのアナロジーは、ソフトウェア製品の開発方法と生物学的進化のいくつかのプロセスの類似性のために表示されます。

私見、これら2つの科学分野を一緒に検討することをお勧めします。 この場合、ある産業から別の産業への法律の移転を実行し、それによって情報技術の開発と生物学的プロセスの正式な記述を確実にすることが可能かもしれません。

ご清聴ありがとうございました。

レビュー

フィードバック、提案、提案は、この分野の仕事の発展の方向性を調整するのに役立つので、とても感謝しています。

参照資料

• 一般的なWikiアルゴリズム理論
• シリーズの最初の記事

Borisova M.Vにより編集