[ SOLID ] 단일 책임 원칙 : 내가 왜 PlayerManager를 나눈 이유

·개발/OOP

요즘 만들고 있던 캐릭터 시스템이 점점 코드 덩어리가 되어가고 있었다.

PlayerManager라는 클래스 하나에 만들고 있던 캐릭터 시스템이 점점 코드 덩어리가 되어가고 있었다.

PlayerManager라는 클래스 하나에 스탯, UI등 다 몰아넣었더니...

수정 할 때마다 코드가 꼬이며 내가 짠 코드인데도 뭐가 뭔지 모르게 되어가고 있었다.


그래서 내가 짠 코드가 잘못된게 아닐까 싶어서 찾아보다가

SRP(Single Responsibility Principle) 이라는 단일 책임 원칙이라는 것을 알게 됐다.

단일 책임 원칙이라는 것은 하나의 클래스는 하나의 책임만 가져야 한다는 것이다.

예를 들면 스탯, UI등을 하나의 클래스에 모두 때려 박는 것이 아니라 각 클래스를 만들어서 다뤄야만 하는 것이다.


이건 내가 바꾸기 전에 코드이다.

public class PlayerManager : MonoBehaviour
{
    public float health;
    public float moveSpeed;
    
    public TMP_Text healthText;
    
    private void Update()
    {
    	Move();
        UpdateUI();
    }
    
    private void Move() { /* 이동 관련 로직 */ }
    private void UpdateUI { /* UI 업데이트 로직 */ }
}

SRP 관점에서 보면, 이 클래스는 체력, 이동, UI를 모두 떠맡는 샘이다.

그렇기 때문에 SRP를 잘 지키지 않은 코드가 된다.

ㅤ


ㅤ


이걸 SRP를 지키며 내가 바꾼 방식을 보자

내가 한 방식은 PlayerMovement, PlayerHealthManager, PlayerUI라는 클래스로 나눠 PlayerManager로 작동시켰다.

// PlayerMovement.cs
public class PlayerMovement : MonoBehaviour
{
    public float moveSpeed;
    
    public void Move() { /* 이동 관련 로직 */ }
}

// PlayerHealthManager.cs
public class PlayerHealthManager : MonoBehaviour
{
    public float maxHealth;
    public float currentHealth;
}

// PlayerUI.cs
public class PlayerUI : MonoBehaviour
{    
    public TMP_Text healthText;
    
    private void UpdateUI { /* UI 업데이트 로직 */ }
}

// PlayerManager.cs
public class PlayerManager : MonoBehaviour
{
    public PlayerMovement movement;
    public PlayerHealthManager healthManager;
    public PlayerUI ui;
    
    private void Awake()
    {
        movement = GetComponent<PlayerMovement>();
        healthManager = GetComponent<PlayerHealthManager>();
        ui = GetComponent<PlayerUI>();
    }
    
    private void Update()
    {
    	movement.Move();
        ui.UpdateUI();
    }
}

ㅤ


ㅤ


SRP를 적용시키고 나서 처음에는 클래스 수가 늘어나서 귀찮았는데,

코드가 늘어날 때마다 각 클래스에서 관련된 코드만 수정하면 되고, 다른 클래스는 손댈 필요가 없어져서

Very Very 편해졌다. 

SRP의 진가를 내가 깨달은 것이다!!! SRP 그저 신...

ㅤ


ㅤ


SRP는 말은 쉽지 이걸 적용할려하면 머리가 복잡해진다...

하지만 장기적으로 보면 유지보수에 드는 비용을 진짜 줄여준다는 것을 알았다.

앞으로는 처음부터 클래스에 책임을 물으며 개발해 나가야 겠다.

 

'개발/OOP' 카테고리의 다른 글
  • [ SOLID ] 인터페이스 분리 원칙 : 한 인터페이스에 집착하지 말자
  • [ SOLID ] 리스코프 치환 원칙 : 제대로 이해하려다 머리 터질 뻔함
  • [ SOLID ] 개방-폐쇄 원칙 : 몬스터 공격 방식을 바꾸며 배운 것
  • 객체 지향 프로그래밍(Object-Oriented Programming)
김노라
김노라
  • 김노라
    노라의 메모장
    김노라
  • 전체
    오늘
    어제
    • 분류 전체보기 (12)
      • 잡담 (1)
        • 경험담 (1)
      • 개발 (11)
        • OOP (6)
        • C# (0)
        • C++ (1)
        • 유니티 (1)
        • ShootingTale (3)
        • 개발일지 (0)
      • 코딩테스트 (0)
        • 백준 (0)
        • 프로그래머스 (0)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    코딩테스트 #프로그래머스
    기본자료형
    카드개발
    유니티
    형변환
    기획
    개발일지
    백준 #코딩테스트
    C# 기초
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
김노라
[ SOLID ] 단일 책임 원칙 : 내가 왜 PlayerManager를 나눈 이유
상단으로

티스토리툴바