このブログ記事は、金英漢講師のSpringコア原理基本編のチュートリアルを参考にした.

歴史

初期、Java側はEJB技術を発表した.
理論はいいですが、高いです.(サーバー1台あたり数千万ウォン)
でも私は良いことを知っていますが、犬は難しいですね.甚だしきに至っては遅い.
だからポジョに戻るって言う人もいました
Plain Old Java Objectは、簡単に言えば、POJOは用語であり、字面の意味で解釈すれば、Java EEなどの重量フレームワークを使用し、そのフレームワークに属する「重い」オブジェクトの作成に反対する古い簡単なJavaオブジェクトである.
このとき、かつてEJBdeveloperの2人の開発者が、それぞれオープンソースでspring、hibernateを作成しました.
JAva側は元使用のORMを捨て、hibernateプロデューサーを雇ってJPAを作成した.
現在のJPAの80%以上がHibernate実装体である.
春という名前の意味は伝統を超えた冬で、新しい季節の始まりです.

コアコンセプト?

Javaベースのオブジェクト向けの最も強力な機能のフレームワーク

オブジェクト向け

抽象、カプセル化、継承、多形性

たけいせい

ロール/実装

ロール:インタフェース、実装:インタフェースを実装するオブジェクト

自動車キャラクター<-K 3(実施)

自動車キャラクター<-アバンド(実施)

クライアント(運転手)に影響を与えることなく、新しい機能を提供できます.

役割と実装によって世界を区別する

役割をインプリメンテーションから分離すると、変更可能な代替が生成されます.=柔軟で容易な変更

内部構造を知らなくてもいいです.

お客様は車の運転方法を知っていればいいです.(内部構造を知る必要はありません)

したがって、キャラクタ(インタフェース)を作成した後、そのキャラクタを実行するインプリメンテーションオブジェクトを作成します.

重要なのは、インタフェースが変わらないように設計されなければならないことです.

Client - Server

クライアント=要求の送信元

サーバ=レスポンス

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

SRP:単一責任原則

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

LSP:リスコフ交換の原則

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

DIP:依存逆転の原則

1.SRP

1階級には1つの責任しかない.

変更の場合、波及が小さい場合、従う法則は良い:

2. OCP

拡張はオープンですが、境界は閉鎖されなければなりません.最も重要

多形性の利用

自動車の例を考えます

新しいインプリメンテーションインタフェースクラスの作成と実装

質問する

A a = new B
-->
A a = new C

下図のように乗り換えるには、コードを変更する必要があります.closedから違反します.
-->誰かが組み立てる必要があります:スプリング容器で完成します.

3.LSP

プログラム内のオブジェクトは、プログラムの正確性を破壊することなく、サブタイプのインスタンスに変換できる必要があります.

すべてのインタフェース規則を使用する必要があります

自動車を例にとると、アクセルを作ると、アクセルを押すと前に進みます.アクセルを押して上に進むとLSP違反になります

4.ISP

複数の特定のクライアントインタフェースは、1つの汎用インタフェースよりも優れています.

自動車を例にとると、自動車を丸めるよりも、整備工、運転手インターフェースを別々に使うほうが明確で、代替の可能性が高い.

5.DIP

抽象に頼るには,具体化に頼るわけにはいかない.

クライアント・コードは実装クラスではなく、インタフェースのみに注目する必要があります.

運転手は車の役割しか知らないはずだ.

依存

A a= new B

-->Aインタフェース、そしてBインタフェース.

暗記する

SPA->単一責任

オープン/クローズ->拡張オープン、変更クローズ

Liskovディスプレイスメント->ディスプレイスメント:実際にインタフェース(実装)を実装する際に勝手にできません.置き換えの時は思うようにできない.

インタフェースの分離:複数の分離がより良い

依存バージョン:依存性逆転:抽象に依存するのは正しいが、関係が逆転し、具体化に依存できない.依存具体化の場合,抽象依存性を逆転させる方法は抽象化に依存する.

上記の例と似ているが、猫は具体的な平凡な動作という構造体に依存する.具体的な等級は変わりやすい.
この過程で,依存性を逆転させる方法は,依存するクラスをあまり具体的でないクラスとすることである.
https://o-o-wl.tistory.com/30

質問する

多形性だけではOCP、DIPは守れない.

トラブルシューティング

スプリングは、依存注入(DI)+DI容器と呼ばれる技術であり、多形性+OCP、DIPをサポートする.

OCP、DIPの原則に従って開発を行い、最終的にスプリングフレーム

を作成した.

理想的な方法は、すべての設計にインタフェースを提供することです.

インタフェースは抽象化されたコストを生み出す.
(したがって、すべてのインプリメンテーションはインタフェースによってxを実現する必要がある)
そのため、インタフェースは拡張機能が必要な場合にのみ使用することをお勧めします.