スプリングコアの原理

7224 ワード

ばねテキストリンク

🌱核心原理を理解し、思考し、さらに成長する.🌱
スプリングフレーム

キーテクノロジー:スプリングDI容器、AOP、アクティブ、その他

Webテクノロジー:Spring MVC、SpringWebFlux 24579182

データアクセス技術:トランザクション、JDBC、ORMサポート、XMLサポート

テクノロジー統合:キャッシュ、Eメール、リモート・アクセス、計画

試験:スプリングベースの試験

をサポートする

言語:コートリン、グルピー

スプリングの真のコア

SpringはJava言語ベースのフレームワーク

Java言語の最大の特徴-オブジェクト向け言語

Springオブジェクト向け言語を採用した強力なフレームワーク

スプリングフレーム

オブジェクト向けアプリケーションの開発を支援
オブジェクト向けプロパティ

抽象

カプセル化

継承

多形性

たけいせい

の役割と実装世界を

に分ける

の役割と実現を区別することで、世界は簡単になり、柔軟になり、変更も便利になります.

の利点

クライアントは、ターゲットの役割(インタフェース)を理解するだけでよい.

クライアントは、実装対象の内部構造を理解する必要はありません.

クライアントは、実装対象の内部構造の変更の影響を受けません.

クライアントは、インプリメンテーションオブジェクト自体の変更の影響を受けません.

ロール=インタフェース

実装=実装インタフェースのクラス、実装対象

💁‍♀️クライアントを変更することなく、サーバの実装機能を柔軟に変更できます.
スプリングとオブジェクトに向かう

多形性が一番重要!

スプリングは、多形性の最大化を助けることができる.

スプリングでいう制御反転(IoC)、依存関係注入(DI)は多形性を利用してキャラクタと
実施を容易にする.

スプリングを使ってレゴの積み木を組み立てるように!舞台を演じる俳優を選ぶように!実装を簡単に変更できます.

良好なオブジェクト向け設計五原則(SOLID)

SRP:単一責任原則

OCP:オープン/クローズの原則

LSP:Liskov置換原則

ISP:インターフェース分離原則

DIP:依存関係逆転原則

SRP単一責任原則

クラスは1つの責任しか負いません.

の責任はあいまいです.

は大きくても小さくてもいいです.

の文脈と状況とは異なります.

の重要な基準は変更です.

変更が発生した場合、影響が小さい場合は、単一の責任原則に従う必要があります.

例)UIの変更、オブジェクトの作成および使用の分離

OCP開放-閉鎖の原則

ソフトウェア要素は拡張時にオープンですが、変更時には閉じた

でなければなりません.

という嘘?拡張するには、もちろん既存のコードを変更しますか?

の多形性

を利用する.
新しいクラス実装

インタフェースを作成することによって、

の新しい機能を実現します.

では、そこから学んだ役割と実装との分離について説明します.

public class MemberService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
 // private final MemberRepository memberRepository = new JdbcMemberRepository();
...

MemberServiceクライアント直接選択実装クラス->🚫DIP違反
LSPリスク両替の原則

プログラム内のオブジェクトは、プログラムの正確性を破壊することなく、サブタイプのインスタンスに置き換えられます.

ができるはずです

多形性では、サブクラスは、多形性をサポートするために、すべてのインタフェースの約束を遵守する必要があります.
一つの原則、インタフェースを体現する実装体を信じて使用するには、この原則が必要である.

はコンパイルに成功した物語だけではありません

例)自動車インタフェースのEXCELは、前に移動する機能を有し、後に移動することはLSPに違反する、速度が遅くても前に移動する

である.
ISPインタフェース分離の原則

特定のクライアント向けの複数のインターフェースは、1つの汎用インターフェース

よりも優れている.

自動車インタフェース->運転インタフェース、メンテナンスインタフェースから

分離

ユーザークライアント->パイロットクライアント、メンテナンス担当クライアント

に分離

離脱後、メンテナンスインターフェース自体が変化し、ドライバークライアント

に影響しない.

インタフェースは明確で、代替性が高い.

DIP依存関係逆転の原則

プログラマーは「具体化ではなく抽象化に頼る」と話しています.依存性注入はこの原則である
これは聖書に従う方法の一つです.

簡単に言えば、実装クラスに依存するのではなく、インタフェースに依存する
これは彼を前述の役(Role)に依存させることに等しい.オブジェクトの世界でも、実装体を柔軟に変更するには、クライアントがインタフェースに依存する必要があります.インプリメンテーションに依存すると、変更は非常に困難になります.

public class MemberService {
    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository){
        this.memberRepository = memberRepository;
    }

@Configuration
public class SpringConfig {

    private final MemberRepository memberRepository;

    @Autowired
    public SpringConfig(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository);
    }