[디자인패턴의 아름다움] ch 3

3장

주제 : 설계 원칙

 

 

단일 책임 원칙

p. 118

주의할 점은 단일 책임 원칙이 설명하는 대상에는 클래스와 모듈이라는 두 가지 종류가 있다는 점이다.

 

p. 120

클래스에 private 메서드가 너무 많은 경우 이 private 메서드를 새로운 클래스로 분리하고 더 많은 클래스에서 사용할 수 있도록 public 메서드로 설정하여 코드의 재사용성을 향상시켜야 한다.

클래스의 이름을 정의하기 어려울 경우, 클래스 책임 정의가 충분히 명확하지 않음을 의미할 수 있다.

 

 

개방 폐쇄 원칙

p. 130

속성과 메서드가 추가되었기 때문에 분명히 클래스가 수정되었다고 할 수 있다. (중략) 하지만 이 변경 사항이 기존의 속성을 변경하거나 메서드를 수정하지 않았기 때문에 속성이나 메서드 입장에서 보면 확장으로 간주될 수 있다.

 

 

 

빈약한 도메인 기반의 싱글턴

p. 127

public class ApplicationContext {
    // 생략
    
    // 빈약한 도메인 기반의 싱글턴
    private static final ApplicationContext instance = new ApplicationContext();
    private ApplicationContext() {
    	initializeBeans();
    }
    
    public static ApplicationContext getInstance() {
    	return instance;
	}
}

 

1. ApplicationContext는 객체라기보다 전역 레지스트리나 서비스 로케이터의 느낌

 

이 싱글턴은 상태와 행위가 별로 없는, 그냥 객체를 담아두기 위한 컨테이너에 불과한 경우가 많다.

즉, 도메인 개념이 아닌 인프라스트럭처 개념이다.

이런 구조에서는 비지니스 규칙이 외부에 흩어지기 쉽고, 객체가 도메인의 규칙을 책임지지 않는다.

 

2. 절차지향적인 객체 사용 방식

 

ApplicationContext.getInstance().get("XXService") 같은 식으로 객체를 가져다 쓰는 구조는, 결국 전역 상태를 공유하면서 사용하는 방식이다.

이런 코드는 객체를 그냥 데이터 홀더나 유틸리티처럼 취급한다.

 

 

관련 아티클

https://tech.kakaobank.com/posts/2411-solid-truth-or-myths-for-developers/

카카오 뱅크 블로그에서 설명해주는 SOLID 원칙

 

https://dannorth.net/cupid-for-joyful-coding/

CUPID 원칙은 SOLID 원칙을 비판적으로 바라보며, 현대 소프트웨어 개발에 더 실용적이고 감성적으로 적합한 원칙들을 제안한 개념