オブジェクト向けの原理とスプリング

スプリングの誕生

スプリングの履歴

JavaとKotlinベースのWebフレームワーク.ロッド・ジョンソンが2002年に出版した『Expert One One One J 2 EE設計と開発』のソースコードから、徐々に発展してきた.
「スプリング」という名前の由来は、以前Java EE(エンタープライズ版)の規格を実現したEJBが技術的複雑さが増して性能が遅くなるという欠点から脱し、EJB時期を「冬」にたとえ、冬以降の「春」の新たなスタートとなったことにあります.

ばねフレームとくせい

POJO(Plain Old Java Object)メソッド:メソッドを追加するために他のクラスやインタフェースを継承/実装するクラスではなく、基本機能を持つJavaオブジェクトを指します.Java EEを使用する場合、個別のフレームワークを必要としないよりも、Java EEは特定のインタフェースを直接実装または継承する必要がないため、既存のライブラリをサポートするのが容易で、オブジェクトが軽い.

観点に向けたプログラミング(Asspect-oriented Programming,AOP):ログ記録、トランザクション、セキュリティなどの複数のモジュールの汎用機能を別々に管理します.

依存注入:プログラミングでは、コンポーネント間の依存関係は、ソースコードの内部ではなく設定によって定義されます.コード再利用を向上させることで、ソースコードを異なる位置に使用することができ、モジュール間の結合を低減することができる.レイヤとサービスの間に依存性がある場合、springフレームワークは相互に関連します.

制御反転(Inversion of Control,IOC):従来のプログラミングでは,開発者が作成したプログラムが外部ライブラリのコードを呼び出す.逆に、制御の反転により、外部ライブラリコードが開発者のコードを呼び出すことになります.すなわち、Springフレームワークは、フレームワークにおける制御権の必要に応じてユーザのコードを呼び出す.

ライフサイクル管理:SpringフレームワークはJavaオブジェクトの作成、破棄を直接管理し、必要なオブジェクトのみを使用します.

スプリングフレーム

スプリングフレーム

- 핵심 기술 : 스프링 DI 컨테이너 / AOP / 이벤트 등
- 웹기술 : 스프링 MVC / 스프링 WebFlux
- 데이터 접근 기술 : 트랜잭션 / JDBC / ORM 등
- 기술 통합 : 캐시 / 이메일 / 스케줄링 등
- 테스트 : 스프링 기반 테스트 지원
- 언어 : 코틀린 / 그루비

ばね起動

- 스프링을 편리하게 사용할 수 있도록 지원
- 톰캣같은 웹서버를 내장해서 별도의 웹서버 설치 필요 없다
- Starter 종속성 제공 : 라이브러리 사용시 필요한 다른 관련 라이브러리들을 알아서 땡겨준다
- 사용하는 여러 라이브러리들 간의 알맞는 버전 조합을 알아서 세팅해준다
- 관례에 의한 간결한 설정

JAvaとspring

Java言語の特徴はオブジェクト向け言語です.

Springはオブジェクト向け言語の強力な特徴を体現するフレームワークである.

オブジェクト向けプログラミング

コンピュータプログラムを複数の独立した単位、オブジェクトの集合として理解する.各オブジェクトは、メッセージの送受信とデータの処理を行うことができます.柔軟で変化しやすく、大規模なソフトウェア開発に使用されます.

オブジェクト向けプログラミングプロパティ

抽象(抽象)

객체들의 공통적인 특징(기능, 속성)을 도출하는 것
객체지향적 관점에서는 클래스를 정의하는 것을 추상화라고 할 수 있다.

パッヶージ

실제로 구현되는 부분을 외부에 드러나지 않도록 하여 정보를 은닉할 수 있다.
객체가 독립적으로 역할을 할 수 있도록 데이터와 기능을 하나로 묶어 관리하는 것
데이터를 보이지 않고 외부와 상호작용을 할 때는 메소드를 이용하여 통신을 한다. 

継承(継承)

