[JAVA] SOLID - 단일 책임 원칙 SRP(Single Responsibility Principle)

서론

최근 정보처리기사 공부를 진행하면서 오랜만에 해당 개념들을 접하게 됐는데 객체지향 언어를 개발하는 코더 입장에서 기본적인 설계 원칙도 잘 모르고 마구 개발을 한다라는 것이 얼마나 불운한 개발자로 성장할 것 인지 체감해볼 수 있었다.

 

이번 챕터에서는 SRP인 "단일 책임 원칙"에 대하여 정리해 볼 것이다.

 

---

 

객체지향 설계 5대 원칙

• SRP(Single Responsibility Principle): 단일 책임 원칙
• OCP(Open Closed Priciple): 개방 폐쇄 원칙
• LSP(Liskov Substitution Priciple): 리스코프 치환 원칙
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle): 의존 역전 원칙

 

---

 

SRP(Single Responseibility Principle) - 단일 책임 원칙이란?

정의

하나의 객체(클래스)는 반드시 하나의 동작만의 책임(역할)을 갖는다는 원칙이다.

이것이 무슨말일까?
이는 기본적인 개발 지식부터 시작된다. 보통 객체지향의 이상적인 설계 원칙들을 한줄로 요악하면 "응집도는 높이고, 결합도는 낮은게 좋다"이다. 

우리가 앞으로 배울 SOLID(SW의 모든 기초 설계에도)도 이 개념과 연관되어 있다. 우선 응집도와 결합도에 대해 가볍게 짚고 넘어가보자.

응집도는 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미한다.
결합도는 모듈간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미한다.

위의 정의를 다시 해석해보면 하나의 클래스에서 여러 동작(메서드)을 하게끔 설계하는 것은 SRP 설계에 위반된다는 행위를 말하는 것이다. 결국 이것은 하나의 클래스에서 응집도와 결합도에 관련이 있으며 해당 원칙들을 잘만 지키면 좋은 소프트웨어를 만들 수 있는것이다.

이제 위의 내용을 토대로 아래의 예제에서 살펴보자.

 

---

 

예제

SRP 원칙 위배 !

pulbic class SuperMarket {

    private String owner;   // 주인
    private String snack;   // 과자
    private int snackCount; // 과자 갯수
	
    /* 위배 */
    public void fnPay() {}           // 결제
    public void fnMoneyCharge() {}  // 카드 충전
    
}

위는 여러 슈퍼마켓들을 관리하기 위해 만든 클래스이다. 그런데 위의 예제는 SRP 원칙에 위배되었다. 왜 위배되었다고 표현할까?

 

이유는 바로 결제한다는 fn_pay()와 돈을 충전하는 fn_money_charge()를 슈퍼마켓 클래스에서 여러 가지의 행동을 의미하는 메서드(pay, charge)들을 사용했기 때문이다.

 

더 풀어서 얘기해보면,

 

기본적인 마켓에 존재하는 정보들을 담당하는 역할을 책임지는 슈퍼마켓 클래스에서 결제와 충전을 정의한다면 하나의 클래스에서 이루고자 했던 하나의 동작(행위)를 위반하게 되는 꼴이 되는 셈인 것이다.

 

 

그럼 이를 해결하기 위해서는 어떻게 하면될까? ↓

SuperMarket Class

pulbic class SuperMarket {

    private String owner;   // 주인
    private String snack;   // 과자
    private int snackCount; // 과자 갯수
	
}

Payment Class

public class Payment {
    public void fnPay() {} // 결제
    ...
}

MoneyCharge Class

public class MoneyCharge {
    public void fnMoneyCharge() {}  // 카드 충전
    ...
}

 

각 클래스들을 나누어 하나의 클래스에서 동작하는 행동들을 각자 나누어서 생성해주었다. 위와 같이 나누어서 하나의 클래스에서 하나의 책임만 부여해준다면 SRP(단일 책임 원칙)를 위배하지 않게된다.

 

이를 유념하고 클래스 설계를 하면,

다른 클래스에서 결제라는 메서드를 필요로할 때 슈퍼마켓 클래스(결제와 관련도 없는 클래스)를 들릴 일이 없어지니 각 클래스별로의 결합도가 줄어들게되고 클래스별로 본 목적에 맞게만 작성해준다면 클래스의 응집도도 올라가게 된다.

 

---

 

마치며..

해당 글은 필자가 어떻게 클래스를 작성해야 이해가 좋을까란 고민 끝에 작성한 예제인데 혹시 잘못된 내용이 있거나 더 좋은 예제로 수정할 수 있는 부분이 있다면 따끔한 피드백은 언제나 환영이니 댓글 부탁드립니다 :)