[스프링 입문을 위한 자바 객체 지향의 원리와 이해] 5장 : 객체 지향 설계 5원칙

객체 지향 설계 5원칙

• 객체 지향의 개념과 4대 특성
  • 좋은 도구을 알게됨.
  • 좋은 도구가 있어도 올바르게 사용하는 방법을 알아야 좋은 요리가 나옴.
• 객체 지향 설계 (Object Oriented Design) 5원칙
  • SOLID (객체 지향을 올바르게 사용하는 방법)
    • SRP (Single Responsibility Principle) : 단일 책임 원칙
    • OCP (Open Closed Princinple) : 개방 폐쇄 원칙
    • LSP (Liskov Substitution Principle) : 리스코프 치환 원칙
    • ISP (Interface Segregation Principle) : 인터페이스 분리 원칙
    • DIP (Dependency Inversion Principle) : 의존 역전 원칙

응집도는 높이고 결합도는 낮추는 객체 지향의 원칙을 지킬 수 있는 방법들.

-> 결합도가 낮으면 모듈 간의 상호 의존성이 줄어들어 객체의 재사용이나 수정, 유지보수가 용이함.

-> 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용이나 기능의 수정, 유지보수가 용이함.

 

SOLID를 녹여낸 소프트웨어

SOLID는 소프트웨어에 녹여내야하는 개념.

• SOLID를 잘 녹여낸 소프트웨어는 이해하기 쉽고 리팩터링과 유지보수가 쉽다. 
• SOLID는 객체 지향 4대 특성을 발판으로 삼고 디자인 패턴의 뼈대이며 스프링 프레임워크의 근간이다.

SRP - 단일 책임 원칙

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

남자는 너무 많은 역할과 책임을 가진다

객체 지향 세계에서는 이런 경우 "나쁜 냄새"가 난다고 한다.

남자는 너무 많은 역할(책임)을 가진다

남자의 책임을 분리해 여러 개의 클래스를 만들자.

남자에게 단일 책임 원칙 적용

남자라는 클래스가 역할과 책임에 따라 네 개의 클래스로 쪼개졌다. 클래스명 또한 역할과 일치하기 때문에 이해하기 쉽다.

• 남자 친구는 여자 친구와 이별하더라도 다른 곳에는 영향을 주지 않는다.
• 단일 책임 원칙은 "속성, 메서드, 패키지, 모듈, 컴포넌트, 프레임워크" 등에 적용할 수 있다.

속성의 SRP 위배

• 문제 코드

public class 사람 {
	String 군번;

	public static void main(String[] args) {
		사람 로미오 = new 사람();
		사람 줄리엣 = new 사람();

		줄리엣.군번 = "11-730411994";
	}
}

 

줄리엣은 여자이므로 '군번'을 가질 수 없다. 하지만 줄리엣은 군번 속성에 값을 할당하거나 읽어올 수 있는 코드이다.

따라서 이 코드는 현재 냄새가 나고 있다...

 

**가질 수 없는 속성 개선**

이를 개선하기 위해선 남자 클래스만 군번을 갖게 하면된다. 여자와 남자의 공통적만 모아 사람 클래스를 상위 클래스로 만들 수도 있고 둘의 공통점이 없다면 남자 클래스와 여자 클래스로 나눠서 구현할 수 있다. 

 

**하나의 속성이 여러 속성을 가지는 경우**

데이터베이스 테이블에 존재하는 하나의 필드가 여러 속성을 가르키게 되면 정규화를 통해 단일 책임 원칙을 유지하도록 해야한다.

메서드가 SRP 위배

• 문제 코드

public class 강아지 {
	final static Boolean 숫컷 = true;
	final static Boolean 암컷 = false;
	Boolean 성별;

	void 소변보다() {
		if (this.성별 == 숫컷) {
			// 한쪽 다리를 들고 소변을 본다.
		} else {
			// 뒤다리 두 개로 앉은 자세로 소변을 본다.
		}
	}
}

 

강아지가 "수컷"인지 "암컷"인지에 따라 메서드에서 분기 처리가 진행되고 있다.

 

이는 강아지 클래스에서 "소변보다"의 암컷과 수컷 강아지의 행위를 모두 구현하려고 했기 때문에 "단일 책임 원칙"을 위배하게 되었다.

 

• 개선 코드

package srp.good;

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

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

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

