[OOP] SOLID - SRP(단일책임원칙)

들어가며

이번 포스팅에서는 좋은 객체지향을 설계하는 5가지 원리인 SOLID 중 S에 해당하는 SRP(단일 책임원칙)에 대해 알아보겠습니다.

 

SRP(단일 책임 원칙)이란

SRP에 대해 찾아보면 많이 볼 수 있는 정의로는 아래와 같습니다.

• 하나의 클래스는 하나의 책임만 진다.

또한 SOLID의 5가지 원리를 소개한 로버트 마틴은 책임을 "변경하려는 이유"라고 정의하고 있습니다. 즉, 하나의 클래스는 하나의 객체(=액터)에 대해서만 책임을 져야 하기 때문에, 클래스를 수정해야 하는 이유가 여러 개가 생겨선 안된다는 것입니다.

 

하지만 이렇게 글로만 보면 별로 와닿지 않기 때문에 코드를 보며 추가적으로 살펴보겠습니다.

 

상황 가정

단순하게 SRP의 이해를 돕기위한 예제입니다.

• Programming 클래스에는 개발팀에서 사용하는 writeCode() method가 존재.
• Programming 클래스에는 배포팀에서 사용하는 deploy() method가 존재.

  

    
    
    
    
  
public class Programming {
    public void writeCode(){

    }

    public void deploy(){

    }
}

• 만약 개발팀에서 개발 도중 code관련 변경사항이 생겨 writeCode() method 수정하는 상황이 발생할 수 있습니다. Programming의 액터로는 개발팀이 있습니다.
• 그리고 배포팀에서도 배포 관련 변경사항이 생겨 deploy() method를 수정해야 하는 상황이 발생할 수 있습니다. 그렇다면 배포팀 역시 Programming의 액터입니다.

위배상황

이렇게 되면 SRP원칙인 하나의 클래스는 하나의 객체에 대해서 책임을 져야 하는, 즉, "하나의 클래스는 하나의 책임만 진다"라는 SRP원칙을 위배하게 됩니다.

 

책임 분리

현재 2가지 책임을 지고 있는 Programming 클래스를 하나의 책임만 지도록 분리해보겠습니다.

• 개발팀 관련 책임을 지는 Developer클래스.
• 배포팀 관련 책임을 지는 Deployment클래스.

  

    
    
    
    
  
public class Developer {

    public void writeCode(){

    }
}

  

    
    
    
    
  
public class Deployment {

    public void deploy(){

    }
}

이제 각 클래스들은 하나의 책임만 지도록 수정이 완료됐으므로, SRP원칙을 준수하게 되었습니다.

 

SRP 장점

• 클래스를 분리하면서 코드의 응집성은 높아지고, 결합도는 낮아지게 됩니다.
• 이로 인해, 테스트 코드 작성이 용이해집니다.
• 또한, 유지보수성이 증가하게 됩니다.

 

마무리

프로그램을 객체지향 적으로 설계하게 되면 유지보수성이 좋아지기 때문에 SOLID관련 내용들을 찾아보고 적용해보고 싶었지만, 객체지향적인 설계를 잘하려면 많은 경험이 필요할 거 같다는 생각이 들었습니다.

 

추후 SRP 외 나머지 SOLID원칙들에 대해서도 포스팅해보겠습니다.

 

• SRP
• OCP
• LSP
• ISP
• DIP

 

출처

• https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%B1%85%EC%9E%84_%EC%9B%90%EC%B9%99