⭐️ 객체 지향 설계 5원칙

객체 지향의 개념과 4대 특성
앞의 3개의 장을 통해 객체 지향의 개념과 4대 특성을 학습했다. 이제 객체 지향 프로그램을 작성할 수 있는 도구를 획득한 것이다.
요리로 비유하자면 객체 지향의 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) : 의존 역전 원칙

이 원칙들은 갑자기 생긴 것이 아니다. 응집도는 높이고(High Cohesion), 결합도는 낮추라는(Loose Coupling)는 고전 원칙을 객체 지향의 관점에서 재정립한 것이라고 할 수 있다.

• 결합도가 낮으면 모듈 간의 상호 의존성이 줄어들어 객체의 재사용이나 수정, 유지보수가 용이하다.
• 응집도가 높은 모듈은 하나의 책임에 집중하고 독립성이 높아져 재사용이나 기능의 수정, 유지보수가 용이하다.

📌 SRP - 단일 책임 원칙

위 그림과 같이 남자라고 하는 클래스와 남자 클래스에 의존하는 다양한 클래스가 있다고 생각해 보자.

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

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

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

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

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

---

단일 책임 원칙은 잘된 경우보다 잘못된 경우를 살펴보는 것이 이해하는 데 좋다.
먼저 속성이 단일 책임 원칙을 지키지 못하는 경우를 살펴보자.
객체 지향 세계에서 남자는 반드시 군대를 가고, 여자는 절대로 군대를 가지 않는다고 가정하자. 그런데 사람 클래스에 군번 속성이 있다면 어떻게 될까?

✔︎ 속성의 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 {
			// 뒤다리 두 개로 앉은 자세로 소변을 본다.
		}
	}
}

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

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

메서드가 단일 책임 원칙을 지키지 않을 경우 나타나는 대표적인 냄새가 바로 분기 처리를 위한 if 문이다. 이런 경우 단일 책임 원칙을 적용해 코드를 리팩토링 해야 한다.

리팩토링 코드

package srp.good;

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

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

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

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

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

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

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

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

📌 OCP - 개방 폐쇄 원칙

어느 날 한 운전자가 마티즈를 구입했다. 그리고 훗날 그 운전자에게 쏘나타가 생겼다.
기어가 수동이던 마티즈에서 기어가 자동인 쏘나타로 차종을 바꾸니 운전자의 행동 또한 변화가 생긴다. 그렇다면 운전자는 차량에 따라 운전하는 습관을 바꿔야할까?
현실이라면 당연히 어느 정도 변화가 있겠지만 객체 지향 세계는 다른 해법이 있다.

상위 클래스 or 인터페이스를 중간에 둔다.

• 다양한 자동차가 생긴다고 해도 객체지향세계의 "운전자"는 영향을 받지 않게 된다.

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

📌 LSP - 리스코프 치환 원칙

상속에 대해 설명하면서 객체 지향에서의 상속은 조직도나 계층도가 아닌 분류도가 돼야 한다고 했다.

리스코프 치환 원칙을 잘 지키고 있는 클래스

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

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

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

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

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

춘향이는 아버지형 객체 참조 변수를 가지므로 아버지 객체가 가진 행위를 할 수 있어야 한다. 그런데 춘향이에게 아버지의 어떤 역할을 시킬 수 있을까?

올바른 예시 (분류도)

• 동물 뽀로로 = new 펭귄()
  펭귄 한 마리가 새롭게 태어나 동물의 행위를 한다. 논리적인 흠이 없다. 펭귄 한 마디가 태어나 뽀로로라 이름을 짓고 동물의 행위(메서드)를 하게 하는데 전혀 이상함이 없다.

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

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

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

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

SRP에서 사용했던 예제를 다시 살펴보자.

단일 책임 원칙을 적용하기 전 남자 클래스는 위 그림과 같았다.

남자에게 너무 많은 책임이 몰렸기에 단일 책임 원칙을 적용했다.

단일 책임 원칙에서 제시한 해결책은 남자 클래스를 쪼개서 하나의 역할(책음)만 하는 다수의 작은 클래스로 분할하는 것이었다.
그런데 이 방법뿐일까?

새로운 방법: ISP(인터페이스 분리 원칙)

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

필요한 경우에 필요한 역할만 할 수 있게 인터페이스로 제한하는 것이다.
결론적으로 "단일 책임 원칙"과 "인터페이스 분할 원칙"은 같은 문제(다중 책임)에 대한 두 가지 다른 해결책이다.

인터페이스 분할 원칙은 인터페이스 최소주의 원칙을 가진다.
최소주의란 인터페이스를 통해 외부에 메서드 제공시 최소한의 메서드만 제공해야한다.

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

빈약한 상위클래스를 사용하면 속성과 메서드가 하위클래스에서 중복되는 경우가 발생한다.
하지만 풍성한 상위 클래스에서는 하위 클래스에서 공통으로 가질 속성과 메서드를 상속한다.

📌 DIP - 의존 역전 원칙

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

자동차는 10년이상도 탈 수 있지만 스노우 타이어는 계절이 바뀌면 일반 타이어로 교체해야 한다.
즉, 스노우타이어가 자동차보다 자주 변경된다. 스노우 타이어를 일반 타이어로 교체할 때 자동차는 그 영향에 노출돼 있다.

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

---

개선

위 그림처럼 자동차가 타이어 인터페이스에 의존하게 해보자.

인터페이스의 구현체가 변경되어도 자동차는 그 영향을 받지 않는다.

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

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

---

출처
스프링 입문을 위한 자바 객체 지향의 원리와 이해
https://github.com/expert0226/oopinspring