04. SOLID

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

각 원칙은 객체지향 언어에서 좋은 설계를 얻기 위해 지켜야 할 규범이다. 소프트웨어의 유지보수성, 확장성을 높이는 것이 목적이다.

코드 유지보수성을 판단할 때 사용할 수 있는 실무적인 세 가지 맥락이 있다.

1. 영향 범위: 코드 변경으로 인한 영향 범위가 어떤지
2. 의존성: 소프트웨어의 의존성 관리가 제대로 이뤄지는지
3. 확장성: 쉽게 확장이 가능한지

SOLID는 이러한 질문의 답을 알려주는 원칙이다!

 

4.1 SOLID 소개

단일 책임 원칙

💡 클래스를 변경해야 할 이유는 단 하나여야 한다.

 

단일 책임 원칙은 클래스에 하나의 책임만 할당하여 변경 범위 및 영향을 최소화 하는 것이다.

 

예를 들어 하나의 클래스가 너무 많은 책임을 가지고 있어 여기저기서 해당 클래스를 참조한다고 생각해보자. 그런 와중에 해당 클래스의 어떤 코드를 변경하려고 하면 변경하려는 코드가 어디까지 영향을 줄지 가늠하기가 어려워진다. 이는 결과적으로 코드 변경 자체가 어려워지는 결과를 낳게 된다. 그래서 과하게 집중된 책임을 피하고 분할해야 한다.

 

하나의 책임을 가지면 코드 이해도 쉬워지고, 코드 변경의 영향도 예측할 수 있으며 코드 변경 범위도 좁아진다. 즉, 변경으로 인한 영향 범위를 최소화할 수 있게 된다.

 

단일 책임에서의 책임이란? - 액터(Actor)에 대한 책임

상황과 이를 바라보는 개인에 따라 책임은 모호하다. 그래서 책임을 설명하기 위한 “액터(Actor)”라는 개념의 등장

 

“하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.”

책임이 무엇인지보다는 액터에 집중하자. 즉, 메시지를 보내는 주체가 하나인지 둘 이상인지를 보고 단일 책임인지를 판단할 수 있다.

클래스를 변경할 이유는 유일한 액터의 요구사항이 변경될 때로 제한되어야 한다.

 

개방 폐쇄 원칙

💡 클래스의 동작을 수정하지 않고 확장할 수 있어야 한다.

 

“확장에는 열려 있고 변경에는 닫혀있어야 한다.”라고 말하기도 한다. 기존 코드의 변경없이 확장이 가능한 시스템을 만드는 것이다.

 

한마디로 구현에 의존하지 말고 역할에 의존하면 해당 역할을 할 수 있는 구현체만 바꾸어 기존 코드의 변경없이(구현체를 변경하는 코드 변경은 어쩔 수 없음) 확장이 가능해진다.

 

리스코프 치환 원칙

💡 하위 클래스는 상위 클래스를 대체할 수 있어야 한다.

 

@Getter
@Setter
@AllArgsConstructor
class Rectangle {

	protected long width;
	protected long height;
	
	public long calculateArea() {
		return width * height;
	}
}

class Square extends Rectangle {

	public Square(long length) {
		super(length, length);
	}
}

Rectangle rectangle = new Square(10);
rectangle.setHeight(5);
System.out.println(rectangle.calculateArea()); // 50 출력

 

해당 예제는 리스코프 치환 원칙을 지키지 못하고 있다. 하위 클래스는 상위 클래스의 모든 동작을 대체할 수 있어야 한다!

 

상위 클래스에 할당된 의도 파악이 중요하다. 이를 통해 하위 클래스는 상위 클래스의 의도대로 동작하도록 잘 지켜야한다. 그러나 위의 클래스의 경우 모든 동작을 대체할 수는 없다. setter 자체가 의도한대로 동작하지 않게 만드는 주범이기 때문이다. (Setter를 지우는 방법이 있을 수 있다.)

 

상위 클래스의 의도 파악 - 테스트 코드 확인

이러한 의도를 파악하기 위해서 직접 물어볼 수 있지만, 상위 클래스 작성자가 테스트 코드를 작성하여 이를 통해 파악하는 것이 이상적이다.

 

