자 마흔 네 번째 키워드인 '단일 책임 원칙'을 알아 볼 것이다.

이번 키워드는 이전 키워드인 ISP처럼 SOLID원칙중 하나 이므로
직접 코드로 알아보았다.

단일 책임 원칙(Single Responsibility Principle, SRP)이 뭐에요?

단일 책임 원칙(Single Responsibility Principle, SRP)은 클래스는 하나의 책임만 가져야 한다는 원칙이다.
즉, 클래스는 하나의 기능이나 역할에만 집중해야 하며, 변경 이유는 오직 하나뿐이어야 한다.
이를 통해 코드는 더 이해하기 쉽고, 유지보수하기 쉬워지게 된다.

단일 책임 원칙을 지키지 않으면 클래스가 너무 많은 역할을 담당하게 되어 코드가 복잡해지고,
특정 기능의 변경이 클래스의 다른 부분에 영향을 미치기 쉽다.
이를 방지하기 위해서는 각 클래스가 하나의 역할만 수행하도록 코드를 작성해야 한다.

예시 코드 - Unity

원칙을 안 지킨 Ex

Player Class

using UnityEngine;

public class Player : MonoBehaviour
{
    private int score;

    void Update()
    {
        Move();
    }

    void Move()
    {
        float moveHorizontal = Input.GetAxis("Horizontal");
        float moveVertical = Input.GetAxis("Vertical");
        Vector3 movement = new Vector3(moveHorizontal, 0.0f, moveVertical);
        transform.Translate(movement * Time.deltaTime);
    }

    public void AddScore(int points)
    {
        score += points;
    }

    public int GetScore()
    {
        return score;
    }
}

Player 클래스는 플레이어의 이동과 점수 관리 두 가지 책임을 가지고 있는 경우이다.

원칙을 지킨 Ex

PlayerMovement Class

using UnityEngine;

public class PlayerMovement : MonoBehaviour
{
    void Update()
    {
        Move();
    }

    void Move()
    {
        float moveHorizontal = Input.GetAxis("Horizontal");
        float moveVertical = Input.GetAxis("Vertical");
        Vector3 movement = new Vector3(moveHorizontal, 0.0f, moveVertical);
        transform.Translate(movement * Time.deltaTime);
    }
}

PlayerScore Class

using UnityEngine;

public class PlayerScore : MonoBehaviour
{
    private int score;

    public void AddScore(int points)
    {
        score += points;
    }

    public int GetScore()
    {
        return score;
    }
}

위 두개의 클래스는 각각 하나만의 책임만을 담당하게 바꿔준 경우 이다.

PlayerMovement 클래스는 플레이어의 이동만을 담당하고, PlayerScore 클래스는 점수 관리만을 담당한다.
이렇게 하면 클래스가 더 이해하기 쉽고, 변경이 필요할 때 영향을 최소화할 수 있다.
예를 들어, 점수 계산 방법을 변경해야 할 때 PlayerScore 클래스만 수정하면 되므로 다른 부분에 영향을 미치지 않는다.

클래스 양이 많아지지 않을까?

클래스의 양이 많아지는 것은 단일 책임 원칙을 준수하면서 발생할 수 있는 부작용 중 하나라고 한다.
각 클래스가 하나의 책임만을 가지기 때문에 전체적으로 클래스의 수가 증가할 수 있다.
이는 코드의 구조를 더 명확하게 만들지만, 클래스의 양이 많아질 수 있다.

하지만 클래스의 수가 많다고 해서 반드시 나쁜 것은 아니라고 한다. 올바른 추상화와 모듈화를 통해 클래스를 관리함으로써 이러한 문제를 완화할 수 있다.
또한, 재사용 가능한 코드를 쉽게 식별하고 추출할 수 있게 해준다고 한다.
더 나아가, 코드의 변경이 필요할 때 해당 변경이 다른 부분에 미치는 영향을 최소화할 수 있다.
따라서 코드의 유지보수성과 확장성이 향상될 수 있다.

단일 책임 원칙은 코드의 구조를 개선하고 유연성을 높이는 데 도움이 되지만, 클래스의 수가 증가할 수 있으며, 이는 상황에 따라 관리하기 어려울 수 있다.
따라서 이러한 디자인 원칙을 적용할 때에는 코드의 복잡성과 유지보수성 사이의 균형을 잘 고려하여 설계해야한다고 한다.

결론 - 느낀 점

이게 참 클래스 수를 늘려 복잡하게 만드는게 좋은건지 아닌지 잘 모르는 딜레마 같다.
클래스를 분리하자니 다방면에서 봐야하고 합치자니 복잡도가 늘어날거 같아서
적정하게 분리하며 개발해야 할 것 같다.