SRP

안녕하세요 Jercy입니다. 오늘은 Swift에서의 SRP(Single Responsibility Principle, 단일책임원칙)에 대해 알아보도록 하겠습니다.

SRP란 SOLID 원칙 중 하나로, 객체는 단 하나의 책임만 가져야 한다는 원칙입니다. 여기서 책임이란 변경을 위한 이유를 뜻하는데요. 클래스를 변경하는 이유는 오직 하나여야 한다는 의미로 해석할 수 있습니다.

예를 들어, 은행 애플리케이션을 개발한다고 가정해봅시다. 사용자 정보 관리, 계좌 관리, 이체, 대출 등 다양한 기능이 필요할 것입니다. SRP를 적용하지 않는다면 이 모든 기능을 하나의 클래스에 구현하려 할지도 모릅니다. 하지만 그렇게 되면 해당 클래스는 지나치게 많은 책임을 갖게 됩니다.

class BankService {
    func createUser() { ... }
    func getUser() { ... }
    func createAccount() { ... }
    func getAccount() { ... }
    func transfer() { ... }
    func loan() { ... }
}
Swift
복사

만약 사용자 정보 관리 로직에 변경이 필요하다면 BankService 클래스를 수정해야겠죠? 또 계좌 관련 기능을 변경할 때도, 이체나 대출 관련 기능이 변경될 때도 매번 이 클래스를 수정해야 합니다.

변경해야 할 이유가 많다는 것은 그만큼 클래스가 여러 책임을 갖고 있다는 뜻입니다. 이는 SRP에 위배되는 것이죠.

대신 아래와 같이 각 책임별로 나누어 클래스를 만들면 어떨까요?

class UserService {
    func createUser() { ... }
    func getUser() { ... }
}

class AccountService {
    func createAccount() { ... }
    func getAccount() { ... }
}

class TransferService {
    func transfer() { ... }
}

class LoanService {
    func loan() { ... }
}
Swift
복사

이렇게 한다면 특정 기능을 변경해야 할 때 오직 해당 클래스만 수정하면 됩니다. 사용자 관련 기능을 변경할 때는 UserService만, 계좌 관련 기능 변경시에는 AccountService만 수정하는 식이죠.

서비스 클래스 외에도 ViewController를 예로 들 수 있습니다. 하나의 ViewController가 데이터 가져오기, 뷰 그리기, 이벤트 처리 등 많은 일을 하고 있다면 SRP에 위배되는 겁니다. 그 대신 다음과 같이 책임별로 분리해 줄 수 있죠.

class MyViewController: UIViewController {
    let dataService = DataService()
    let userService = UserService()

    override func viewDidLoad() {
        super.viewDidLoad()
        updateView()
    }

    private func updateView() {
        let data = dataService.getData()
        let user = userService.getUser()
        // update UI using data and user
    }

    @IBAction func handleButtonTap() {
        // handle tap event
    }
}

class DataService {
    func getData() -> Data { ... }
}

class UserService {
    func getUser() -> User { ... }
}
Swift
복사

이렇게 데이터 가져오기는 DataService가, 유저 정보 가져오기는 UserService가 담당하게 하면 ViewController가 각각의 책임으로부터 자유로워 집니다.

SRP를 따르면 클래스마다 변경해야 할 이유가 하나로 명확해지므로 코드의 가독성이 좋아지고 유지보수도 쉬워집니다. 하지만 너무 작은 단위로 나누다 보면 오히려 복잡도가 증가할 수 있으니 적절한 수준을 유지하는 것이 중요합니다.

이상으로 단일책임원칙에 대해 알아보았습니다. 예시 코드들을 보면 어떤 책임을 기준으로 클래스를 분리해야 할지 감이 오실 거예요. 처음에는 어렵겠지만 연습을 통해 점차 SRP를 体得해 나가시길 바랍니다.

생각해볼 점:

•

SOLID에서 SRP가 제일 먼저 나오는 이유는 무엇일까요?

•

우리가 작성한 코드들을 다시 보면 SRP 관점에서 어떤 문제점이 보이나요?

답변 예시:

•

SRP는 SOLID의 기본이 되는 원칙이기 때문입니다. 한 클래스가 여러 책임을 갖는다면 다른 원칙을 지키기도 어려워지므로 가장 먼저 고려해야 할 원칙이라 할 수 있습니다.

•

한 클래스에 여러 메서드가 있고 각 메서드가 서로 다른 일을 하고 있다면 SRP 위반일 가능성이 높습니다. 메서드를 기준으로 책임을 나누어 별도의 클래스로 분리하는 것이 좋겠네요. 그러면 각 클래스는 명확한 역할과 책임을 갖게 될 것입니다.