[Design Pattern] 개요
일종의 설계 기법이며, 설계 방법이다.
목적
SW 재사용성, 호환성, 유지보수성을 보장
특징
디자인 패턴은 아이디어임, 특정한 구현이 아님
프로젝트에 항상 적용해야 하는 것은 아니지만, 추후 재사용, 호환, 유지 보수시 발생하는 문제 해결을 예방하기 위해 패턴을 만들어 둔 것
원칙 - SOLID(객체지향 설계 원칙)
1. 하나의 클래스는 하나의 역할만 해야함
2. 확장(상속)에는 열려 있고, 수정에는 닫혀 있어야 함
3. 자식이 부모의 자리에 항상 교체될 수 있어야 함
4. 인터페이스가 잘 분리되어서, 클래스가 꼭 필요한 인터페이스만 구현 하도록 해야함
5. 상위 모듈이 하위 모듈에 의존하면 안됨. 둘 다 추상화에 의존하며, 추상화는 세부 사항에 의존하면 안됨
분류
3가지 패턴의 목적을 이해하기
- 생성패턴: 객체의 생성 방식을 결정
- 구조패턴: 객체간의 관계를 조직
- 행위패턴: 객체의 행위를 조직, 관리, 연합
어댑터 패턴
- 클래스를 바로 사용할 수 없는 경우가 있음
(다른 곳에서 개발했다거나, 수정할 수 없을 때)
중간에서 변환 역할을 해주는 클래스가 필요
사용방법: 상속
호환되지 않은 인터페이스를 사용하는 클라이언트 그대로 활용 가능
향후 인터페이스가 바뀌더라도, 변경 내역은 어댑터에 캡슐화 되므로 클라이언트 바뀔 필요 x
싱글톤 패턴
애플리케이션이 시작될 때, 어떤 클래스가 최초 한 번만
메모리를 할당(static)하고 해당 메모리에 인스턴스를 만들어 사용하는 패턴
즉 싱글톤 패턴은 '하나'의 인스턴스만 생성하여 사용하는 디자인 패턴이다.
왜 쓰나요?
먼저, 객체를 생성할 때마다 메모리 영역을 할당 받아야한다. 하지만 한번의 new를 통해 객체를 생성한다면 메모리 낭비를 방지할 수 있다.
또한 싱글톤으로 구현한 인스턴스는 '전역'이므로, 다른 클래스의 인스턴스들이 데이터를 공유하는 것이 가능한 장점이 있다.
많이 사용하는 경우
주로 공통된 객체를 여러개 생성해서 사용해야하는 상황'
단점: 싱글톤 인스턴스가 혼자 너무 많은 일을 하거나, 많은 데이터를 공유시키면 다른 클래스들 간의 결합도가 높아지게 되는데 이때 개방-폐쇄 원칙이 위배된다.
템플릿 메소드 패턴
-로직을 단계 별로 나눠야 하는 상황에서 적용한다
-단계별로 나눈 로직들이 앞으로 수정될 가능성이 있을 경우 더 효율적이다.
조건
클래스는 추상으로 만든다
단계를 진행하는 메소드는 수정이 불가능하도록 final 키워드를 추가한다
각 단계들은 외부는 막고, 자식들만 활용할 수 있도록
protected로 선언한다.
abstract와 interface의 차이
abstract: 부모의 기능을 자식에서 확장시켜나가고 싶을 때
interface: 해당 클래스가 가진 함수의 기능을 활용하고 싶을 때
팩토리 메소드 패턴
- 객체를 만드는 부분을 Sub class에 맡기는 패턴
옵저버 패턴
- 상태를 가지고 있는 주체 객체 & 상태의 변경을 알아야 하는 관찰 객체
(1 대 1 or 1 대 N 관계)
서로의 정보를 주고받는 과정에서 정보의 단위가 클수록, 객체들의 규모가 클수록 복잡성이 증가하게 된다. 이때 가이드라인을 제시해줄 수 있는 것이 '옵저버 패턴'
스트레티지 패턴(Strategy Pattern)
어떤 동작을 하는 로직을 정의하고, 이것들을 하나로 묶어 (캡슐화) 관리하는 패턴
새로운 로직을 추가하거나 변경할 때, 한번에 효율적으로 변경이 가능하다
컴포지트 패턴(Composite Pattern)
compositie pattern의 사용 목적은 object의 hierarchies를 표현하고 각각의 object를 독립적으로 동일한 인터페이스를 통해 처리할 수 있게한다.
