DotNet
객체지향 프로그래밍 (OOP)
OOP 설계
디자인 패턴
행동패턴
State

State

State 패턴이란?

State 패턴은 객체의 내부 상태에 따라 행동이 달라지는 방식의 디자인 패턴입니다. 상태가 변할 때 객체의 행동도 동적으로 바뀌며, 이는 상태를 객체로 캡슐화하여 처리하는 방식으로 구현됩니다. 이 패턴은 객체가 많은 상태를 가질 때, 상태마다 다른 행동을 정의하여 복잡성을 줄이는 데 유용합니다.

State 패턴 구조

D2 Diagram

  • Client → Context
    • 클라이언트는 Context의 Request() 메소드를 호출하여 동작을 요청합니다.
  • Context → State
    • Context는 현재 참조하고 있는 State 객체의 HandleRequest() 메소드를 호출하여 동작을 위임합니다.
  • State → Context
    • State 객체는 자신의 로직에 따라 Context의 상태를 다른 상태로 변경할 수 있습니다. (Change State)
  • State → ConcreteStateA / ConcreteStateB
    • 상태 전환이 필요할 경우, State는 새로운 상태 객체로 전환합니다.

State 패턴 적용

State 패턴의 필요성

도서 관리 시스템에서 책의 대여, 예약, 반납 등의 상태에 따라 처리 방식이 달라질 때가 있습니다. 이때 상태를 명시적으로 관리하지 않으면, 코드가 복잡해지고 유지보수가 어려워집니다. 상태 패턴은 상태를 객체로 분리하여 관리할 수 있게 해줍니다.

잘못된 처리

일반적으로 상태별 조건문을 통해 처리하는 방식은 코드가 복잡해질 수 있습니다. 예를 들어, 책의 상태에 따라 행동을 정의하는 경우 상태마다 조건문을 추가하는 방식은 확장성과 유지보수성에 문제가 발생합니다.

public class Book
{
    public string State { get; private set; }
    public void HandleRequest()
    {
        if (State == "available")
        {
            Console.WriteLine("Book is available for borrowing.");
        }
        else if (State == "borrowed")
        {
            Console.WriteLine("Book is currently borrowed.");
        }
        else if (State == "reserved")
        {
            Console.WriteLine("Book is reserved.");
        }
    }
}

상태 처리의 복잡성

상태마다 if-else나 switch 문을 추가해야 하므로, 상태가 늘어날수록 코드가 복잡해집니다.

단일 책임 원칙 위반

하나의 클래스가 상태와 행동을 모두 관리하므로, 단일 책임 원칙을 위반하게 됩니다.

State 패턴 적용 예시

State 패턴을 적용하면 상태를 별도의 클래스로 분리하여 관리하고, 객체의 상태가 바뀔 때 행동도 함께 바뀌도록 처리할 수 있습니다.

// State 인터페이스
public interface IBookState
{
    void Handle(Book book);
}
// 구체적인 상태 클래스: 사용 가능 상태
public class AvailableState : IBookState
{
    public void Handle(Book book)
    {
        Console.WriteLine("Book is available for borrowing.");
        book.SetState(new BorrowedState());
    }
}
// 구체적인 상태 클래스: 대여 중 상태
public class BorrowedState : IBookState
{
    public void Handle(Book book)
    {
        Console.WriteLine("Book is currently borrowed.");
    }
}
// 구체적인 상태 클래스: 예약 상태
public class ReservedState : IBookState
{
    public void Handle(Book book)
    {
        Console.WriteLine("Book is reserved.");
    }
}
// Context 클래스: Book
public class Book
{
    private IBookState _state;
    public Book()
    {
        _state = new AvailableState();
    }
    public void SetState(IBookState state)
    {
        _state = state;
    }
    public void HandleRequest()
    {
        _state.Handle(this);
    }
}
// 클라이언트 코드
public class Program
{
    public static void Main(string[] args)
    {
        Book book = new Book();
        book.HandleRequest();  // Output: Book is available for borrowing.
        book.HandleRequest();  // Output: Book is currently borrowed.
    }
}

상태 처리 로직의 분리

상태에 따른 행동을 개별 클래스로 분리하여 단일 책임 원칙을 준수합니다.