인터페이스 분리 원칙

💡 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.

 

어떤 클래스가 자신에게 필요하지 않은 인터페이스의 메서드를 구현, 의존하지 않아야 한다는 말이다. 즉, 자바의 인터페이스(interface)를 의미하기도 하지만 좀 더 넓은 범위에서 일반적인 의미의 ‘인터페이스’를 뜻하는 말이다.

 

이 원칙은 단일 책임 원칙과도 밀접하게 관련이 있다. 왜냐하면 인터페이스에 책임이 너무 많을수록 클래스가 필요하지 않은 메서드를 구현할 확률이 높아지기 때문이다.

 

통합된 인터페이스보다 세분화된 인터페이스를 만들자 - 비슷한 인터페이스를 하나로 통합해서 관리해서는 안 된다.

이러한 활동이 응집도를 높이는 것 같지만 반드시 응집도가 높아지는 결과로 이어지지는 않는다. 응집도의 종류가 다양하기 때문이다.

1. 기능적 응집도: 역할과 책임 측면에서 바라보는 응집도
2. 순차적 응집도: 특정 작업을 수행하기 위해 순차적으로 연결된 응집도
3. 통신적 응집도: 모듈 내 컴포넌트들이 같은 데이터, 정보를 공유하고 상호 작용할 때 이에 따라 모듈을 구성하는 경우의 응집도
4. 절차적 응집도: 단계별 절차를 따라 동작하도록 설계된 경우의 응집도
5. 논리적 응집도: 같은 목적 달성을 위해 논리적으로 연결된 경우의 응집도

하지만, 무조건 세분화 하는 것도 좋은 것은 아니므로 저울질을 잘해야 한다.

 

의존성 역전 원칙

💡구체화가 아닌 추상화에 의존해야 한다.

• 상위 모듈은 추상화에 의존해야 한다.
• 상위 모듈이 하위 모듈에 의존해서는 안 된다.
• 하위 모듈은 추상화를 구현해야 한다.

 

4.2 의존성

• 의존: 다른 객체나 함수를 사용하는 상태

즉, 사용하기만 해도 의존하는 것이다. 의존을 또 다른 표현으로는 결합이라고 한다. 결합이 얼마나 강하게 되어 있느냐에 따라 ‘결합도’로 평가할 수 있다. 이러한 결합도가 약할 수록 좋다.

 

의존성 주입 - 결합도를 낮추는 방법

필요한 의존성을 외부에서 넣어주는 것을 의미한다.

class HamburgerChef {

	public Food make() {
		Bread bread = new WheatBread();
		Meat meat = new Beef();
		Vegetable vegetable = new Lettuce();
		Sauce sauce = new TomatoSauce();
        
		return Hamburger.builder()
			.bread(bread)
			.meat(meat)
			.vegetable(vegetable)
			.sauce(sauce)
            .build();
	}
}

 

위의 예제에서 햄버거 셰프는 모든 재료를 본인이 생성해서 사용한다. 이러면 Bread, Meat, Vegetable, Sauce 인터페이스 뿐만 아니라 WheatBread, Beef, Lettuce, TomatoSauce 구현체까지 의존한다. 심지어는 Hamburger와 Food까지 의존하여 총 10개의 클래스 및 인터페이스에 의존하는 것이다.

// 매개변수 주입
class HamburgerChef {

	public Food make(
			Bread bread,
			Meat meat,
			Vegetable vegetable,
			Sauce sauce) {
		return Hamburger.builder()
			.bread(bread)
			.meat(meat)
			.vegetable(vegetable)
			.sauce(sauce)
			.build();
	}
}

// 생성자 주입
class HamburgerChef {

	private Bread bread;
	private Meat meat;
	private Vegetable vegetable;
	private Sauce sauce;

	public HamburgerChef(
			Bread bread,
			Meat meat,
			Vegetable vegetable,
			Sauce sauce) {
		this.bread = bread;
		this.meat = meat;
		this.vegetable = vegetable;
		this.sauce = sauce;
	}
    
