Code Design Pattern

Code Design Pattern

• Code Design Pattern은 잘 만들어진 코드의 설계도인 동시에 개발자들의 공통 도구 입니다.
• 왜 써야 할까?
  • 반복적으로 등장하는 문제에 대해 이미 검증된 해결책입니다.
  • 구조가 명확해지기 때문에, 나중에 보거나 협업할 때도 이해하기 쉽고, 유지보수하기 좋습니다.
  • 협업 시 커뮤니케이션 용이합니다.
  • 패턴을 잘 활용하면, 시스템이 커져도 유연하게 변경 및 확장이 쉬운 코드를 만들 수 있습니다.

 

 

 

 

 

Module Pattern

• 코드를 하나의 모듈로 묶고, public/private 접근 제어를 통해 캡슐화(encapsulation)를 구현하는 패턴입니다.
• 장점
  • 큰 파일을 작고 재사용 가능한 조각들로 나눌 수 있어, 유지보수와 협업에 유리합니다.
  • 모듈 안의 값들은 기본적으로 비공개(private) 입니다. export 키워드를 사용해야만 외부에서 접근할 수 있어, 특정 값들을 외부에 노출하거나 숨기기 쉽게 만들 수 있습니다. 

 

 

 

 

 

Singleton Pattern

• 어떤 클래스나 객체를 오직 한 번만 생성하고, 항상 같은 인스턴스를 반환하도록 보장하는 패턴입니다.
• ES2015 모듈은 기본적으로 싱글톤입니다. 모듈 자체가 한 번만 로드되므로, 굳이 별도로 싱글톤을 만들 필요가 없습니다.
  • ES2015 (ES6)에서 import와 export를 사용하는 모듈 시스템은, 하나의 모듈 파일이 애플리케이션 내에서 단 한 번만 실행되고, 메모리에 딱 한 번만 로드됩니다. 즉, 어떤 모듈을 여러 번 import하더라도 항상 같은 인스턴스, 같은 객체를 참조합니다.
• 장점
  • 인스턴스를 하나만 생성하므로 불필요한 메모리 낭비를 줄일 수 있습니다.
• 단점
  • 여러 컴포넌트나 모듈이 동시에 같은 인스턴스를 참조하기 때문에, 누군가 의도치 않게 값을 변경하면 전체 애플리케이션에 영향을 미칠 수 있습니다. 따라서, 상태를 변경하는 순서나 타이밍이 중요할 경우, 데이터 흐름을 추적하고 디버깅하는 게 매우 어렵습니다.
  • 싱글톤 인스턴스는 한 번 생성되면 모든 테스트가 동일한 인스턴스를 공유합니다. 따라서, 하나의 테스트가 값을 바꾸면, 다른 테스트에도 영향을 미치게 되어 독립적인 테스트 작성이 힘들어집니다. 매 테스트 후 상태를 초기화하거나 별도의 mocking 작업이 필요할 수 있습니다.

 

 

 

 

 

Proxy Pattern

• 실제 객체에 직접 접근하지 않고, 프록시(Proxy) 객체를 통해 접근을 제어하거나 기능을 추가할 수 있도록 하는 패턴입니다.
  • Proxy 객체는 실제 객체를 호출하는 대신, 요청을 가로채고 처리하는 중간자 역할을 합니다.
  • ex : Virtual Proxy, Remote Proxy, Protective Proxy, Smart Proxy, Cache Proxy
• 장점
  • 실제 객체에 대한 직접적인 접근을 차단하고, 이를 대신하여 프록시 객체가 객체 접근을 제어합니다. 이를 통해 중요한 객체에 대한 불필요한 수정이나 잘못된 접근을 방지할 수 있습니다.
  • 프록시 패턴을 사용하면 객체가 실제로 필요할 때만 생성되도록 할 수 있습니다. 이를 통해 불필요한 객체 생성을 방지하고, 지연 로딩(Lazy Loading)을 구현할 수 있습니다.
• 단점
  • 프록시 객체가 모든 접근을 가로채기 때문에, 매번 프록시를 거쳐야 하므로 성능 저하가 발생할 수 있습니다. 
  • 실제 객체와 프록시 객체를 관리해야 하고, 이로 인해 코드의 유지보수가 어려워질 수 있습니다.
  • 프록시 패턴을 도입할 필요가 없는 단순한 객체에 적용할 경우, 오히려 과도한 추상화로 인해 코드가 불필요하게 복잡해질 수 있습니다. 작은 객체에 프록시를 추가하는 것은 유지보수나 코드 관리에서 비효율적일 수 있습니다.