추상 메서드를 통해 행위가 다른 메서드의 구현을 하위 클래스에게 위임한다.

-> 암컷과 수컷 강아지의 서로 다른 행위의 구현을 하위 클래스에 맡겼기 때문에 "단일 책임 원칙"을 지킬 수 있었다.

 

"상속"은 "단일 책임 원칙"을 지키키 위한 도구로 사용한다.

 

모델링을 담당하는 "추상화"는 "단일 책임 원칙"과 가장 관계가 깊다.

-> "애플리케이션 경계(context)"를 정하고 추상화를 통해 클래스의 속성과 메서드를 설계할 때 반드시 단일 책임 원칙을 고려하자!!

 

OCP - 개방 폐쇄 원칙

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

--> 위 인용을 의역해보면 "자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 한다" 라는 말이라고 한다...

 

<문제 코드>

운전자(자신)가 "소나타"를 운전하든 "마티즈"(주변)를 운전하든 행동에 변화가 오면 안된다.

-> 주변의 변화에 자신이 변화해야 하는 경우 (문제)

 

현실 세계 였다면 자신이 변화하면 되는 문제지만 객체지향 세계는 다른 해결책을 사용한다.

• 개선 방법

개방 폐쇄 원칙 적용

상위 클래스 or 인터페이스를 중간에 둠으로써 다양한 자동차가 생긴다고 해도 객체지향세계의 "운전자"는 영향을 받지 않게 된다.

• 운전자의 입장에선 주변의 변화에 영향을 받지 않게 된다. (마티즈 - 소나타 든 신경안씀)
• 자동차의 입장에선 자신의 확장에 개방되 있는 것이다. (마티즈 - 소나타로 확장)

OCP의 예

JDBC

OCP예 : JDBC

• 자바 애플리케이션은 JDBC 인터페이스를 완충 장치 삼아 변화에 영향을 받지 않게 된다. (변화에 닫혀있음)
• 데이터베이스를 다른 데이터베이스로 교체하는 것은 자신의 확장에 열려있는 것이다. (확장에는 열려있음)

다른 예로는
-> 개발자가 JVM이라는 완충 장치가 있기에 개발자가 작성한 소스코드는 운영체제에 닫혀있고 각 운영체제별 JVM은 확장에 열려있는 구조이다.

 

개방 폐쇄 원칙을 무시하고 프로그램을 작성하면 객체 지향의 장점인 유연성, 재사용성, 유지보수성 등의 이점을 얻을 수 없다.

 

==> 그 역할에 주어진 책임을 수행할 수 있다면 누구나 그 역할이 될 수 있다.

==> 스프링은 개방 폐쇄 원칙의 김연아라고 할 정도로 원칙을 잘 활용하고 있다.

 

⇒ 확장은 못하고 변화에 영향을 받지 않는다..??? (DIP!!)

LSP - 리스코프 치환 원칙

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

상속에서 기억해야 할 것 -> 객체 지향의 상속은 계층도가 아닌 분류도가 되어야 한다. (슈퍼클래스 서브클래스 구조)

 

 

• 리스코프 치환 원칙을 잘 지키고 있는 클래스
  • 하위 클래스 is a kind of 상위 클래스 - 하위 분류는 상위 분류의 한 종류이다.
  • 구현 클래스 is able to 인터페이스  - 구현 분류는 인터페이스할 수 있어야 한다.

잘못된 상속 예시  (계층도)

아버지 - 딸 (기반 타입 - 서브 타입)은 계층도 형태의 잘못된 상속이라고 볼 수 있다.

그렇다면 무엇이 문제일까? 한번 리스코프 치환 법칙을 적용해보자.

 

• 아버지 춘향이 = new 딸() -> 불가능!!!!

딸이 태어나 아버지의 역할을 하는 것은 말이 안된다.

춘향이는 아버지형 객체 참조 변수를 가지므로 아버지 객체가 가진 행위를 할 수 있어야 한다...(할 수 없음)

올바른 예시  (분류도)

 

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

펭귄 한 마리가 새롭게 태어나 동물의 행위를 한다. -> 이상한 점 없음

리스코프 치환 원칙을 만족한다.

 

**결론**

-> "하위 클래스 인스턴스는 상위형 객체 참조 변수에 대입해 상위 클래스의 인스턴스 역할을 하는 데 문제가 없어야 한다"

 

리스코프 치환 원칙 적용 사례

