이글을 쓰는 이유
그 동안 객체지향 설계를 위한 5대 원칙이라는 것을 알기는 했지만 항상 아리쏭하고 크게 느껴지는 바가 없었는데 최근 홀로 프로젝트를 진행함에 있어 클래스를 수정할 때마다 다른 클래스를 수정하는 내 모습을 보면서 설계의 중요성을 깨닫게 되어 근본을 잘 깨우치면 개선될 수 있다는 생각에 하얀 백지에서부터 다시 시작 하려고한다. 공부하면서 쓰는 글이니 개념이 틀릴 수 있으니깐 유의하세요!
✅ SOLID란?
- S - Single-responsiblity Principle
- O - Open-closed Principle
- L - Liskov Substitution Principle
- I - Interface Segregation Principle
- D - Dependency Inversion Principle
모두 5가지 설계 원칙이 있으면 이 설계 원칙을 지키면 객체의 변경, 확장 등에 최대한 자유롭게 할 수 있다는 원리이다. 이 원칙은 디자인 패턴을 이해하는데 매우 중요한 개념이 된다. 나도 이 원칙을 잘 깨우치지 못하고 디자인 패턴만 주구장창 공부했었는데 패턴을 이름외우랴 구조 외우랴 다 암기식으로 외우다보니 막상 코드를 작성할 때 적용하지 못했다. 근데 이 원칙을 조금 깨우치고 다시 살펴보니 디자인 패턴이란 것이 외우지 않아도 왜 적용하는지에 대한 이유를 조금은 깨우친 것 같다.
💡 S : Single-Responsibility Principle란?
☑️ 기본 개념
- Gather together the things that change for the same reasons. Separate things that change for different reasons.
- 같은 이유로 변경되는 것은 묶고, 다른 이유로 변경되는 것은 분리시켜라.
SRP의 기본원칙이다. 하나의 단위(객체)로 묶는 기준은 같은 이유로 변경되는 것이다. 이 원칙은 여러 객체들이 상호작용하는 OOP에서 매우 중요한 개념이다. 여기서 단위란 다양한 것들이 적용될 수 있다. OOP에서는 일반적으로 클래스, 함수, 메소드 단위가 될 수 있고, 데이터베이스에서는 엔티티가 될 수 있다. 조금 더 확장하면 서비스의 단위, 소프트웨어를 구성하는 컴포넌트 등 다양하게 적용될 수 있다. 자세하게 이해하기 위해 클래스 단위에서 세부적으로 다루어보자.
📢👨🏻💼 by Robert Martin aka Uncle bob
로버트 마틴(밥 삼촌)은 일반적인 프로그래밍의 클래스의 단위에서 SRP를 정의했다.
- a class should only have one reason to change, in other words like it should do only one thing.
- 클래스는 반드시 하나의 이유로 변경해야하고, 이것은 클래스가 오직 하나의 일만 담당해야한다는 것을 의미한다.
클래스라는 단위로 묶으니 조금 더 구체적으로 설명된 것 같다. 조금 더 확장해서 이해해보자. 클래스가 하나의 이유로 변경 = 하나의 일(책임)이 왜 성립되는 것일까? 지금까지 우리가 코드를 작성하면서 클래스 내부 어떤 것을 수정했을 때 해당 클래스만 변경하지 않고 다른 클래스를 변경한 적이 있지 않나? 바로 SRP가 지켜지지 않았을 가능성이 매우 크다. 클래스가 하나의 책임을 갖지 않고 있으니깐 유지보수할 때 마다 여러 클래스가 영향 받을 수 밖에 없는 것이다. 책임이 하나라면 변경하는 이유도 하나일 것이다. 좋은 코드를 구성하기 위해서는 관련 없는 다른 코드에 영향을 받지 않도록 구성해야 한다.
📌 SRP의 오해
❗️ 클래스 당 메소드 한 개?
하나의 책임을 갖는다고해서 클래스 하나 당 메소드도 하나가 있어야 될 것이라고 착각하는 경우가 있다. 잘못된 생각이다. 클래스의 추상화는 넓은 범위에서 행해져야 하며 메소드와 클래스의 책임은 같은 것이아니다. 메소드는 클래스의 추상화 정도에 따라 해당 클래스가 행해야할 행동을 정의한 것이다. 파일 클래스를 정의한다고 하자.
class file{
open();
close();
read();
write();
};open, close, read, write 총 4개의 메소드가 있으니깐 4개의 책임을 갖는 것이 아닌가요? 아니다. 파일 클래스는 파일의 대한 모든 책임이 있는 것이다. 즉, 파일을 다루는 모든 것들이 파일 클래스의 책임이다. 그리고 파일이 행할 수 있는 행동을 메소드로 정의한 것이다. 덧붙혀서 각 메소드 또한 SRP를 잘 지켜야 한다. 앞에서 말했듯이 SRP는 클래스에 국한되지 않고 여러 방면에서 최대한 지켜져야 할 원칙이다.
❗️ 책임의 세분화
이 또한 책임을 얼마나 배분하느냐의 개인적 판단이겠지만 프로젝트 규모가 작은데 엄청난 세분화를 할 필요성이 있을까? 책임을 세분화해서 클래스를 너무 많이 만드는 것은 때로는 좋지 못한 코드를 발생시킬 수 있다. 왜냐하면 책임의 추상화를 너무 디테일하게 되면 클래스 관점으로 너무 많은 클래스를 야기하기 때문이다. 클래스가 많아진다는 것은 코드의 길이가 길어지고 전반적인 프로그램의 구조를 파악하기 힘들어 진다는 것이다. 이때까지 SRP를 따르라면서 이제와서 이런 말을하면... 그럼 책임의 추상화는 어느 정도해야하나? 그건 개인의 몫이다....????????
