Singleton은 디자인 패턴의 일부이다. 그럼 디자인 패턴이 무엇인지에 대해 알아보자.

디자인 패턴 소개

• 인간은 패턴 인식에 최적화되어 있다.
• 프로그래밍 작업에 있어서도 귀납적으로 발견한 어떠한 패턴이 있을 것이다.
• 이렇게 소프트웨어 설계에서 흔히 겪는 문제에 대한 해결책으로 나온 것이 디자인 패턴
• 완성된 설계가 아니다.
• 특정 문제를 다양한 환경에서 해결하는 법을 설명한 가이드로 생각하자.
• GoF(Gang of Four), 1994

디자인 패턴 장단점

장점

1. 이미 테스트를 마친 검증된 개발 방법을 사용해 개발 속도를 향상시킬 수 있다.
   • 새 코드 작성시 곧바로 알 수 없는 문제가 있다.
   • 아직 드러나지도 않았고 예측도 못한 문제들
   • 증명된 패턴은 이런 문제에 대비되어 있다.
2. 공통 용어 정립을 통한 개발자들 간의 빠른 의사소통을 촉진
   • "XX 패턴을 사용하면 돼"로 의사소통 끝
   • 단, 모두가 해당 패턴, 용어를 알고 있어야 한다.

단점

1. 고치려는 대상이 잘못되었다.
   • 책의 과반수는 C++ 언어의 미지원 기능에 대한 미봉책이다.
   • 절반은 필요없다 라는 논문도 있었음
2. 곧바로 적용할 수 없는 참고 가이드를 "패턴"이라 할 수 없다.
3. 잘못 적용하는 경우가 빈번하다.
   • 오히려 복잡해짐
4. 비효율적인 해법이 되는 경우가 많다.
   • 추상적, 범용적 => 재사용성을 고려 => 성능 저하
   • 코드 중복이 많아짐
5. 다른 추상화 기법과 크게 다르지 않다.
   • 이미 존재하던 현상에 왜 굳이 건축 용어를 사용하는가?

디자인 패턴의 실제 목적

• 대상 독자: 이미 OO 설계를 좀 해본 프로그래머
• 새 개념이 아니라 지인끼리 공유하던 설계 방법을 정리
  • OO 설계 중 발생할 수 있는 문제에 특화된 간단하고 우아한 방법
  • 재활용성과 유연성을 높이기 위한 설계 방법
• 처음 읽고 이해 안되더라도 괜찮다.
• 100% 완성된 목록이 아니다.
  • 현재(1994년) OO 설계에 대한 생각들을 정리한 것
  • 계속 바뀔 것이라 생각한다.

94년 이후 제대로된 디자인 패턴 책이 나오지 않았다. == 해당 책에 문제가 많을 가능성이 높다.

디자인 패턴이 비판받는 실제 이유

• 커뮤니티에서 의도적으로 약을 팔았다.
• 세상이 바뀌었다.
  • 자체 개발팀 증가
  • 제품에 대한 인식, 비즈니스 모델 변화: 버전 별 배포, 지원 기간
  • 배포 방식 변화
  • Git 등의 버전 관리 시스템
  • 인터넷에 더 훌륭한 해답이 많음

그러면 왜 배우나

• 그래도 여전히 언급되기 때문에, 알아두기는 하려고.
• 그나마 몇 개 많이 쓰이는 패턴이 있다.
  • 하지만 대부분은 다형성에 기반한 추상화에 기초한다.

디자인 패턴 공부법

• 디자인 패턴 배웠다고 쓸생각하지 말 것.
  • 내 코드가 정확히 어떻게 도는지 이해되기 전까진 X
• 스택 오버플로우에서 해법을 먼저 찾을 것
• 남의 코드를 보고 추상적으로 이해가 되는 수준까지 기다려라.
• 모자란 실력을 숨기지 마라.

여기서 배울 패턴들

1. 팩토리 메서드 (Factory Method)
2. 빌더 (Builder)
3. 싱글톤 (Singleton)
4. 어댑터 (Adapter) == Wrapper
5. 프록시 (Proxy)
6. 책임 연쇄 (Chain of Responsibility)
7. 옵저버 (Observer)

Reference

• Pocu Academy