3년전쯤 다니던 회사에서 팀장님이 물으셨다.
-"필자야 SOLID가 뭔지아니?"
-"그 옛날 가수요..?"
-"하아... 공부좀 하자"
이후 SOLID에 대해 알아 보았고, 그 당시에는 아 이런것들이 있구나만 생각을 했었다. 시간이 지나면서 여러 코드를 보고 책들을 읽다보니 그 당시에는 몰랐던것들이 보이면서 이해가 되기 시작하였다. SOLID 원칙이 왜 생겼는가에 대해 내가 이해한것들을 바탕으로 SOLID에서 이야기 해보려고한다.
SOLID
- 유지보수와 확장이 쉬운 시스템을 만들기 위한 객체지향 설계 5대 원칙
-> 프로그래밍을 유지보수와 확장이 쉽게 하다보니 몇가지 규칙이 있었고 거기서 제일 중요한 5가지를 제안한것.
Single Responsibility Principle : 단일책임원칙
객체는 하나의 책임만 가져야한다.
-> 유지보수, 특히 변경이 있을 때 주요하다고 생각된다. 객체에 책임이 많아 질수록 변경을 하기가 어렵다. 변경에 따른 영향도가 크기 때문이다. 결국은 변경이 일어날때 최소한으로 수정할수 있도록 프로그래밍을 설계하는 것이다. 중요한것은 단일책임이라는 기준을 적절히 선택하는 것이다.
Open/Closed principle : 개방 폐쇄 원칙
확장에는 열려 있으나 변경에는 닫혀 있어야한다.
-> 객체를 변경하거나 추가를 할수 있도록 하고 그 객체를 가져다 쓰는 쪽에서는 코드가 변경이 되지 않도록 하는것이다. 예를 들어 내가 쇼핑몰을 개발한다고 하자. 결제 시스템이 여러가지이다. 카카오페이, 네이버페이, pg사 등등.. 결제 플로우에 대한 부분은 추상화 하여 결제연동을 부분을 구현하여 객체를 추가한다면 유지보수가 쉬워지고 확장성을 높이게 된다.
Liskov substitution principle : 리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.
-> 부모클래스의 인스턴스를 하위타입의 인스턴스로 사용해도 문제가 없도록 설계를 해야한다는것이다. 예를 들어 부모 객체에서는 0 보다 큰값을 반환해야 하는데 이보다 작은 값을 자식 객체에서 반환한다면 문제가 생길 수 밖에없다. oop의 특성인 상속을 제대로 쓰라는 의미에서 리스코프 치환 원칙이 있는것 같다.
Interface segregation principle : 인터페이스 분리 원칙
클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다.
-> 말그대로 자신이 이용하지 않는 메소드에 의존하지 말고 인터페이스를 분리 하라는 뜻이다. 필요가 없는 메소드가 인터페이스에 들어간다면 혼란만 가중될 뿐이다.
Dependency inversion principle :
추상화에 의존하고 구체화에 의존하면 안된다. 자기보다 변하기쉬운것에 의존하지마라.
-> 클래스 A 가 있고 클래스 B에 의존할경우 클래스 B가 변경된다면 클래스 A도 변경을 해주어야한다. (A-B) 이때 , 중간에 추상화된것(C)을 둔다면 변경되기 쉬운 B가 변경되더라도 클래스 A는 영향이 없기 때문에 의존하지 말라고 하는것이다 (A-C-B)
결론
유지보수를 쉽게하기 위한 객체지향 설계 5원칙에 대해 알아보았습니다. 여기서 유지보수를 쉽게 한다는 의미가 무슨 뜻일까요? 저는 유지보수란 코드를 변경하는 것이고 유지보수를 쉽게 한다는 것은 코드 변경에 시간을 덜들어가게 하는것이라고 생각합니다. 코드변경에 시간을 줄이려면 아래 같은 조건들이 필요합니다.
- 코드를 쉽게 읽을 수 있어야한다.
- 코드의 변경범위를 빠르게 정할 수 있어야한다.
- 코드의 변경의 영향도를 쉽게 알수 있어야한다.
- 코드의 변경량이 적어야한다.
위 조건들을 만족하기 위하여 SOLID가 나왔다고 생각합니다. 아직 코드들을 작성할 때 위조건들을 완전히 만족시키는 것은 아니지만 항상 염두해두고 작성을 해야겠습니다.
P.S. 위 내용들은 제생각이 들어간것이라 틀린것 일 수도있습니다.
[참고]