리스코프 치환 원칙은 상속이라는 특성을 올바르게만 사용하면 자연스럽게 얻을 수 있다.

그렇다면 리스코프 치환 원칙이 위배되었을 때 어떤 문제가 발생하는가?

 

ISP - 인터페이스 분리 원칙

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

단일책임 원칙을 적용하기 전 남자 클래스를 살펴보자.

너무 많은 책임과 역할을 가진 남자..

서로 간의 영향을 줄이기 위해 "단일 책임 원칙"을 적용시킬 수 있었다.

 

이때 클래스를 토막내는 것 말고는 다른 방법은 없을까???

새로운 방법 : 인터페이스 분할 원칙

인터페이스 분할 원칙이 적용된 남자 클래스

이 방법은 남자 클래스를 책임과 역할에 따라 클래스를 쪼개는 것이 아니다.

 

대신 남자를 다중 인격화(?)(제한)시켜
직장상사와 있을 땐 "출근하기(), 아부하기()" 행위만 하도록 제한하고

어머니와 있을 땐 "효도하기(), 안마하기()" 행위만 하도록 제한시키는 방법이다.

 

결론적으로 "단일 책임 원칙"과 "인터페이스 분할 원칙"은 같은 문제(다중 책임)에 대한 두 가지 다른 해결책이다.

 

• 인터페이스 분할 원칙은 인터페이스 최소주의 원칙을 가진다.
  • 최소주의란 인터페이스를 통해 외부에 메서드 제공시 최소한의 메서드만 제공해야한다.
  • 예를 들어, 사원 인터페이스에 키스하기() 메서드를 제공하면 안되는 것과 같은 이유이다. (사원의 책임에 부합하지 않는다.)

상위 클래스는 풍성할수록 좋고 "인터페이스"는 작을수록 좋다.

빈약한 상위 클래스 vs 풍성한 상위 클래스

빈약한 상위클래스를 사용하면 속성과 메서드가 하위클래스에서 중복되는 경우가 발생한다.

 

하지만 풍성한 상위 클래스에서는 하위 클래스에서 공통으로 가질 속성과 메서드를 상속한다.

DIP - 의존 역전 원칙

"고차원 모듈은 저차원 모듈에 의존하면 안된다. 이 둘은 모두 다른 추상화된 것에 의존해야한다."
"추상화 된 것은 구체적인 것에 의존하면 안된다. 구체적인 것이 추상화된 것에 의존해야한다."

 

의존 역전 원칙  적용 전(구체 클래스에 의존)

위의 예시처럼 자동차와 스노우타이어 사이에는 의존 관계가 존재한다.

자동차가 스노우타이어에 의존하는 관계이다.

 

자동차는 10년이상도 탈 수 있지만 스노우타이어는 계절이 바뀌면 일반 타이어로 바꿔줘야 한다.

-> 즉, 스노우타이어가 자동차보다 자주 변경된다.

 

그렇기 때문에 자동차는 자신보다 자주 변경되는 클래스에 의존해 부서지기 쉽고 냄새를 풍기는 클래스이다. 이를 개선해보자!

 

개선 방법

의존 역전 원칙 적용 후

위 그림처럼 자동차가 "스노우타이어"가 아닌 추상화된 타이어 인터페이스에 의존하게 해보자.

인터페이스의 구현체가 변경(스노우 -> 일반)되도 자동차는 그 영향을 받지 않는다.

 

이 해결책은 "개방 폐쇄 원칙"도 녹아들어 있는 것을 볼 수 있다. 하나의 해결책에 여러 설계를 찾을 수 있다.

 

 

자, 그러면 왜 "의존 역전 원칙"이라고 부를까??

 

이제 개선된 방법의 스노우타이어와 기존 방법의 스노우타이어를 비교해보자.

기존 스노우타이어는 어떤 곳에도 의존하지 않는 클래스였지만 개선 방법에선 추상적인 타이어 인터페이스에 의존하게 되었다.

 

즉, 자동차는 자신이 의존하던 타이어 대신 더 추상화된 타이어 인터페이스에 의존하고 스노우 타이어 또한 추상적인 타이어 인터페이스에 의존하도록 하는 것이다. (의존 방향이 바뀐 것을 볼수 있다)

 

⇒ 확장은 못하고 변화에 영향을 받지 않는다..??? (DIP!!)

 

**결론 -> "자신보다 변하기 쉬운 것에 의존하지 마라." **