팩토리패턴, 이터레이터패턴, 전략패턴, 옵저버패턴, 프록시 패턴(핵심내용)

팩토리패턴

예시

• 객체 생성 부분만 추상화한 패턴 -> (상속관계) 느슨한 결합 -> 상위, 하위 클래스 분리 가능 -> 유연성 높음
  • 객체 생성 로직 따로 존재 -> 유지 보수성 높음
• 상위 클래스 -> 뼈대
• 하위 클래스 -> 구체적 내용
• DI가 적용됨

이터레이터패턴

• iterator를 사용해서 collection요소에 접근하는 것
  • 여러 가지 자료형의 구조와는 상관없이 순회 가능!
• 각기 다른 collection 같은 인터페이스로 순회 가능
• 용어
  • collection -> 동일한 요소들의 집합
  • 이터레이터 프로토콜 -> iterable한 객체 순회 시, 사용되는 규칙
  • 이터러블한 객체 -> 배열을 반복 가능한 객체로 바꾼 것!
    • Set 사용시 iterator, hasNext(), next() 요런 느낌쓰~

DI, DIP

• DI(Dependency Injection)
  • 의존한다
    • A -> B (B가 변하면 A도 변한다 = A가 B에 의존한다)
  • DI 적용 X
  • DI 적용 O
  • 장점
    • 외부에서 모듈 생성 -> 모듈을 쉽게 교체 가능한 구조
    • TDD 쉬움, Migration(다른 운영환경으로 이동하는 것) 쉬움
    • App 의존성 방향이 일관 -> 코드 추론 쉬움
  • 단점
    • 결과적으로 Module 증가 -> 복잡도 증가 -> Cost 증가
    • 종속성 주입 컴파일 할 때(런타임 X) -> 컴파일 할 때 종속성 관한 Error 잡기 어려움
• DIP(Dependency Injection Principle)
  • DI하면 DIP도 적용됨

전략패턴

• 객체의 행위 바꾸고 싶다 -> '직접'수정 X, 캡슐화한 알고리즘을 context(개발자가 어떤 작업을 완료하는데 필요한 모든 정보) 안에서 상호 교체 가능하게 하는 것

옵저버패턴

• 주체가 어떤 subject(객체)의 변화를 관찰 후 변화가 있으면, 옵저버들에게 변화를 알려주는 것

프록시패턴

• Subjcet에 접근하기 전 대상의 흐름을 '가로채는' 것
  • 무엇인가를 확인하기 위해서
• 서버 앞단에 두어서 데이터, 보안, 캐싱, 로깅 등에 활용
• 프록시 서버가 대표적