객체 지향 설계 5원칙 - SOLID

 

 

 

SOLID는 다음의 객체 지향 설계 5원칙을 두문자어로 표현한 말이다. 해당 원칙은 응집도는 높이고 (High Cohesion), 결합도는 낮추라(Loose Coupling)는 고전 원칙을 객체 지향의 관점에서 재정립한 것이라고 할 수 있다.

- SRP (Single Responsibility Principle) : 단일 책임 원칙
- OCP (Open Closed Principle) : 개방 폐쇄 원칙
- LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
- ISP (Interface Segregation Priniciple) : 인터페이스 분리 법칙
- DIP (Dependency Inversion Principle) : 의존 역전 원칙

 

결합도?

결합도는 모듈(클래스) 간의 상호 의존 정도로서, 결합도가 낮으면 모듈 간의 상호 의존성이 줄어들어 객체의 재사용이나 수정, 유지보수가 용이하다. 

 

응집도?

응집도는 하나의 모듈 내부에 존재하는 구성 요소들의 기능적 관련성으로, 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용이나 기능의 수정, 유지보수가 용이하다.

 

 

 

SOLID는 제품이 아닌 개념이다. 따라서 보는 사람의 관점에 따라 잘 적용됐는지 아닌지 애매모호하거나 다르게 해석될 수 있는 소지가 있지만, 이를 잘 녹여내 소프트웨어를 만든다면, 그렇지 않은 소프트웨어에 비해 상대적으로 이해하기 쉽고, 리팩터링과 유지보수가 수월할 뿐만 아니라 논리적으로 정연하다.

 

 

이러한 SOLID는 이후에 소개할 디자인 패턴의 뼈대이자 스프링 프레임워크의 근간이기도 하다. 

 

 

💡 SRP - 단일 책임 원칙

 

어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
로버트 C. 마틴

 

 

간단한 예를 들자면, 강아지라는 클래스가 있을 때, 소변보다 라는 메서드에서 if 문을 통해 남자인경우와 여자인 경우를 나눠서 소변을 보는 방식을 다르게 써줬다고 가정을 해보자.

class 강아지 {
	final static Boolean 수컷 = true;
    final static Boolean 암컷 = false;
    Boolean 성별;
    
    void 소변보다() {
    	if(this.성별 == 수컷) {
        	//한쪽 다리를 들고 소변을 본다.
        } else {
        	//뒷다리 두 개를 굽혀 앉은 자세로 소변을 본다.
        }
    }
}

 

이런 경우 소변보다() 메서드가 수컷 강아지의 행위와 암컷 강아지의 행위를 모두 구현하려고 하기에 단일 책임 원칙을 위배하고 있는 것이다. 특히 이런 분기 처리를 위한 if문을 대표적인 경우라고 할 수 있다.

 

이것을 단일 책임 원칙을 적용해 코드를 리팩터링하면, 다음과 같이 만들 수 있다.

abstract class 강아지 {
	abstract void 소변보다()
}

class 수컷강아지 extends 강아지 {
	void 소변보다() {
    	//한쪽 다리를 들고 소변을 본다.
    }
}

class 암컷강아지 extends 강아지 {
	void 소변보다() {
    	//뒷다리 두 개를 굽혀 앉은 자세로 소변을 본다.
    }
}

 

🙋🏻‍♀️  단일 책임 원칙과 객체 지향 4대 특성은 어떻게 결부돼 있을까?

모델링 과정을 담당하는 추상화임을 알 수 있다.

애플리케이션의 경계를 정하고, 추상화를 통해 클래스들을 선별하고 속성과 메서드를 설계할 때 반드시 단일 책임 원칙을 고려하는 습관을 들이자. 그리고 리팩터링을 통해 코드를 개선할 때도 단일 책임 원칙을 적용할 곳이 있는 지 꼼꼼히 살피자.

 

 

💡 OCP - 개방 폐쇄 원칙

 

