단일 책임 원칙 이론 공부

dddingzong·2025년 5월 12일

이론

목록 보기
1/11
post-thumbnail

단일 책임 원칙

Single responsibility principle


우테코가 끝난 이후 가장 먼저 공부하고싶었던 내용입니다.

프리코스를 진행하던 중 설계 단계에서 가장 중요하게 여긴 부분은 객체지향에 따른 객체 설계였습니다.

이에 따라 유지보수성은 천차만별이기 때문에 많은 시간을 투자했고, 그중에서도 가장 어려웠던 것은 객체의 책임 범위 할당이었습니다.

이는 사람들마다 구현 방식이 제각각 달랐고, 방식마다 장단점이 있어서 어느 것이 정답이라고 단정 짓기는 어려웠습니다

객체지향 5원칙 중 하나인 단일 책임 원칙을 더 깊이 공부하여 설계 과정에 적용하고자 합니다.


단일 책임 원칙: 하나의 객체는 반드시 하나의 동작만의 책임을 갖는다.

  • 모듈화가 강해줄수록 다른 객체와의 의존/연관성이 줄어든다.

  • 모듈화가 약해질수록 다른 객체와의 의존/연광성이 늘어난다.

  • 책임이 많아질 수록 해당 객체의 변경에 따른 양과 범위가 매우 커진다.

  • 특정 객체의 책임 의존성 과중을 최대한 지양하기 위한 원칙이다.


예시

단일 책임 원칙 미준수

public class Coffee {

    private String name;
    private String mixture;

    public void setName(String name){
        this.name = name;
    }

    public String recipe(){

        if (name.equals("아메리카노")){
            mixture = "에스프레소" + "물";
        }

        if (name.equals("카페라떼")){
            mixture = "에스프레소" + "우유";
        }

        if (name.equals("카페모카")){
            mixture = "에스프레소" + "우유" + "초코시럽";
        }

        return mixture;
    }
}

해당 Coffee 클래스에서 recipe를 작동시키면 name의 상태에 따라 mixture의 형태가 결정됩니다. Coffee 클래스의 책임을 어디까지 할당하는지에 따라 관점이 달라지지만, 해당 서비스에서는 새로운 메뉴가 추가될 가능성 혹은 mixture가 바뀔 경우를 고려해, 단일책임원칙을 준수하는 것이 옳다고 생각합니다.

단일 책임 원칙 준수

abstract class Coffee {
    protected String mixture;

    public abstract String recipe();
}

class Americano extends Coffee{
    @Override
    public String recipe() {
        mixture = "에스프레소 + 물";
        return mixture;
    }
}

class CafeLatte extends Coffee{
    @Override
    public String recipe() {
        mixture = "에스프레소 + 우유";
        return mixture;
    }
}

class CafeMoka extends Coffee{
    @Override
    public String recipe() {
        mixture = "에스프레소 + 우유 + 초코시럽";
        return mixture;
    }
}

추상 클래스 Coffee 아래에 추상 메서드 recipe를 작성했습니다. 각각의 커피는 Coffee를 상속 받아 자신만의 recipe를 구현할 수 있습니다. 하나의 클래스에 하나의 동작만을 가지는 단일 책임 원칙을 준수하고 수 있습니다.


정리

서비스 개발 시에 Controller, Service, Repository 영역으로 나눠서 각 역할에 적합한 메서드를 작성합니다.

이론상으로는 SRP를 준수하는 것이 어렵지 않다 생각하지만, 개발 진행 시 하나의 클래스가 몇 백줄 이상 넘어갈때가 있는데, 이러한 상황에서는 클래스를 분리해야 할지 참 애매하다고 생각이 듭니다.

클래스 분리 시 클래스의 양이 과도하게 많아지게 되면 그것 또한 유지보수 입장에서 성가신 것 아닌가? 라는 의견 또한 틀리지 않다 생각합니다.

데이터베이스 정규형 단계에서도 중복된 컬럼은 존재하면 안된다는 내용이 포함되지만 성능적인 측면에서 중복을 허용할 경우도 존재합니다.

코드의 가독성과 유지보수성 사이의 적절한 균형을 맞춰야 한다고 생각합니다. 그 과정에서 개발자의 주관적인 생각이 들어갈 수 밖에 없어 SRP에 대해 깊게 고민하게 되는 것 같습니다.

profile
공부 노트 & 회고

0개의 댓글