디자인 패턴

1. 싱글톤 패턴

• 어떤 클래스가 유일하게 1개만 존재해야 할 때 사용.
• 예를 들어 어떤 프리터기에 여러 대의 컴퓨터가 접속해야 사용하는 것과 비슷한 논리이다.
• 소켓 통신을 위한 socketClient를 싱글톤 패턴으로 생성하는 예시
• 내 경험으로는 보통 Util 클래스 들을 싱글톤으로 만들었다. 주소를 주면 지역을 추출해 주는 유틸클래스 같은 것.

2. 어댑터 패턴

• 서로 호환이 안되는 인터페이스를 호환되도록 만들어주는 장치
• 예를 들어 110V, 220V 인터페이스가 있을 때 어떤 기계가 둘 다 이용할 수 있도록 해주는 돼지코 같은 개념이다.
• DDD 패턴으로 도메인별로 모듈을 쪼개서 개발했는데, 이 도메인들을 다 호출할 수 있는 Core 모듈에서 실제 도메인 내부의 메서드를 호출해서 쓸 때 어댑터를 사용했던 경험이 있다.

3. Proxy 패턴

• 스프링 AOP는 프록시로 되어 있다.
• 실제 클래스가 아닌 프록시 클래스를 통해서 대신 전달하는 형태.
• 캐시 기능에 사용.
• SOLID 원칙중 개방폐쇄 원칙과 의존 역전 원칙을 따른다.
• JPA도 그렇고 AOP도 그렇고 인지도 잘 못하는 상태로 밥 먹듯이 쓰고 있는 것.

4. Decorator 패턴

• 기존 뼈대 클래스는 유지하되, 이후 필요한 형태로 꾸밀 때 사용한다.
• 상속의 대안으로도 활용할 수 있다.
• 개방폐쇄 원칙과 의존 역전 원칙을 따른다.
• 데코레이터는 진짜 써본 적이 없는 것 같다.

5. Observer 패턴

• 특정 이벤트가 일어났을 때 미리 등록된 다른 클래스에 통보해주는 패턴
• 예시로는 eventListener에서 사용.
• 거래소 개발할 때 매수/매도 오더북에 이벤트리스너를 걸어서 체결이 되면 결제를 이행할 수 있도록 하는 곳에 옵저버 패턴을 사용했다. 체결 후에 알림을 보내는 곳에도 사용했다.

6. facade 패턴

• 여러 객체와 실제 사용하는 서브 객체 사이에 복잡한 의존관계가 있을 때 중간에 facade라는 객체를 두고 여기서 제공하는 인터페이스만 활용하여 기능을 사용하는 방식.
• 이거는 DDD에서 Core 모듈의 특정 도메인 applicationService에 만든 메서드들에 해당하는 것 같다.
• Core의 GameApplicationService에서 어떤 정보를 각 도메인의 서비스 레이어를 호출해서 조립해서 데이터를 만드는데 이 패턴이 사실 파사드 패턴으로 볼 수 있는 것 같다.

7. Strategy 패턴

• 객체지향의 꽃이라 불린다.
• 유사한 행위들을 캡슐화하여 객체의 행위를 바꾸고 싶은 경우에 직접 변경하는 것이 아니라 전략만 변경하여 확장에 유연성을 제공하는 패턴이다.
• 개방폐쇄 원칙과 의존 역전 원칙을 따른다.
• 전략을 가지고 있는 Strategy 객체가 있고, 전략 객체를 사용하는 컨텍스트 객체가 있어서 전략 객체를 생성해서 컨텍스트에 주입한다.
• 인코딩을 할 때 Base64를 쓸지, SHA-256을 쓸지 하는 걸 골라서 넣는 방식에 해당하는 것 같다.