소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에 대해서는 열려 있어야 하지만
변경에 대해서는 닫혀 있어야 한다.
로버트 C. 마틴

 

 

위의 문장의 조금 더 의역해 보면 "자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다." 정도로 의역해 볼 수 있겠다.

 

한가지 예를 들어보자면, JDBC를 한번 떠올려보자. JDBC를 사용하는 클라이언트는 데이터베이스가 오라클에서 MYSQL로 바뀌더라도 Connection을 설정하는 부분 외에는 따로 수정할 필요가 없다. Connection 설정 부분을 별도의 설정 파일로 분리해두면 클라이언트 코드는 단 한줄도 변경할 필요가 없다. 이것을 보면 오라클을 MYSQL로  교체한다는 것은 데이터베이스가 자신의 확장에는 열려 있지만, 오라클을 MYSQL로 교체하더라도 JDBC 인터페이스라고 하는 완충 장치로 인해 변화에 영향을 받지 않으므로, 변화에 닫혀있다고 할 수 있는 것이다.

 

개방 폐쇄 원칙을 따르지 않는다고 해서 객체 지향 프로그램을 구현하는 것이 불가능한 것은 아니지만, 무시하고 프로그램을 작성하면 객체 지향 프로그래밍에서 가장 큰 장점인 유연성, 재사용성, 유지보수성 등을 얻을 수 없다. 따라서 반드시 지켜야 할 원칙이다.

 

 

💡 LSP - 리스코프 치환 원칙

 

서브 타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다.
로버트 C. 마틴

객체 지향의 상속은 다음의 조건을 만족해야 한다.

- 하위 클래스 is a kind of 상위 클래스 - 하위 분류는 상위 분류의 한 종류다.
- 구현 클래스 is able to 인터페이스 - 구현 분류는 인터페이스할 수 있어야 한다.

 

위 두개의 문장대로 구현된 프로그램이라면 이미 리스코프 치환 원칙을 잘 지키고 있다고 할 수 있다. 위 문장대로 구현되지 않은 코드가 존재할 수 있는 데, 바로 상속이 조직도나 계층도 형태로 구축된 경우다. 예를 들어 아버지를 상위 클래스로 하는 딸이라는 하위 클래스가 있다고 하자. 이런 경우가 바로 전형적인 계층도 형태이며, 객체 지향의 상속을 잘못 적용한 예이다. 보통 상속을 부모 객체와 자식객체로 비유를 하며 생기는 오해이다. 

 

아버지 춘향이 = new 딸();

 

딱 봐도 이상하다. 딸을 하나 낳아서 이름을 춘향이라 한 것 까지는 좋은데, 아빠의 역할을 맡기고 있는 셈이다. 

 

반대로 분류도의 형태를 가지고 있다고 생각해보자.

 

동물 뽀로로 = new 펭귄();

 

논리적인 흠이 없다. 펭귄 한 마리가 태어나 뽀로로라 이름을 짓고 동물의 행위를 하게 하는데 전혀 이상함이 없다. 

 

즉, 아버지 - 딸 구조(계층도/조직도)는 리스코프 치환 원칙을 위배하고 있는 것이며, 동물 -펭귄 (분류도)는 리스코프 치환 원칙을 만족하는 것이다. 

 

 

💡 ISP - 인터페이스 분리 원칙

 

클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안 된다.
로버트 C. 마틴

 

남자라는 클래스가 있다고 예를 들어보자. 이 남자 클래스는 남자친구로서의 기념일챙기기(), 키스하기() 라는 행위를 하고, 아들로서 효도하기(), 안마하기() 행위를 할 수 있다고 해보자. 남자 클래스는 남자친구와 아들로서의 여러가지 책임을 동시에 가지고 있다. 이는 앞서 말했던 단일 책임 원칙에서 벗어난다고 할 수 있다. 단일책임원칙의 해결법으로는, 남자 클래스를 남자친구 클래스와, 아들 클래스로 분리시켜 하나의 책임만을 지닐 수 있도록 하는 것이다.

 

