테스트 주도 개발 (Test-Driven Development) TDD란 Test-Driven Development의 줄임말로 '테스트 주도 개발'이라는 의미를 가지고 있습니다. 테스트 주도 개발은 반복 테스트를 이용한 소프트웨어 개발 방법론으로서 테스트 코드를 먼저 작성한 후 테스트를 통과하는 코드를 작성하는 과정을 반복하는 소프트웨어 개발 방식입니다. 애자일 방법론 중 하나인 익스트림 프로그래밍(eXtream Programming)의 Test-First 개념에 기반을 둔, 개발 주기가 짧은 개발 프로세스로 단순한 설계를 중시합니다. 애자일 소프트웨어 개발 방법론(Agile Development)과 익스트림 프로그래밍(Extreme Programming) 애자일은 신속한 반복 작업을 통해 실제 작동 가..

Abstract Factory: Family Creator Makes groups of related items. 관련된 항목들의 그룹을 만듭니다. Builder: Lego Master Builds objects step by step, keeping creation and appearance separate. 단계적으로 객체를 생성하며, 생성과 외관을 분리합니다. Prototype: Clone Maker Creates copies of fully prepared examples. 완전히 준비된 예제의 복사본을 생성합니다. Singleton: One and Only A special class with just one instance. 하나의 인스턴스만 가지는 특별한 클래스입니다. Adapter: Uni..

상태 패턴 (State Pattern) 상태 패턴을 사용하면 객체의 내부 상태가 바뀜에 따라서 객체의 행동을 바꿀 수 있다. 마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있다. 상태를 별도의 클래스로 캡슐화한 다음 현재 상태를 나타내는 객체에게 행동을 위임하므로 내부 상태가 바뀔 때 행동이 달라지게 된다는 사실을 쉽게 알 수 있습니다. 클라이언트의 관점에서 지금 상태에 따라 사용하는 객체의 행동이 완전히 달라져 마치 그 객체가 다른 클래스로부터 만들어진 객체처럼 느껴집니다. 상태패턴을 사용하지 않으면, 상태마다 모든 분기를 if문을 사용하여 분기 처리하여야 합니다 즉, 확장에 닫혀있게 되고, 상태패턴을 이용하면 확장에 비교적 열려있게 됩니다. 상태 패턴의 구성은 다음과 같습니다. Context..

컴포지트 패턴컴포지트 패턴(Composite Pattern)으로 객체를 트리구조로 구성해서 부분-전체 계층을 구현한다. 컴포지트 패턴을 사용하면 클라이언트에서 개별 객체와 복합 객체를 똑같은 방법으로 다룰 수 있습니다. 부분-전체 계층 구조(part-whole hierarchy)란, 부분들이 계층을 이루고 있지만 모든 부분을 묶어서 전체로 다룰 수 있는 구조를 뜻합니다. (트리에서 부모 노드와 자식 노드들의 가장 작은 부분들이 합쳐져서 트리의 전체 구조가 된다는 것을 생각하면 이해하기에 쉽다.) 트리와 구분되는 점은 트리에선 모든 Leaf 노드가 부모 노드가 될 수 있지만, 컴포지트 패턴에서는 Composite 객체만 Leaf 객체들을 관리하는 부모 노드가 될 수 있다는 것입니다. 컴포지트 패턴의 구성에..

템플릿 메소드 패턴 템플릿 메소드 패턴은 알고리즘의 골격을 정의합니다. 템플릿 메소드를 사용하면 알고리즘의 일부 단계를 서브 클래스에서 구현할 수 있으며, 알고리즘의 구조는 그대로 유지하면서 알고리즘의 특정 단계를 서브 클래스에서 재정의할 수도 있습니다. 쉽게 말해 템플릿 메소드 패턴은 알고리즘의 템플릿을 만들고, 이 템플릿은 일련의 단계로 알고리즘을 정의한 메소드입니다. 위 UML Class Diagram 에서, AbstractClass는 templateMethod() 작업을 정의합니다. 이 메서드는 행동의 뼈대를 구현하고, primitive1()과 primitive2() 메시지를 자기 자신에게 보냅니다. 이 메시지들은 SubClass1에서 구현되어 있기 때문에 이 서브클래스에서 해당 알고리즘의 일부를..

