Java開発フレームワークの設計原則とは何ですか

#フレームワーク開発の概念の紹介

• オブジェクト指向分析: オブジェクト指向分析は、客観的な世界のプログラミング ビジネスのオブジェクト分析です。プロセス中に知っておくべきこと;

  輻輳モデル: データと対応するビジネス ロジックは同じクラスにカプセル化されます; 貧血モデル: データとビジネス ロジックさまざまなクラスに分類されます; DDD: ドメイン駆動モデル、MVC 従来の 3 層アーキテクチャ;

• オブジェクト指向設計の目的: 強力な凝集性、低結合、拡張が容易、安定性、安定性。スケーラブル、シンプル;

• オブジェクト指向設計原則: この原則はプログラミング言語に依存せず、非オブジェクト指向プログラミング言語でも使用できます;

• デザインパターン: 主に使用される ある種の問題に対する一般的な解決策であり、数式や入れ子展開に相当します 一般的に、デザインパターンは作成パターン、動作モデル、構造パターンにまとめられます。

#フレームワーク: フレームワークは、特定の種類のアプリケーションを実装する構造的なプログラムです。これは、特定の種類のアーキテクチャ ソリューションの再利用可能な設計と実装です。
##開発フレームワークの設計原則

SOLID 原則

##SRP: 単一責任原則、クラスまたはモジュールは 1 つの責任を完了することのみを担当します;

• OCP: オープンクローズド原則、ソフトウェア エンティティ (モジュール、 ;

• LSP: Liskov 置換原則、子オブジェクトはプログラム内の任意の場所で親クラス オブジェクトを置き換えることができます。また、元のプログラム ロジックの動作が変更されず、正確性が損なわれていないことを確認します。

• ISP: インターフェイス分離原則。クライアントは、必要のないインターフェイスに依存することを強制されるべきではありません。

• DIP: 依存関係逆転の原則、高レベルのモジュールは基礎となるモジュールに依存する必要はありません。高レベルのモジュールと基礎となるモジュールは、抽象化を通じて相互に依存する必要があります。また、抽象化特定の実装の詳細に依存すべきではありません。特定の実装の詳細は抽象化に依存します。

• #KISS 原則

• 車輪の再発明ではなく、既存のツール ライブラリを上手に使いましょう。これらのライブラリを自分で実装すると、バグが発生する可能性が高くなり、メンテナンスのコストが高くなることが経験的に証明されています。

• 最適化しすぎないでください。コードを最適化し、コードの可読性を犠牲にするために、いくつかのトリック (算術演算の代わりにビット単位の演算、if-else の代わりに複雑な条件文、低レベルすぎる関数の使用など) を多用しないでください。

• YAGNI 原則

#KISS=You Ain't Gonna Need It. (過度にデザインしないでください)

設計の本来の目的はコードの品質を向上させることです。

• 設計済み アプリケーション シナリオは複雑なコードです。

• ##継続的なリファクタリングにより過剰な設計を効果的に回避できます。

• ##Don特定のシナリオを考慮せずにデザインについて話さないでください。

• DRY 原則

• DRY=Don't Reply Yourself. (次のようなことは書かないでください)繰り返されるコード。)

• モジュール化;

• ビジネス ロジックと非ビジネス ロジックの分離;

• ユニバーサル コード シンキング;

• #継承、ポリモーフィズム、抽象化、カプセル化;

• テンプレートおよびその他のデザイン パターンを適用する;

以上がJava開発フレームワークの設計原則とは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。