✍️Today I Learned

📅 2025-12-09

• 인터페이스 래퍼 + 팩토리 패턴으로 카테고리별 스탯 표시 로직 분리

---

인터페이스 래퍼 + 팩토리 패턴으로 카테고리별 스탯 표시 로직 분리

📌 문제 상황

빌딩/아이템 스탯 표시 시스템에서:

• FItemData와 FBuildingData는 완전히 다른 구조체 → 함수를 따로 만들어야 함
• 각 카테고리(TOOL, WEAPON, ARMOR, CONSUMABLE, WALL, FLOOR...)마다 표시할 스탯이 다름
• Switch-case로 처리하니 코드가 길어지고, 새 카테고리 추가 시 기존 코드 수정 필요

// Before: 너무 길고 유지보수 어려움
void UpdateCraftingItemStatView(const FItemData& ItemData)
{
    switch (ItemData.Category)
    {
    case EItemCategory::TOOL:
        // 채취 유형, 공격력, 내구도... 50줄
        break;
    case EItemCategory::WEAPON:
        // 공격력, 사거리, 내구도... 50줄
        break;
    // ...
    }
}

void UpdateBuildingItemStatView(const FBuildingData& BuildingData)
{
    switch (BuildingData.Type) { /* ... */ }
}

🎯 해결 방법

인터페이스 래퍼 + 팩토리 패턴 조합으로 해결

1. 인터페이스 래퍼로 데이터 통합

// IDisplayDataProvider (순수 C++ 인터페이스)
class IDisplayDataProvider
{
public:
    virtual FGameplayTag GetCategoryTag() const = 0;
    virtual float GetStatValue(const FGameplayTag& StatTag) const = 0;
    // ...
};

// 각 데이터 타입을 래핑
class FItemDataProvider : public IDisplayDataProvider { /* ... */ };
class FBuildingDataProvider : public IDisplayDataProvider { /* ... */ };

2. 팩토리 패턴으로 카테고리별 Viewer 생성

// 추상 클래스
UCLASS(Abstract)
class UStatViewer : public UObject
{
    virtual void ShowStats(
        UListView* ListView,
        const IDisplayDataProvider& DataProvider,
        UGameplayTagDisplaySubsystem* DisplaySystem) PURE_VIRTUAL();
};

// 카테고리별 구현
UCLASS() class UToolStatViewer : public UStatViewer { /* 도구 스탯 표시 */ };
UCLASS() class UWeaponStatViewer : public UStatViewer { /* 무기 스탯 표시 */ };
UCLASS() class UWallStatViewer : public UStatViewer { /* 벽 스탯 표시 */ };

// 팩토리가 적절한 Viewer 반환
UCLASS()
class UStatViewerFactory : public UObject
{
    UStatViewer* GetViewer(const FGameplayTag& CategoryTag)
    {
        if (CategoryTag == TAG_Category_Tool)
            return CachedToolViewer;
        // ...
    }
};

3. 위젯에서 통합 사용

// After: 5줄로 축약, 모든 타입 통합!
void UItemInfo::UpdateStatViewInternal(const IDisplayDataProvider& DataProvider)
{
    FGameplayTag CategoryTag = DataProvider.GetCategoryTag();
    UStatViewer* Viewer = ViewerFactory->GetViewer(CategoryTag);
    Viewer->ShowStats(ItemStatView, DataProvider, TagDisplaySubsystem);
}

void UpdateCraftingItemStatView(const FItemData& ItemData)
{
    FItemDataProvider Provider(ItemData);
    UpdateStatViewInternal(Provider);
}

void UpdateBuildingItemStatView(const FBuildingData& BuildingData)
{
    FBuildingDataProvider Provider(BuildingData);
    UpdateStatViewInternal(Provider);
}

🔑 핵심 포인트

1. 인터페이스 래퍼 (IDisplayDataProvider)

   • 서로 다른 구조체를 통일된 방식으로 접근
   • 순수 C++ 인터페이스로 가볍게 구현
   • 스택에 생성 가능 (임시 래퍼)

2. 팩토리 패턴 (UStatViewerFactory)

   • 카테고리 태그로 적절한 Viewer 반환
   • Viewer들을 캐싱해서 재사용 (성능)
   • 새 카테고리 추가 시 Factory에 한 줄만 추가

3. Strategy 패턴 (UStatViewer)

   • 각 카테고리별 스탯 표시를 독립 클래스로
   • 각 Viewer가 자기 카테고리 스탯만 담당
   • OCP 준수 (Open-Closed Principle)

📂 폴더 구조

UI/StatDisplay/
├── DisplayDataProvider.h           # 인터페이스
├── Providers/
│   ├── ItemDataProvider.h/cpp      # 아이템 래퍼
│   └── BuildingDataProvider.h/cpp  # 빌딩 래퍼
├── Viewers/
│   ├── StatViewer.h/cpp            # 추상 클래스
│   ├── Items/
│   │   ├── ToolStatViewer.h/cpp
│   │   ├── WeaponStatViewer.h/cpp
│   │   └── ...
│   └── Buildings/
│       ├── CraftingStatViewer.h/cpp
│       └── ...
└── StatViewerFactory.h/cpp         # 팩토리

✅ 장점

• 서로 다른 데이터 타입을 하나의 함수로 처리
• 각 카테고리 로직이 독립적 (유지보수 쉬움)
• 새 카테고리 추가 시 기존 코드 수정 불필요
• 각 Viewer별 단위 테스트 가능

---

💡 느낀 점 (What I Felt)

처음엔 switch-case가 간단해 보였는데 카테고리가 늘어나면서 함수가 너무 길어졌다. 인터페이스 래퍼로 데이터를 추상화하고, 팩토리 패턴으로 각 로직을 분리하니까 코드가 훨씬 깔끔해졌다. 특히 FItemData와 FBuildingData를 전혀 건드리지 않고 Provider로만 감싸서 해결할 수 있는게 신기했다.

팩토리 패턴이 처음엔 오버엔지니어링 같았는데, 이후 빌딩의 특정 카테고리의 내용만 수정할 때 훨씬 간단해 편했다. 그리고 각 Viewer 클래스가 30~50줄 정도로 짧아서 읽기도 편하고 테스트하기도 좋았다.

UCLASS로 구현한 Viewer 클래스들이 순수 C++ 인터페이스(IDisplayDataProvider)를 파라미터로 받아서 쓸 수 있다는 게 새로웠다. UObject 계열과 순수 C++을 조합해서 쓸 수 있다는 걸 몰랐는데, 스택에 생성한 Provider를 UObject인 Viewer가 참조로 받아서 사용하는 구조가 깔끔했다. 언리얼에서도 순수 C++과 디자인 패턴을 실전에 제대로 적용해본 경험이었다.

---