퍼사드 패턴(Facade Pattern) 퍼사드 패턴은 서브 시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어줍니다. 또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편하게 쓸 수 있습니다. 위의 UML Class Diagram에서, Client 클래스는 Subsystem 클래스들에 직접적으로 접근하지 않습니다. 대신, Client는 간단한 인터페이스를 구현하고 Subsystem 클래스들 (Class1, Class2 및 Class3)을 통해 작동하는 Facade 클래스를 통해 작업합니다. Client는 단순한 Facade 인터페이스에만 의존하며 복잡한 서브시스템에 대해 독립적입니다. 여기서 중요한 포인트는 Facade 디자인 패턴을 사용하여 복잡한 서브시스템을 단순한 인터페이스로 감싸고, 클라..

어댑터 패턴(Adapter Pattern) 어댑터 패턴은 특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환합니다. 이로써 인터페이스가 호환되지 않아 같이 쓸 수 없었던 클래스를 사용할 수 있게됩니다. 위의 UML Class Diagram에서, Target 인터페이스를 필요로 하는 Client 클래스는 Adaptee 클래스의 인터페이스가 Target 인터페이스와 일치하지 않기 때문에 Adaptee 클래스를 직접 재사용할 수 없습니다. 대신 클라이언트는 Adapter 클래스를 통해 작업하며, 이 Adapter 클래스는 Adaptee를 사용하여 Target 인터페이스를 구현합니다. 객체 어댑터 방식은 런타임에 어댑티 객체에 위임함으로써(Adaptee.specificOperation()) ..

커맨드 패턴(Command Pattern) 커맨드 패턴을 사용하면 요청 내역을 객체로 캡슐화해서 객체를 서로 다른 요청 내역에 따라 매개변수화할 수 있습니다. 위의 UML Class Diagram 에서 Invoker 클래스는 직접 요청을 구현하지 않습니다. 대신 Invoker는 요청을 수행하기 위해 Command 인터페이스를 참조합니다(command.execute()). 이로써 Invoker는 요청이 어떻게 수행되는지와는 독립적이게 됩니다. Command1 클래스는 Command 인터페이스를 구현하여 Receiver1 객체에 대한 작업을 수행합니다 (receiver1.action1()). UML Sequence Diagram은 런타임 상호 작용을 보여줍니다. Invoker 객체가 Command1 객체에서..

싱글톤 패턴 (Singleton Pattern) Singleton 패턴은 소프트웨어 디자인 패턴 중 하나로, 클래스의 인스턴스화를 단일 인스턴스로 제한하는 소프트웨어 디자인 패턴입니다. "Gang of Four" 디자인 패턴 중 하나로, 객체 지향 소프트웨어에서 반복적으로 발생하는 문제를 해결하는 방법을 설명합니다. 이 패턴은 시스템 전체에 걸쳐 작업을 조정해야 할 때 유용합니다. Singleton 패턴을 사용하면 객체가 다음을 수행할 수 있습니다. 1. 하나의 인스턴스만 가지도록 보장 2. 해당 인스턴스에 쉽게 액세스 3. 인스턴스의 생성을 제어 (예: 클래스의 생성자를 숨김) 이 용어는 수학적인 개념인 'singleton'에서 유래되었습니다. 싱글톤은 종종 global 변수와 비교하여 선호되는데, 그..

Factory Pattern 새로운 객체가 필요한 곳마다 new를 사용하여 구상 클래스를 코딩하면, 나중에 코드를 수정해야 할 가능성이 커지고 유연성이 떨어집니다. 디자인 패턴을 적용하지 않은 코드 예시를 보겠습니다. public class DependentPizzaStore { public Pizza createPizza(String style, String type) { Pizza pizza = null; if (style.equals("NY")) { if (type.equals("cheese")) { pizza = new NYStyleCheesePizza(); } else if (type.equals("veggie")) { pizza = new NYStyleVeggiePizza(); } else i..