	public Food make() {
    	return Hamburger.builder()
				.bread(bread)
				.meat(meat)
				.vegetable(vegetable)
				.sauce(sauce)
				.build();
	}
}

// 수정자 주입
@Setter
class HamburgerChef {

	private Bread bread;
	private Meat meat;
	private Vegetable vegetable;
	private Sauce sauce;

	public Food make() {
		return Hamburger.builder()
			.bread(bread)
			.meat(meat)
			.vegetable(vegetable)
			.sauce(sauce)
			.build();
	}
}

 

이와 같은 방법으로 외부에서 구현체를 주입받는 것을 ‘의존성 주입’이라고 하며 이를 통해 구현체에 대한 의존성을 제거할 수 있다.

 

new 연산자 사용을 자제하라

new 연산자 자체가 강한 의존성을 만든다! 위의 예제에서 이미 경험한 바 있다. 'Bread bread = new WheatBread();' 와 같은 방법은 빵이라는 추상 클래스를 사용함에도 WheatBread로 고정시킨다. 즉, 구현체에 강한 의존성을 가지게 된다.

 

의존성 역전 - 의존성 역전이 경계를 만든다.

5가지 원칙 중 가장 중요하다.

 

public class Restaurant {
	
	private HamburgerChef hamburgerChef = new HamburgerChef();
	
	public Food serve() {
		return hamburgerChef.make();
	}
}

 

Restaurant가 HamburgerChef에게 햄버거를 만들어달라는 지시를 내린다.

 

public class Restaurant {
	
	private Chef chef;
	
	public Restaurant(Chef chef) {
		this.chef = chef;
	}
	
	public Food serve() {
		return chef.make();
	}
}

 

이때, Chef 인터페이스를 만들고 기존에 존재하던 Restaurant, HamburgerChef 클래스가 인터페이스를 의존하도록 바꾸었다. 이러한 상황을 ‘의존성 역전’이라고 한다.

 

 

이를 통해 인터페이스를 중심으로 경계가 생기며 모듈의 범위를 정하고 상하 관계를 표현할 수 있다.

 

restaurant 모듈은 상위 모듈, hamburger 모듈은 하위 모듈이 되고, 상위 모듈은 하위 모듈에 의존하지 않는다.

→ 상위 모듈의 재사용성이 높아진다.

 

의존성 역전과 스프링 - 스프링은 의존성 역전을 지원하지 않는다.

의존성 역전 원칙은 설계의 영역이므로 개발자가 신경 써야 한다.

 

위와 같은 구조는 컴포넌트가 컴포넌트를 직접 호출하고 있으므로 의존성 역전이 이뤄진 것이 아니다.

 

이것이 책의 저자가 제안하는 의존성 역전 원칙을 지킨 설계 구조이다.

 

의존성이 강조되는 이유 - 의존성의 특징(의존성 전이)

소프트웨어 설계를 잘하려면 코드를 변경하거나 확장할 때 영향받는 범위를 최소화할 수 있어야 함.

→ 의존성을 잘 다뤄야 한다.

 

위 그림과 같이 C 컴포넌트를 변경하면 이를 의존하는 A, B 컴포넌트도 변경의 영향을 받는다. 이렇게 연쇄적으로 다른 컴포넌트에 영향을 주는 것을 ‘의존성이 전이된다’

→ 의존성은 화살표의 역방향으로 전이된다.

 

C 컴포넌트의 의존성 역전으로 의존성 전이를 끊을 수 있다.

 

순환 참조를 만들지마라 - 순환 참조는 사실상 같은 컴포넌트라는 선언이다

순환 참조는 의존성 전이의 영향 범위를 확장시키는 주범이다.

 

B, C 간의 순환 참조로 인해 영향 범위가 넓어졌다.

양방향 참조, 사이클을 만들지말고 오로지 단방향 참조를 만들자.

 

4.3 SOLID와 객체지향

SOLID와 객체지향은 추구하는 바가 약간 다르다.

SOLID: 객체지향 설계를 추구 - 응집도를 높이고 의존성을 낮추는 방법에 집중

객체지향: 역할, 책임, 협력을 추구