スプリングのデフォルト5 AppConfigを使用して関心を分離


(1)注目点の分離

  • 「問題はどこですか?」
  • ->演出(アプリケーション)で、実役にふさわしい俳優(インタフェース)を選ぶのは誰ですか?
    -->誰がロミオを演じるかは俳優が決めるものではありません.
    -->以前のコードはロミオ役(インタフェース)を演じたディカプリオ俳優(インプリメンテーション)がジュリエット役(インタフェース)を演じたヒロイン(インプリメンテーション)を直接招聘した
    ---ディカプリオ(実施体)には、演出や主人公の招聘など「多様な責任」がある
  • 「注目点を分離」
  • ->俳優(実施体)は自分のコスプレだけに専念すべきです.
    -->演出プランナーが必要で、演出を組織し、俳優を招待し、役に合った俳優を指定します.
    ------>演出プランナーを作り、俳優と演出プランナーの責任を明確に分ける

    (2)AppConfigの作成

  • アプリケーションの完全な動作を構成するには、実装オブジェクトを作成し、接続を担当する独立した設定クラス
  • を作成します.
  • AppConfig.java
  • package springbasic.core;
    
    import springbasic.core.discount.FixDiscountPolicy;
    import springbasic.core.member.MemberService;
    import springbasic.core.member.MemberServiceImpl;
    import springbasic.core.member.MemoryMemberRepository;
    import springbasic.core.order.OrderService;
    import springbasic.core.order.OrderServiceImpl;
    
    public class AppConfig {
        //생성자주입
        public MemberService memberService(){
            return new MemberServiceImpl(new MemoryMemberRepository());
        }
    
        public OrderService orderService(){
            return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
        }
    
    }
    
  • AppConfigでは、アプリケーションの実際の操作要件を満たすために実装オブジェクトを作成できます.
    -MemberServiceImpl
    -MemoryMemberRepository
    -OrderServiceImpl
    -FixDiscountPolicy
  • AppConfigでは、作成されたオブジェクトインスタンスの参照がジェネレータによって注入されます.
    -MemberServiceImpl -> MemoryMemberRepository
    -OrderServiceImpl -> MemoryMemberRepository, FixDiscountPolicy

  • MemberServiceImpl.JAva-コンストラクション関数注入

    ->MemberServiceImplはMemoryMemberRepositoryに依存しなくなりました.
    -->MemberRepositoryのみに依存します.
    -->MemberServiceImplの場合、ジェネレータはどのインプリメンテーションオブジェクトがインポートされるか分からない(注入)
    -->MemberServiceImplの作成者によって注入されたインプリメンテーションオブジェクトはAppConfigによって決定されます.
    -->MemberServiceImplは、依存関係の悩みをAppConfigに任せ、実行に専念します.


    依存性を注入!「外部から依存関係を注入するように」

  • OrderServiceImpl.JAva-コンストラクション関数注入

    ->OrderServiceImpl FixDiscountPolicyに依存しなくなりました.
    -->DiscountRepositoryのみに依存します.
    -->OrderServiceImplの観点から、作成者はどのインプリメンテーションオブジェクトがインポートされるか分からない(注入)
    -->OrderServiceImplジェネレータによって注入されるインプリメンテーションオブジェクトは、AppConfigによって決定されます.
    -->OrderServiceImpl依存関係に関する悩みはAppConfigに任せられ、実行のみに注目されます.
  • (3)AppConfig反射の修正

  • OrderApp.java
  • MemberApp.java
  • OrderServiceTest.java
  • MemberServiceTest.java
  • (4)整理

  • AppConfigで注目点
  • を明確に区別する.
  • AppConfigは演出プランナー
  • AppConfigは、特定のカテゴリの選択、俳優の選択、アプリケーション全体の構成を担当します.
  • 現在、各実施機関はその職責のみを担当しています.

    (5)AppConfig再包装

  • 尊敬理由
  • 現在のAppConfigでは重複する内容があり、キャラクターの実装が不明である

  • 前AppConfigを尊敬します.java


  • 尊重されたAppConfigを加えます.java

  • の新しいメモリMemberRepository()セクションの重複データが消去されました.
    ->MemoryMemberRepository()一部を変更するだけで
  • AppConfigはキャラクタクラスとインプリメンテーションクラスを一目で見ることができます.
    ->アプリケーション全体の構成をすばやく理解します.
  • (6)新しい構造と割引ポリシーの採用

  • 「固定割引」を「定額割引」
  • に変更
  • はどの部分を変更する必要がありますか?
    ->AppConfig.Javaを置き換えるだけです.
  • AppConfig.Javaの変更

  • AppConfig割引ポリシーロールの実装をFix->Rateオブジェクト
  • に変更
  • 割引ポリシーを変更する場合は、アプリケーション構成ロールのAppConfigを変更するだけです.
    ->受注サービスImplなどの使用分野のコード(
  • )
  • コンフィギュレーションエリア(AppConfig)は当然変更されます.
  • **(7)5項目の対象設計原則を採用することを確定する


    **
    1、SRP単一責任原則:一つの等級は一つの責任しか引き受けられない.
  • クライアント・オブジェクトは、ダイレクト・インプリメンテーション・オブジェクトの作成、接続、および実行を担当します.
  • SRP単一責任原則に従って注目点を分離する.
  • インプリメンテーションオブジェクトの作成と接続を担当します.
  • クライアント・オブジェクト(MemberServiceImpl,OrderServiceImpl)は、実行のみを担当します.
    2.DIP依存関係逆転の原則:プログラマは「抽象化に依存して具体化に依存することはできない」とし,依存性注入はこの原則に従う方法の一つである.
  • の新しい割引ポリシーを開発し、適用します.クライアントコードも変更する必要があります.
    ->クライアントは抽象化と実装に依存します.
  • クライアントコードが抽象(DiscountPolicy)
  • のみに依存するように変更されました.
  • AppConfigによって生成されたオブジェクトインスタンス(FixDiscountPolicy)は、クライアントコードに依存関係を注入する(
  • ).
    3.OCP:ソフトウェア要素は拡張時に開いていますが、変更時には閉じている必要があります.
  • はマルチフォーマットを使用し、クライアントはDIP保護
  • を使用する.
  • アプリケーションは、使用領域と構成領域
  • に分けられます.
  • コンフィギュレーション領域で依存関係(Fix->Rate)を変更してクライアントに注入することで、クライアントコードを変更する必要はありません.
  • ソフトウェア要素を再拡張しますが、使用範囲
  • は変更されません.