싱글톤 패턴

• 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴

비용 Down / 의존성 Up

장점

• 데이터베이스 연결 모듈에 많이 사용
  -> DB.instance라는 하나의 인스턴스를 기반으로 생성가능하여, 데이터베이스 연결에 관한 인스턴스 생성 비용이 절감

단점

• 의존성이 높아진다. (= 종속성이 높아진다.)
• TDD(Test Driven Development)이 어렵다. 독립적이어야하는 단위테스트를 기반으로 하는 TDD는 하나의 인스턴스를 기반으로 구현하는 싱글톤패턴과 맞지 않다.

의존성 주입
모듈간의 강한 결합성을 해결하기 위해 의존성 주입(Dependency Injection)을 통해 결합을 조금 더 느슨하게 만든다. (메인모듈이 직접X -> 간접O)

But, 모듈들이 분리될수록 클래수 수가 늘어나서 복잡성이 증가될수 있고, 약간의 런타임 패널티가 생길 수 있다.

원칙

• 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않는다.
• 둘다 추상화에 의존해야하며, 이때 추상화는 세부 사항에 의존하지 않는다.

팩토리 패턴

• 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴
• 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴

장점

• 객체 생성 로직에 따로 떼어지는 느슨한 결합 상태가 되고 코드를 리팩토링하더라도 한 곳만 고칠 수 있으므로 유지 보수성이 증가
  (객체지향 기본원칙 중 OCP에 따르면 확장에 있어서는 열려있어야 하고, 수정에 있어서는 닫혀있어야한다는 말. (= 수정이 일어날 부분과 그렇지 않을 부분을 분리))

단점

• 패턴을 구현할 많은 서브 클래스를 도입해야하므로 코드가 복잡해진다.

팩토리 메서드 패턴 VS 추상 팩토리 패턴

팩토리 메서드 패턴

• 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정하게 만드는 패턴
• 1개의 하위 클래스 안에서 매개변수를 통하여 조건을 따로 각각의 객체를 생성 -> 다형을 배제한 방법

추상 팩토리 패턴

• 많은 수의 연관된 서브 클래스를 특정 그룹으로 묶어 한번에 교체할 수 있도록 만든 디자인 패턴
• 생성해야할 각각의 객체마다 하위 클래스(factory)를 생성하여, 원하는 하위클래스를 결합하도록하는 방식 -> 복수의 하위클래스

참고:https://yeah.tistory.com/13
https://velog.io/@ellyheetov/Factory-Pattern

잠깐) Enum

상수의 집합을 정의할때 사용되는 타입이다. 상수나 메서드 등을 집어넣어서 관리하며 코드를 리책토링할 때 해당 집합에 관한 로직 수정시 이부분만 수정하면 되므로 코드 리팩토링 시 강점이 생긴다.

전략패턴

• 정책패턴이라고도하며, 객체의 행위를 바꾸고 싶을 경우 '직접' 수정하지 않고, 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴
• 동일한 목적을 지닌 알고리즘군을 인터페이스로 묶고 캡슐화하여 서로 대체가 가능하게 사용하는 것

예시) 우리가 물건을 결제할시 네이버페이, 카카오페이, 등 다양한 방법으로 결제하듯이 전략만 바꿔서 두 가지 방식으로 결제하는 경우

장점

• 변경 부분만을 빼내어 구현하므로 코드 중복을 방지
• 알고리즘을 쉽게 대체 가능
• 확자엉이 용이

단점

• 알고리즘이 늘어날 수록 객체도 무한정으로 증가
• 클라이언트가 사용할 객체를 직접 결정하므로 수많은 알고리즘에 대한 성능과 효율에 신경써야 한다.

잠깐) 컨텍스트

프로그래밍에서의 컨텐스트는 상황, 맥락, 문맥을 의마하며 개발자가 어떠한 작업을 완료하는데 필요한 모든 관련 정보를 말한다.

참고: https://scorpio-mercury.tistory.com/21

옵저버 패턴

• 주체(관찰자)가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴
• 어떠한 '이벤트'가 일어나는 것을 감시하는 패턴

ex) B에게 일어나는 이벤트를 A에게 알리기 위해서 종(인터페이스)를 울린다. 이때 이 인터페이스가 바로 옵저버!(B가 구현된 인터페이스 메서드를 호출함으로써 이벤트를 전달하는 행위 = callback)

• 주로 MVC 패턴에서 사용
  주체라고 할 수 있는 model에서 변경사항이 생겨 update()메소드로 옵저버인 view에 알려주고 이를 기반으로 controller가 작동

장점

• 실시간으로 한 객체의 변경사항을 다른 객체에게 전파 가능
• 느슨한 결합으로 시스템이 유연하고 객체 간의 의존성 제거

단점

• 너무 많이 사용되면, 상태 관리가 힘들다
• 데이터 배분에 문제가 생기면 큰 문제로 야기 가능

잠깐) 상속 & 구현

• 상속(extends): 상속은 자식 클래스가 부모 클래스의 메서드 등을 상속받아 사용하며 자식 클래스에서 추가 및 확장을 할 수 있는 것. 이로 인해 재사용성, 중복성의 최소화가 이루어진다.
• 구현(implements): 부모 인터페이스를 자식 클래스에서 재정의하여 구현하는 것을 말하며, 상속과는 달리 반드시 부모 클래스의 메서드를 재정의하여 구현해야 힌다.

상속과 구현의 차이

• 상속은 일반 클래스, abstract 클래스를 기반으로 구현
• 구현은 인터페이스를 기반으로 구현

참고: https://velog.io/@haero_kim/%EC%98%B5%EC%A0%80%EB%B2%84-%ED%8C%A8%ED%84%B4-%EA%B0%9C%EB%85%90-%EB%96%A0%EB%A8%B9%EC%97%AC%EB%93%9C%EB%A6%BD%EB%8B%88%EB%8B%A4