[JAVA] 중간고사 대비

관계

Generalization (is-a) : extends

단일상속만 허용

강한결합

실선 삼각형

Realization : implements

다중상속 가능

Interface에는 메소드만 정의 가능

점선 삼각형

Association (has-a)

기본적으로 실선 화살표 (서로 참조하는 경우 실선)

소유하는 경우 마름모로 표현, 강도에 따라 색 다름

Dependency (use-a)

소유하지 않고 일시적으로 사용 (parameter로 전달)

점선 화살표

---

---

Overloading

이름이 같은데 인자가 달라

리턴 타입만 다른 건 안 돼

Overriding

상속받은 method를 다르게 구현 (동적바인딩)

접근제한을 더 강하게 만들수는 없음

---

추상클래스

이따 꼭 만들어야 해

Interface와 다르게 변수 필드도 포함

new 안돼요

---

https://shinyunha.tistory.com/2

[JAVA] Generic & Collection

https://shinyunha.tistory.com/3

[JAVA] Thread

---

결합도는 낮추고(떨어지기 쉽게) 응집도는 높이자(성격은 비슷하게)

 

Single Responsibility: 단일 책임의 원칙

CoffeeMaker, Coffee, CoffeeMachine은 모두 커피를 만들기만 하고 주문을 받지는 않습니다. 만약 주문을 받고 싶다면 새로운 클래스를 생성해야합니다.

 

Open/Closed: 개방/폐쇄 원칙

만약 아인슈페너를 Coffee에 추가하고 싶다면 Coffee interface 구현을 통해 손쉽게 추가할 수 있습니다. 그리고 아인슈페너를 추가했다고 해서 다른 코드들이 망가지지 않습니다.

 

Liscov Subsitution: 리스코프 치환 원칙

MilkFrother는 CoffeeMachine과 관계를 가지지 않습니다. Coffee를 brew한다는 상위 타입의 특성을 따르지 않기 때문입니다.

 

Interface Segregation: 인터페이스 분리 원칙

레시피를 담고 있는 Coffee와 brew하는 CoffeeMachine은 인터페이스가 분리되어 있습니다.

 

Dependency Inversion: 의존성 역전 원칙 (제어의 역전 - IoC, 의존성 주입 -  DI)

CoffeeMaker가 Coffee들을 생성하여 레시피를 찾는 것이 아니라, coffee를 주입받아서 prepare() 메소드를 호출합니다. Coffee들이 CoffeeMachine들을 생성하여 brew하는 것이 아니라 machine을 주입받아서 brew() 메소드를 호출합니다. 

주입의 3가지 방법!

1. 생성자를 이용한 주입 (권장)

2. Setter로 구현한 주입

3. 필드에 직접 주입

---

디자인 패턴

 

생성 패턴

싱글톤 (객체가 오직 하나)

private static으로 객체를 하나만 생성해두고 외부에서는 new 하지 않고, getInstance()로 가져다 씀

+ static: 전역, 공유 상황일 때 사용, 한 번만 생성

 

팩토리 메소드 (객체를 내가 만드는 게 아니라 위임)

---

구조 패턴 - 시스템을 어떻게 만들것인가?

데코레이터 

eg) 커피메어커

---

행위 패턴 - 객체 간의 상호작용과 책임 분배 방식

전략