[유니티] 더 나은 코드를 위해, 코드간의 결합도 낮추기

진행중인 한 프로젝트의 개발 규모를 확장하면서, 이전 코드구조를 리팩토링하기로 했다.

도중에 전역 인스턴스를 너무 과하게 사용하고 있는것 같다는 생각이 들었다.

분명 올바른 사용을 하고 있는 코드들도 있을것이다. 반드시 다른 코드를 참조해야 하는 로직들도 분명 존재하기 때문이다.

하지만 분명 불필요한 참조도 있었고, 이를 줄이기 위해 참조 부분 위주로 살펴보며 고찰을 해보았다.

 

다른 코드 인스턴스를 직접 가져오는 것 자체는 문제가 되지 않는다.

 

정말 고려해야 하는것은 한 코드가 다른 코드에 '얼마나 많은 영향'을 미치는가이다.

간단한 예시를 통해 살펴보자.

 

# CASE 1

public class A : MonoBehaviour
{
    public void DoWork() 
}

public class B : MonoBehaviour
{
    [SerializeField] private A a;

    public void Run()
    {
        a.DoWork(); // 클래스 A의 DoWork() 호출
    }
}

표면적으로 보면:

• B는 A의 인스턴스를 직접 들고 있고
• 메서드를 직접 호출한다.

이런식의 구조라면 class B가 얼마든지 다른 클래스 인스턴스를 지니고 있어도 상관없다.

왜냐하면 class A의 DoWork() 메서드의 내부로직을 얼마든지 갈아엎어도, classB는 전혀 수정하지 않아도 되기 때문이다.

 

중요하게 생각해봐야하는것은 바로 'A를 수정했을 때 B를 얼마나 손대야 하는가?' 이다.

 

# CASE 2

public class Inventory : MonoBehaviour
{
    public List<Item> items = new List<Item>(); // 인벤토리 리스트
}

public class InventoryUI : MonoBehaviour
{
    [SerializeField] private Inventory inventory;

    public void updateInventory()
    {
        // 내부 리스트에 직접 손대기
        inventory.items[0] = someOtherItem;
        inventory.items.Add(newItem);
        inventory.items.Sort((a, b) => a.Id.CompareTo(b.Id));
    }
}

여기서 문제는:

• InventoryUI가 Inventory의 items 리스트에 완전히 의존하고 있다.
• Inventory 쪽에서
  • List<Item> → Dictionary<int, Item>로 바꾸거나
  • 정렬 로직을 다른 방식으로 바꾸고 싶어지면..

▶️  Inventory와 InventoryUI 코드 둘 다 갈아엎어야한다.

 

즉, UI가 Inventory의 내부 구조를 수정하는 형태라 결합도가 높은 안좋은 코드이다.

 

# CASE 2 리팩토링

그러면 CASE 2의 코드를 어떤식으로 수정해야할까?

InventoryUI는 절대로 Inventory의 내부 데이터를 수정하게끔 하면 안된다.

 

public class Inventory : MonoBehaviour
{
    private List<Item> items = new List<Item>();

    public void AddItem(Item item) // 아이템 추가
    {
        items.Add(item);
    }

    public void ReplaceItem(int index, Item item) // 아이템 대체
    {
        items[index] = item;
    }

    public void SortById() // 아이템 정렬
    {
        items.Sort((a, b) => a.Id.CompareTo(b.Id));
    }

    public List<Item> GetItems() // 아이템 반환
    {
        return items;
    }
}

 

먼저 리팩터링된 Inventory 코드를 보자.
이전과 달리, 내부 데이터를 직접 만지는 대신 작은 기능 단위의 메서드들로 쪼개 놓았다.

이제 다른 코드에서는 이 메서드들만 호출하거나, 필요하다면 이벤트를 통해 이 메서드들이 호출되도록 만들면 된다.
그렇게 하면 외부 코드는 Inventory가 내부에서 리스트를 어떻게 관리하는지 전혀 알 필요 없이,
“무엇을 해 달라”는 요청만 보내는 수준으로 의존성이 줄어든다.

 

public class InventoryUI : MonoBehaviour
{
    [SerializeField] private Inventory inventory;

    public void UpdateInventory()
    {	
    	// 내부 리스트 직접 컨트롤 x
        inventory.ReplaceItem(0, someOtherItem);
        inventory.AddItem(newItem);
        inventory.SortById();

        var items = inventory.GetItems();
        foreach (var item in items)
        {
            // 슬롯 UI 갱신
        }
    }
}

 

이런 식으로 UI 클래스는 이제 Inventory의 내부 구현을 직접 건드리지 않고, Inventory가 공개한 메서드만 통해 상호작용하게 된다. 그래서 두 클래스는 서로에 대해 아는 정보가 줄어들었고, 더 얕은 결합도로 연결되었다고 볼 수 있다.

 

 

---

 

사실 아주 기초적이고 당연한 이야기이긴 한데, 그만큼 중요한 개념이라고 생각한다.

협업을 하다 보면 시간에 쫓겨서, 일단 돌아가게 만드는 로직 위주의 절차지향 코드부터 짜게 되는 경우가 많다.
나도 이번에 리팩토링을 하면서, 예전에 내가 써둔 강한 결합도의 코드들을 보며 이 개념을 다시 떠올리게 됐다..^^