[Readable Code] SRP : Single Responsibility Principle - 단일 책임 원칙

SOLID

 

이 글은 인프런 '박우빈'님의 Readable Code: 읽기 좋은 코드를 작성하는 사고법이라는 인프런 강의를 공부하며 정리한 내용이다. 가독성이 좋지 않게 짜여진 지뢰 찾기 게임 코드를 가독성 좋은 코드로 리팩토링 하며 읽기 좋은 코드를 작성하는 방법에 대해 학습한다.

Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의 | 박우빈 - 인프런

 

 

---

 

이번 강의는 SOLID 원칙에서 S에 해당하는 단일 책임 원칙(Single Responsibility Principle)에 대해 코드를 리팩토링하며 학습하는 것이 목표이다. 

 

SRP : 단일 책임 원칙

단일 책임 원칙(Single Responsibility Principle, SRP)은 소프트웨어 설계 원칙 중 하나로, 클래스나 모듈이 오직 하나의 책임만을 가져야 한다는 원칙이다. 여기서 "책임"이란 변경의 이유라고도 볼 수 있다. 즉, 하나의 클래스나 모듈이 변경되어야 하는 이유는 하나뿐이어야 한다는 뜻이다.

• 하나의 클래스는 단 하나의 변경 이유만 가져야 한다. 
• 관심사의 분리로 코드가 명확해진다.
• 높은 응집도, 낮은 결합도를 유지할 수 있게 된다.

 

1. 게임 시작점과 게임 자체의 역할을 분리

GameApplication 클래스를 정의하여, '게임 시작' 부분만 담당하게 한다. 이 클래스는 추후에 '지뢰 찾기' 게임이 아닌 다른 게임도 실행할 수 있도록 하여, 유연하게 확장성이 높아졌다고 볼 수 있겠다.

 

 

2. 입/출력 클래스 분리

게임의 핵심 로직과 사용자에게 입력 받거나, 출력해서 보여주는 부분을 분리할 수 있겠다. io 패키지를 만들어서 콘솔 입출력 클래스를 정의하여 분리하였다.

 

이제 사용자가 입력하는 부분, 사용자에게 출력하는 부분들은 모두 이 클래스에 정의되어 관리될 것이다.

 

3. Board(지뢰판)를 클래스로 따로 분리

지뢰판은 원래 Minesweeper 클래스에 Cell[][] 이중배열로 선언되어 사용되었었다. 이 지뢰판을 GameBoard 클래스로 분리하여, 책임을 분리해 보도록 한다. 이제 지뢰판에 대한 모든 조작은 이 GameBoard 클래스가 담당하게 될 것이다. 

 

 

 

책임을 분리하는 리팩토링을 한 후

• 게임 시작점을 게임 자체와 분리하는 부분
• 입/출력을 분리하는 부분
• 지뢰판(board) 자체를 클래스로 분리 하는 부분

SRP 단일 책임 원칙을 지키려 리팩토링 하였다.

 

처음에는 클래스가 나눠지는 것이 번거롭게 느껴졌지만, 각 클래스가 명확한 역할을 가짐으로써 코드가 더욱 읽기 쉬워지고, 유지보수나 확장 시 발생할 수 있는 오류도 줄일 수 있다고 생각한다. 유지보수에 강한 구조를 가진 코드를 작성하는 개발자가 되기 위해 끊임없이 연습해야 할 것이다.

 

사실 '책임'의 분리라는 것 자체가, 개개인마다 생각하는 부분이 다를 것 같다. 개인적으로는 어느 부분을 분리해야 할지 모호한 부분이 있었다. 끊임없이 자기 자신에게 되물어보며 생각하는 습관을 들이는 것이 중요할 것 같다.

 

Github : https://github.com/yoonion/my-readable-code

GitHub - yoonion/my-readable-code: [Readable Code: 읽기 좋은 코드를 작성하는 사고법]