• 프록시 패턴이 유용한 상황
  • 객체에 대한 접근 제어 또는 보안이 필요할 때
  • 객체 생성 비용이 크고 지연 초기화가 필요한 경우
  • 원격 객체에 대한 통신 처리가 필요할 때
  • 메모리 관리 또는 리소스 관리가 중요한 경우 (ex : 큰 이미지 파일이나 비디오 파일을 다룰 때, 프록시 객체가 메모리에 로드된 파일을 대신하여 작업을 처리하고, 실제 파일에 접근이 필요한 순간에만 해당 파일을 로드할 때)
  • 여러 객체를 그룹화하여 다루고자 할 때 (ex : 여러 개의 이미지를 하나의 프록시 객체로 관리)

 

 

 

 

 

Observer Pattern

• 객체 간 1:N 의존 관계를 정의해 두고, 어떤 객체의 상태가 변할 때 그 객체에 의존하는 다른 객체들이 자동으로 알림을 받고 갱신될 수 있도록 하는 패턴입니다.
• 장점
  • 옵저버 객체는 옵저버블 객체와 긴밀하게 결합되지 않아서, 언제든지 결합하거나 분리할 수 있습니다. 옵저버블 객체는 이벤트를 모니터링하는 역할을 하고, 옵저버는 받은 데이터를 처리하는 역할을 맡습니다.
• 단점
  • 모든 구독자에게 알림을 보내는 데 시간이 많이 걸릴 수 있습니다. 옵저버가 복잡해지거나 구독자가 너무 많으면 성능 저하가 발생할 수 있습니다.
  • 상태가 변경되면 내부적으로 알림이 퍼지기 때문에, 어디서 어떤 로직이 실행되는지 파악이 어려워 디버깅이 복잡해집니다.
  • 옵저버가 Subject에 등록됐지만 제거되지 않으면, 메모리 누수의 원인이 됩니다.
• 옵저버 패턴이 유용한 상황
  • 사용자가 데이터를 변경하면, 여러 UI 컴포넌트가 자동으로 갱신되어야 하는 경우
  • 버튼 클릭, 키 입력, 네트워크 이벤트 등 이벤트 감지
  • 데이터가 바뀌었을 때 구독자들에게 알림 전송할 때
  • 공통 데이터를 여러 곳에서 사용하면서 자동 동기화가 필요한 경우
  • 어떤 작업이 끝난 후 여러 처리를 동시에 해야 할 때

 

 

 

 

 

Factory Pattern

• 객체 생성 로직을 별도의 팩토리 함수(또는 클래스)에 분리하여, 다양한 타입의 객체를 유연하게 생성할 수 있게 하는 패턴입니다.
• 장점
  • 객체 생성의 책임을 팩토리에 위임해서 유연하고 확장 가능한 코드 구조를 만들 수 있어 캡슐화가 가능합니다.
  • 객체 생성을 중앙집중화 할 수 있어 하나의 팩토리에서만 변경하면 전체 적용이 가능하여 일관성 보장이 됩니다.
  • 객체 생성 로직이 한 곳에 모여 있으므로, 테스트 시 의존성 주입 또는 Mock 객체 설정이 용이합니다.쉬
• 단점
  • 단순한 객체도 Factory를 통해 생성하게 되면, 오히려 불필요하게 클래스 수와 추상화가 많아질 수 있습니다.
  • 클래스 간 의존성 관계가 외부에 드러나지 않아 디버깅에 어려움이 있습니다.
• 팩토리 패턴이 유용한 상황
  • 객체 생성 과정이 복잡하거나 조건에 따라 달라지는 경우
  • 인터페이스 기반 설계를 통해 확장성과 테스트를 고려할 때
  • 객체 생성 시, 클라이언트 코드에 의존성을 최소화하고 싶을 때

 

 

 

 

 

Prototype Pattern

• 기존 객체를 복제(clone) 하거나, 프로토타입 체인을 통해 상속하여 새로운 객체를 만드는 패턴입니다.
• 장점
  • 기존 객체를 복사하기 때문에, 무거운 생성 과정을 매번 반복할 필요가 없습니다.
  • 프로토타입을 통해 공통 기능을 공유하므로, 메모리를 아낄 수 있고, 코드 재사용성을 높입니다.
  • 기존 객체에 속성을 추가하면, 복제 객체도 즉시 그 영향을 받을 수 있어 객체 확장성이 용이합니다.
• 단점
  • 객체가 어디서 복제됐는지 파악이 어려워 디버깅 복잡할 수 있습니다.
• 프로토타입 패턴이 유용한 상황
  • 복제 기반으로 비슷한 객체를 많이 생성할 때
  • 공통 기능이 많은 객체를 빠르게 확장하고자 할 때
  • 퍼포먼스가 중요한 곳 (ex. 게임, 시뮬레이션 등)