📋 Design Pattern

디자인 패턴은 소프트웨어 개발에서 자주 발생하는 문제를 해결하기 위한 검증된 방법

❓ 쓰는 이유

• 코드 재사용성: 동일한 패턴을 여러 곳에서 적용할 수 있어 코드 중복을 줄이고, 생산성을 높임

• 유지보수성: 구조화된 코드로 문제를 해결 -> 유지보수가 쉬워지고 새로운 요구사항이 생겼을 때 코드 변경이 간편

• 확장성: 객체나 모듈을 확장하거나 변경하는 것이 용이하여, 시스템이 커져도 유연성을 유지 가능

• 효율적인 협업: 팀 내에서 디자인 패턴을 공유하면, 서로의 코드를 이해하고 협업하는 데에 도움

---

📗 생성 패턴 (Creational Patterns)

객체를 생성하는 방식과 관련된 패턴

📄 싱글톤 (Singleton)

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

장점 및 사용 이유

• 전역 접근: 하나의 인스턴스를 애플리케이션 전역에서 공유해, 설정 관리나 데이터베이스 연결 같은 리소스를 효율적으로 관리할 수 있음.

• 메모리 절약: 객체를 한 번만 생성해 메모리 사용을 줄이고, 불필요한 중복 생성이 없음.

• 일관성 유지: 동일한 객체를 여러 곳에서 사용해 상태의 일관성을 보장할 수 있음.

단점 및 TDD, 의존성 주입과의 관계

• 테스트 어려움 (TDD 문제): 싱글톤은 전역 상태를 공유해 테스트가 독립적으로 수행되기 어려움. 테스트 주도 개발(TDD)에서 문제를 일으킬 수 있음.

• 의존성 증가: 클래스가 싱글톤에 직접 의존하면 결합도가 높아져 코드의 유연성이 떨어짐.

• 의존성 주입으로 해결: 의존성 주입을 통해 싱글톤 객체를 주입받으면, 모의 객체(Mock)를 사용해 테스트 가능성을 높이고, 결합도를 줄일 수 있음.

TDD : 테스트를 먼저 작성하고 이를 통과하는 코드를 구현하는 방식
의존성 주입 : 객체를 외부에서 주입받아 결합도를 낮추고 테스트를 용이하게 하는 기법

📄 팩토리 메소드 패턴 (Factory Method Pattern)

객체 생성의 책임을 서브클래스에 위임하는 패턴
상위 클래스는 객체 생성 방법을 알 필요 없으며, 하위 클래스가 구체적인 객체를 생성함.

장점 및 사용 이유

• 유연성: 객체 생성 로직을 하위 클래스에서 변경할 수 있어 유연한 설계가 가능함.

• 확장성: 새로운 객체가 추가되더라도 상위 클래스를 수정하지 않으므로, 코드의 확장성과 유지보수성이 높아짐.

• 코드 캡슐화: 객체 생성 과정을 분리해 클라이언트 코드가 생성 로직을 알 필요 없게 하여 코드가 간결해짐.

단점 : 서브클래스가 많아지면 코드 구조가 복잡해지고, 관리가 어려워질 수 있음.

예시

public abstract class CoffeeFactory {
    abstract Coffee createCoffee(String type);
}


public class EspressoFactory extends CoffeeFactory {
    @Override
    Coffee createCoffee(String type) {
        switch(type) {
        case "espresso":
            return new Espresso();
        case "latte":
            return new Latte();
        }
        return null;
    }
}

생성하는 객체를 별도로 둔다.
객체에 넘어오는 값에 따라서, 다른 커피를 만들어 낸다.