디자인패턴(2)

팩토리패턴

• 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고,
  하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴
• 상위 클래스에서는 객체 생성방식에 대해 알 필요가 없어져 유연성을 갖게 되며
  객체 생성 로직은 하위클래스에서만 관리 되기 때문에 유지보수성이 증가

 

이터레이터패턴

• 이터레이터(iterator)를 사용하여 컨테이너의 요소들에 접근하는 디자인패턴
  (컨테이너 : 동일한 요소들을 담아놓는 집합 - 배열, 맵 등)
• 각기 다른 자료구조들을 똑같은 인터페이스로 순회를 쉽게 할 수 있다는 장점이 있음

 

의존성주입(DI, Dependency Injection)

• 의존성주입이란 메인 모듈(main mudule)이 '직접' 다른 하위모듈에 대한 의존성을 주기보다는
  중간에 의존성 주입자(dependency injector)가 이 부분을 가로채 메인 모듈이 '간접'적으로 의존성을 주입하는 방식

• 이를 통해 메인 모듈과 하위모듈간의 의존성을 조금 더 느슨하게 만들 수 있으며 모듈을 쉽게 교체 가능한 구조로 만듬

 

의존관계역전원칙(DIP, Dependency Inversion Principle)

• 의존성 주입을 할 때는 의존관계역전원칙이 적용
• 상위 모듈은 하위 모듈에 의존해서는 안 되고 둘 다 추상화에 의존해야 함
• 추상화는 세부사항에 의존해서는 안 되고 세부 사항은 추상화에 따라 달라져야 함
• 장점
  • 외부에서 모듈을 생성하여 dev.add(new BackendDeveloper()) 이런식으로 집어넣는 구조가 되기 때문에
    모듈들을 쉽게 교체할 수 있는 구조
  • 단위 테스팅과 마이그레이션이 쉬워짐
  • 애플리케이션 의존성 방향이 좀 더 일관되어 코드를 추론하기가 쉬워짐
• 단점
  • 결국에는 모듈이 더 생기게 되므로 복잡도가 증가
  • 종속성 주입자체가 컴파일 할 때가 아닌 런타임 때 일어나기 때문에
    컴파일을 할 때 종속성 주입에 관한 에러를 잡기가 어려워질 수 있음

 

전략 패턴

• 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호교체가 가능하게 만드는 디자인패턴

 

옵저버 패턴

• 주체가 어떤 객체(subject)의 상태변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해
  옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인패턴
• ex) 트위터의 메인 로직, MVC패턴

 

프록시 패턴

• 객체가 어떤 대상 객체에 접근하기 전,
  그 접근에 대한 흐름을 가로채서 해당 접근을 필터링하거나 수정하는 등의 역할을 하는 계층이 있는 디자인패턴
• ex) 서버 앞단에 두어 캐싱, 로깅 등에 활용하는 프록시서버