SOLID 원칙을 이해하기 쉽게 알아보자

백엔드 개발자라면 누구나 들어봤을 만한 개념, SOLID. 기술 면접을 위해 달달 외워보지만 개념도 어렵고 심지어는 긴 영어단어로 이루어져 있어서 이름 외우기도 힘듭니다. 저도 실제로 면접 질문으로 나온 적이 있었는데, 그때 이렇게 대답했습니다.

 

"S가 단일 책임 이고, O가 아... L이 리스코프 치환 어쩌고였는데 생각이 나지 않네요...."

 

지금 생각하면 아찔한 답변이네요. 자주 나오는 빈출 질문이어서 외우기는 했는데 실제로 답변을 하려니까 머리가 새하얘 졌었습니다. 물론 이 질문 하나로 당락이 결정되지는 않겠지만 외우기 힘든 개념을 술술 말한다면 좋은 인상을 남길 수는 있겠죠. 같은 실수를 반복하지 않기 위해, 그리고 여러분은 저와 같은 실수를 범하지 않게 하기 위해 이번에는 SOLID 원칙에 대해 알아보겠습니다.

S : Single Responsibility (단일 책임)

말 그대로 하나의 책임만을 지녀야 한다는 법칙입니다. 실생활에서도 한 사람에게 프론트, 백엔드, devops까지 모두 맡긴다면 머지않아 사직서를 낼 것입니다.(해내시는 분들도 더러 있으시긴 하시더라고요.)  

 

물론 한 클래스에 모든 책임을 때려 박으면 초반에는 편리할 수도 있습니다. 그러나 그런 스파게티 코드가 될 경우, 유지보수가 비교적 힘들어지겠죠.

 

퇴사해야겠다

그래도 다닐 수는 있겠네

O : Open/Closed (개방-폐쇄)

객체의 확장에는 열려있으나, 수정에서는 닫혀있어야 한다는 법칙입니다. 다시 말해, 원래의 코드에서 기능을 추가해야 하나 변경을 하지 않아야 한다는 말입니다. 

 

아니 무슨 소리야... 변경을 하지 않고 어떻게 기능을 추가해?

 

이를 지키기 위해서 쓰는 방법은 주로 인터페이스나 추상 클래스입니다. 해당 방법을 통해 공통적인 부분은 추상화시키고 개별적인 부분은 따로 구현하여 개방-폐쇄의 원칙을 만족시킬 수 있습니다.

 

개발자가 추가될 때마다 코드가 수정되어야 함

새로운 개발자만 추가시키면 된다!

L : Liskov Substitution (리스코프 치환)

리스코프라는 컴퓨터 과학자가 어떠한 컨퍼런스에서 최초로 발표한 내용을 바탕으로 만들어졌습니다. 쉽게 말해 부모 객체와 자식 객체가 있다고 가정할 때, 자식은 당연히 부모 객체의 역할을 할 수 있어야 한다는 원칙입니다. (현실에서는 부모님이 더 많은 역할을 하심)

 

상속과 깊게 연관이 있기 때문에, 일반적으로 리스코프 치환 원칙이 지켜지지 않으면 개방-폐쇄의 원칙도 위반한다고 합니다.

 

위반 사례. 휴식도 하면서 일해야 한다.

I : Interface Segregation (인터페이스 분리)

클라이언트가 자신이 호출하지 않는 메소드에 의존하지 않아야 한다는 원칙입니다. 인터페이스, 혹은 추상 클래스가 하나의 책임만을 가져야 한다는 뜻이 될 수 있습니다.

 

a, b, c라는 기능을 가지는 A라는 클래스가 있다고 가정할 때, D라는 클래스가 b, c라는 기능만을 상속받고 싶다고 A라는 클래스를 상속받아 버리면  B에게는 쓸모없는 A라는 기능도 같이 상속이 되어 버릴 것입니다. 그러나 a, b, c라는 기능을 각각 A, B, C라는 클래스가 담당하고 있다면, D라는 클래스는 B, C 클래스만을 상속하면 되겠죠. (물론 자바에서 추상 클래스의 다중 상속은 안됩니다.) 

 

죽여줘

D : Dependency Inversion (의존관계 역전)

자주 변경되지 않는 구현체에 의존하라는 법칙입니다. 의존성을 가지는 대상이 변경되게 되면 의존하는 주체도 함께 변경이 되므로 코드의 변경이 잦아질 수밖에 없습니다. 그러나 코드가 덜 바뀌는 인터페이스나 추상 클래스에 의존하게 된다면 비교적 적은 수정 작업을 가진 코드를 만들게 됩니다.

 

SOLID 법칙을 정리하다 보니 추상 클래스와 인터페이스 개념과 연관되는 부분이 많은 것 같습니다. 이 두가지 개념을 적절히 잘 활용하면 객체 지향 법칙을 준수하면서 개발하는 이상적인 개발자가 될 수 있을 거란 생각이 듭니다.