코드 확장성 증가

새로운 상태가 추가되더라도 기존 코드에 영향을 주지 않고 쉽게 확장할 수 있습니다.

State 패턴 구성 요소

State

상태 인터페이스로, 상태에 따른 행동을 정의합니다. IBookState 가 이에 해당합니다.

Concrete State

구체적인 상태 클래스들이며, 각 상태에 따른 구체적인 행동을 구현합니다. 예제에서는 AvailableState, BorrowedState, ReservedState가 이에 해당합니다.

Context

상태를 관리하는 주체로, 현재 상태에 따라 행동을 위임합니다. 상태 변경 시 Context 객체는 자신의 상태를 변경하고, 각 상태에 맞는 행동을 호출합니다. 예제에서는 Book 클래스가 이 역할을 담당합니다.

객체지향 원칙과의 관계

State Pattern과 캡슐화

State 패턴은 객체의 상태에 따라 동작이 달라지는 부분을 각 상태 클래스에 캡슐화합니다. 즉, 상태에 따른 로직을 상태 클래스 내에 숨겨놓음으로써, 상태에 따라 달라지는 행동의 세부 구현이 외부에 노출되지 않도록 합니다. Context 객체(예: Book)는 상태 변경에 대한 세부 구현을 알 필요 없이 상태 객체에 책임을 위임합니다. 이를 통해 복잡한 상태 전환 로직이 내부적으로 캡슐화되어 유지보수성이 향상됩니다. Book 클래스는 상태가 “대출 가능"인지, “대출 중"인지에 따라 서로 다른 동작을 수행합니다. 이때 상태별 로직은 각 상태 클래스에 숨겨져 있으며, Book 클래스는 그저 상태에 따른 동작을 위임하기만 합니다.

State Pattern과 다형성

State 패턴은 다형성을 적극 활용합니다. Context 객체는 상태 인터페이스(예: IBookState)에 의존하며, 구체적인 상태 클래스들이 이 인터페이스를 구현해 각기 다른 동작을 제공합니다. 이로 인해 상태가 다를 때마다 Context는 동일한 메서드를 호출하더라도 다른 결과를 얻게 됩니다. 다형성을 통해 Context는 상태별로 다른 객체를 사용할 수 있으며, 상태 전환에 따른 유연성을 제공합니다. Book 객체는 BorrowedState나 AvailableState와 같은 서로 다른 상태에서 동일한 Borrow() 메서드를 호출할 수 있지만, 상태에 따라 그 동작은 달라집니다. 이러한 다형성 덕분에 상태 전환이 유연하게 이루어집니다.

State Pattern과 단일 책임 원칙

State 패턴은 상태에 따른 행동을 각 상태 객체로 분리하여 단일 책임 원칙을 잘 준수합니다. 즉, Context 객체(예: Book)는 자신의 현재 상태를 관리하는 역할만을 맡고, 상태별로 해야 할 동작은 각 상태 클래스에서 처리합니다. 이로 인해 Context는 상태에 관련된 복잡한 로직을 처리하지 않아도 되며, 상태 전환만을 책임지는 구조로 유지됩니다. Book 클래스는 상태를 추적하고 상태를 전환하는 것에만 집중하며, 실제 “대출 중” 또는 “예약 중"과 같은 상태에서의 동작은 각 상태 클래스가 처리합니다. 이를 통해 각 클래스가 하나의 책임만 가지도록 설계됩니다.

State Pattern과 개방_폐쇄 원칙

State 패턴은 상태가 추가되거나 변경될 때 기존 코드를 수정하지 않고도 확장할 수 있습니다. 새로운 상태가 필요할 경우 기존 상태나 Context 코드를 변경하지 않고도 새로운 상태 클래스를 추가하여 확장할 수 있습니다. 이는 개방-폐쇄 원칙을 충족시키며, 상태 전환 로직이 유연하게 확장될 수 있는 구조를 제공합니다. Book 클래스에 새로운 상태인 LostState를 추가해야 한다면, 기존 코드에 영향을 주지 않고 LostState 클래스만 추가하면 됩니다. Book 클래스나 다른 상태 클래스는 수정할 필요가 없습니다.

State Pattern과 의존 역전 원칙