반면, 인터페이스 분리 원칙에서의 해결법은 이 남자 클래스의 역할을 남자친구 인터페이스와 아들 인터페이스로 나누어 여자친구를 만날 때는 남자친구 역할만 할 수 있게 인터페이스로 제한하고, 어머니와 있을 때는 아들 인터페이스로 제한하도록 하는 것이다.

 

결국, 단일 책임 원칙과 인터페이스 분할 원칙은 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다. 프로젝트 요구사항과 설계자의 취향에 따라 단일 책임 원칙이나 인터페이스 분할 원칙 중 하나를 선택해서 설계할 수 있다. 하지만 특별한 경우가 아니라면 단일 책임 원칙을 적용하는 것이 더 좋은 해결책이라고 할 수 있다.

 

이러한 개념과 함께 자주 등장하는 원칙 중 하나에는 인터페이스 최소주의 원칙이라는 것이 있다. 인터페이스를 통해 메서드를 외부에 제공할 때는 최소한의 메서드만 제공하라는 것이다. 즉 남자친구 인터페이스에는 효도하기() 메서드를 제공할 필요도 없고, 제공해서도 안된다는 것이다. 

 

"상위 클래스는 풍성할수록 좋고, 인터페이스는 작을수록 좋다" 라는 말이 있다. 그 이유에 대해서 살펴보자면, 사람이라는 클래스가 있고, 이를 확장한 학생클래스와 군인 클래스가 있다고 가정해보자. 현재 상황은 사람클래스에는 단지 이름이라는 속성과, 먹다()라는 메서드만 있으며, 학생과 군인에서 공통적으로 자다(), 소개하다() 이러한 메서드가 추가적으로 더 필요한 상황이다.

이런 상황에서, 상위 클래스(사람)형의 참조 변수를 이용할 때, 여기저기서 형변환이 발생하면서 상속의 혜택을 제대로 누리지 못할 것이다. 물론 여기서 학생과 군인에서 실제로 소개하다() 메서드가 동일한 기능을 수행하지 않을 것이다. 이 경우에 사용하는 것은 바로  추상메서드가 될 것이다.

 

 

💡 DIP - 의존 역전 원칙

 

고차원 모듈은 저차원 모듈에 의존하면 안 된다.

이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.

 

추상화된 것은 구체적인 것에 의존하면 안 된다.
구체적인 것이 추상화된 것에 의존해야 한다.

자주 변경되는 구체클래스에 의존하지 마라.

- 로버트 C. 마틴

쉽게 한가지 예를 통해 설명해보자. 자동차라는 클래스가 있다. 이 클래스가 만약에 스노우타이어라는 클래스에 의존을 하고 있다고 가정했을 때, 추운 겨울이 지나면 일반 타이어로 계절마다 바꿔줘야하는 경우가 발생하면, 자동차 클래스는 타이어가 바뀔 때 당연히 그 영향에 노출될 것 이다. 바로 자동차 자신보다 더 자주 변하는 스노우 타이어에 의존하고 있는 것이다. 

 

이런 경우, 구체적인 스노우타이어, 일반타이어, 광폭타이어가 아닌 추상화된 타이어 인터페이스에만 의존하게 함으로써 스노우타이어에서 일반타이어로, 또는 다른 구체적인 타이어로 변경돼도 자동차가 그 영향을 받지 않는 형태로 구성하면 된다.

 

정리하자면, 기존에는 스노우타이어가 그 무엇에도 의존하지 않는 클래스였는데, 추상적인 것인 타이어 인터페이스에 의존하게 되었다. 의존의 방향이 역전된 것이다. 그리고 자동차는 자신보다 변하기 쉬운 스노우타이어에 의존하던 관계를 중간에 추상화된 타이어 인터페이스를 추가해 두고 의존 관계를 역전시키고 있다. 이처럼 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 것이 의존 역전 원칙이다.