SOLID : 단일 책임 원칙

리팩토링과 SOLID 원칙은 서로 간에 연관이 아주 깊다.

둘 다 모두 유지보수가 쉽고, 이해하기 쉬운 코드를 짜기 만들기 위함이라는 목적이 있기 때문이다.

 

단일 책임 원칙 (SRP: Single Responsibility Principle)

보통 '클래스, 메서드는 하나의 책임만을 가져야 한다'라고 알려진 원칙이다.

책임이라고 하니 뜻이 되게 애매한데, 그냥 '각각의 클래스, 메서드는 한 가지 짓만 해야 한다'라고 하면 이해하기 쉬울 것이다.

 

예를 들어, 유저의 계정을 관리하는 AccountManager라는 클래스가 있는데,

계정 관련 기능을 다 AccountManager에 구현했다고 가정해보자.

public class AccountManager : IAccountManager
{
    public void LogIn()
    {
    	...
    }
	
    public void LogOut()
    {
    	...
    }
    
    public AchievementData GetAchievementData()
    {
    	...
    }
    
    public void UpdateAchievementData()
    {
    	...
    }
    
    public StatisticsData GetStatisticsData()
    {
    	...
    }
    
    public void UpdateStatisticsData()
    {
    	...
    }
    
    ...
}

 

예시 코드를 보면 단순해 보이지만, 만약 내부 함수와 실제 구현 코드를 포함하면 더 많은 코드를 포함하고 있을 것이다.

만약 이 클래스가 다른 사람이 구현한 코드이고, 중간에 자신이 참여해서 업적 관련 기능을 수정한다고 해보자.

분명 다른 구현된 기능들이 뒤섞여 있어서, 업적 관련 코드를 파악하기도 어렵고, 제대로 디버깅하기도 힘들 것이다.

 

이 문제를 해결 해기 위해서 코딩을 할 때, 또는 위와 같은 코드를 리팩토링 할 때는, 단일 책임 원칙을 따를 필요가 있다.

 

원칙을 지키는 법은 간단하다, 앞서 말한대로 클래스는 한 가지 짓만 해야 하므로 기능 별로 분리하면 된다.

여기서는 로그인(LogInService), 업적(AchievementService), 기록(StatisticsService) 클래스로 분리할 수 있을 것이다.

public class LogInService : ILogInService
{
    private IAccountDataService accountDataService;

    public LogInService(IAccountDataService accountDataService)
    {
    	
    }

    public void LogIn()
    {
    	...
    }
    
    public void LogOut()
    {
    	...
    }
}

public class AchievementService : IAchievementService
{
    public AchievementData GetData()
    {
    	...
    }
    
    public void UpdateAchievementData()
    {
    	...
    }
}

public class StatisticsService : IStatisticsService
{
    public StatisticsData GetStatisticsData()
    {
    	...
    }
    
    public void UpdateStatisticsData()
    {
    	...
    }
}

이렇게 하면 나중에 기능 추가, 수정도 쉽고, 관련 작업자들도 기존 기능을 파악하기 쉬울 것이다.