이미 만들어 놓은 상위 객체를 재사용해서 하위 객체를 쉽고 빠르게 만들수 있습니다. 
수정을 할때도 상위객체를 수정해주면 상속받은 모든 하위 객체가 수정이 되므로 유지보수가 쉽다.

たじょうたいせい

다형성(polymorphism)이란 하나의 객체가 여러 가지 타입을 가질 수 있는 것을 의미한다.
부모 클래스 타입의 참조 변수로 자식 클래스 타입의 인스턴스를 참조할 수 있도록 하여 구현한다.

オブジェクト向けプログラミングコア

キャラクターとインプリメンテーションを分離!役割と実装を区別すれば、簡単で柔軟になり、変更も容易になります.

クライアントは、ターゲットのロール(インタフェース)のみを知る必要があります.

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

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

クライアント変更の実装目標自体は影響を受けません.

Java言語の多形性を利用してオブジェクト向けプログラミングを行う.
オブジェクトを設計するときに、キャラクタとインプリメンテーションを明確に区別します.オブジェクトを設計するときに、まずキャラクタを割り当て、次にそのキャラクタを実行するインプリメンテーションオブジェクトを作成します.

ロール=インタフェース

インプリメンテーション=インプリメンテーションインタフェースのクラス、オブジェクト

多形性の本質

実行時に実装インタフェースのオブジェクトインスタンスを柔軟に変更できます.
クライアントを変更することなく、サーバの実装機能を柔軟に変更できます.

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

ロバート・マーティンがまとめたオブジェクト向け設計の5つの原則
単一責任原則:単一責任原則

한 클래스는 하나의 책임만 가져야 한다. 하지만 책임의 범위가 상황에 따라 다르므로 모호하다. 
→ 기준 : 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.

開放閉鎖原則:開放閉鎖原則

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. 
다형성을 활용해서 확장하고 기존의 코드는 변경하지 않는다. 
→ 하지만 인터페이스에서 구현 객체를 변경하는 과정에서 코드는 변경된다. 다형성을 사용해도 OCP 원칙이 깨져버린다. 
그래서 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자(스프링 컨테이너)가 필요하다. 

Liskov Substitution Principle:リスコフ交換の原則

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
다형성에서 하위 클래스는 인터페이스 규약을 지켜야 한다는 것이다.
인터페이스를 구현한 구현체를 믿고 사용하기 위한 원칙이다.

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

특정 클라이언트를 위한 인터페이스 여러개가 범용(하나로 합친) 인터페이스보다 낫다.
자동차 인터페이스를 운전, 정비 인터페이스로 분리한다. 
분리하면 한쪽 인터페이스 자체가 변해도 다른 쪽에는 영향을 주지 않는다.
→ 인터페이스가 명확해지고, 대체 가능성이 높아진다.

依存独立の原則:依存関係を変える原則

'추상화에 의존하고 구체화에 의존하면 안된다'의 원칙을 따르는 방법 중 하나이다.
클라이언트가 구현 클래스를 바라보지 말고 인터페이스만 바라보라는 뜻이다. 역할에 의존해야 한다는 것과 같다.

客体向けの核心は多形性である.ただし、マルチフォームを使用してインプリメンテーションオブジェクトを変更する場合、クライアントコードも変更されます.だから部品を交換するように簡単に開発することはできません.
すなわち,多形性だけではOCP,DIPを保護できない.
スプリングは依存注入(DI)を採用し,多形性+OCP,DIPをサポートする.
→クライアントコードを変更しないで部品交換のように開発
アプリケーション設計の役割をインプリメンテーションから分離し、インプリメンテーションがいつでも柔軟に変更できるようにするオブジェクト向けの設計です.→すべての設計にインタフェースを提供する
しかし、実際の操作でインタフェースを導入すると抽象化されたコストが発生します.したがって、拡張機能の可能性がなければ、実装されたクラスを直接使用し、インタフェースを導入するために後で必要に応じて再パッケージすることができる.