State 패턴에서 Context 객체는 구체적인 상태 클래스가 아닌 상태 인터페이스(예: IBookState)에 의존합니다. 이를 통해 Context는 상태 구현의 세부 사항에 의존하지 않고, 인터페이스에 의존하게 되어 의존 역전 원칙을 준수합니다. 구체적인 상태 클래스는 언제든지 변경되거나 확장될 수 있으며, Context는 이에 영향을 받지 않습니다. Book 클래스는 BorrowedState, AvailableState 같은 구체적인 상태 클래스에 의존하지 않고, IBookState라는 추상화된 인터페이스에 의존합니다. 이를 통해 상태 구현이 변경되어도 Book 클래스는 영향을 받지 않습니다.

State Pattern과 리스코프 치환 원칙

State 패턴에서 구체적인 상태 클래스들은 상태 인터페이스(예: IBookState)를 구현하고 있으며, 이 인터페이스를 통해 동작하므로 상태가 변경되더라도 Context 객체는 동일한 인터페이스를 통해 상태 객체를 호출할 수 있습니다. 이는 상태 객체가 상태 인터페이스를 준수하면서 교체 가능하다는 것을 보장합니다. Book 클래스는 IBookState 인터페이스를 통해 상태를 처리하며, 상태가 AvailableState에서 BorrowedState로 변경되어도 같은 방식으로 메서드를 호출할 수 있습니다. 각 상태 클래스는 동일한 메서드를 제공하므로, Context는 상태 교체에 대해 걱정할 필요가 없습니다.

맺음말

State 패턴은 객체의 상태에 따른 행동 변화를 관리하는 데 유용한 패턴입니다. 상태를 객체로 캡슐화하여, 상태가 추가되거나 변경될 때 유연하게 확장할 수 있으며, 상태와 행동의 관리가 명확해집니다.

심화학습

상태 전환의 로그 기록

상태가 전환될 때마다 로그를 기록하여 상태 전환을 추적할 수 있습니다.

public class LoggingState : IBookState
{
    private IBookState _wrappedState;
    public LoggingState(IBookState wrappedState)
    {
        _wrappedState = wrappedState;
    }
    public void Handle(Book book)
    {
        Console.WriteLine($"State changed to: {_wrappedState.GetType().Name}");
        _wrappedState.Handle(book);
    }
}

상태 객체의 재사용

상태 객체를 재사용하여 메모리 사용을 줄이는 방법을 고려할 수 있습니다. 모든 책이 동일한 “대여 중” 상태를 공유할 수 있다면, 상태 객체를 Singleton으로 구현하여 재사용할 수 있습니다.

public class BorrowedState : IBookState
{
    private static BorrowedState _instance = new BorrowedState();
    private BorrowedState() { }
    public static BorrowedState GetInstance()
    {
        return _instance;
    }
    public void Handle(Book book)
    {
        Console.WriteLine("Book is currently borrowed.");
    }
}

State와 Strategy

State 패턴과 전략 패턴은 유사하지만, 상태 패턴은 상태에 따라 객체의 행동이 달라지는 데 초점을 맞추고, 전략 패턴은 행동을 캡슐화하여 교체 가능하도록 하는 데 초점을 맞춥니다.

public class BookWithStrategy
{
    private IStrategy _strategy;
    public BookWithStrategy(IStrategy strategy)
    {
        _strategy = strategy;
    }
    public void ExecuteStrategy()
    {
        _strategy.Execute();
    }
}

State와 Observer

상태가 변경될 때 옵저버 패턴을 사용하여 다른 객체에 알림을 보낼 수 있습니다.

public interface IObserver
{
    void Update(IBookState state);
}
public class StateObserver : IObserver
{
    public void Update(IBookState state)
    {
        Console.WriteLine($"State has changed to {state.GetType().Name}");
    }
}

상태 전환의 조건 처리

특정 조건에 따라 상태 전환이 이루어져야 할 때, 상태 전환 조건을 명시적으로 관리할 수 있습니다.

public class ConditionalStateTransition
{
    public bool CanTransitionToBorrowed(Book book)
    {
        // 대출 가능한 상태인지 확인하는 로직
        return book.IsAvailable();
    }
}
Buy me a coffee Buy me a coffee
MementoNull Object