[JAVA 객체 지향 디자인 패턴] 3장 : SOLID 원칙

3.1 단일 책임 원칙 (SRP)

3.11 책임의 의미

객체 지향 설계관점에서 책임의 기본 단위는 바로 '객체'이다. (이 '객체'는 단 하나의 책임만을 가져야 한다)

 

학생 '객체'가 여러 책임(수업듣기 + 알바하기)을 가진다고 가정해보자.

public class Student {
public void getCourses() {...}
    public void addCourses() {...}
    
    public void save() {...}
    public Student load() {...}
    
    public void printOnReport() {...}
    public void printOnBook() {...}
}

학생 객체는 수업에 관한 책임만 가지는 것이 좋고 이외의 책임은 이를 더 잘 수행할 수 있는 다른 객체가 가지는 것이 좋다.

학생 -> 수업 - SRP 만족

 

3.12 변경

객체지향 설계원칙을 학습하는 이유는 뭘까?

-> 그 이유는 예측하지 못한 변경사항이 발생하더라도 유연하고 확장성이 있도록 시스템 구조를 설계하기 위해서이다.

 

좋은 설계란 무엇일까?

-> 시스템에 새로운 요구사항이나 변경이 있을 때 가능한 한 영향을 받는 부분을 줄이는 것이다.

 

객체 하나에 책임이 많아지면 클래스 내부에서 서로 다른 역할을 수행하는 코드끼리 강하게 결합되게 된다.

학생의 course()관련 메서드와 데이터베이스 관련 메서드(save, load)가 결합되어 일하는 방식이 변하면 학생이 수업을 듣는 데 영향을 미치게 될수 있다!! ㅠㅠ (강한 결합의 문제점)

회귀 테스트

어떤 변화가 있을 때 기존 시스템에 영향을 주는 지 평가하는 테스트

-> 책임을 분리하면 변경사항 발생 시 영향을 받는 부분을 줄여 '회귀 테스트' 비용을 줄일 수 있다.

3.13 책임 분리

"한 클래스에 단 하나의 책임만 수행하도록 해 변경 사유가 될 수 있는 것을 하나로 만드는 것"

책임 분리 하면 A기능이 변경되면 A기능을 직간접을 사용하는 코드만 다시 테스트할 수 있다.

개선된 학생 클래스 디자인

개선된 디자인

위의 그림처럼 학생 클래스의 책임을

1. 데이터베이스 관련 학생 DAO

2. 성적을 담당하는 성적표 클래스

3. 출석을 담당하는 출석표 클래스

이 3가지로 책임을 적절하게 분리했다.

 

이로써 학생 클랫느는 변화가 발생했을 때 파생되는 영향을 최소화할 수 있다.

예를 들어, 데이터베이스 스키마가 변경된다면 오직 학생 DAO클래스만 영향을 받고 성적표, 출석부는 영향을 받지 않을 수 있다.

3.1.4 산탄총 수술

하나의 책임이 여러 개의 클래스들로 분산되어 있는 경우라면?

산탄총 수술은 상처 부위가 많아 모든 부분을 빠짐없어 찾아 치료해야만 한다.

즉, 여러 개의 클래스에 책임이 분산되었을 때 변경이 발생한 경우이다.

 

예를 들어 로깅, 보안, 트랜잭션과 같이 횡단 관심으로 분류할 수 있는 기능들이 존재하는 것들이다.

만약 특정 메서드 실행 로그를 데이터베이스에 저장한다고 한다면 분명 메서드에는 '로그 기능'이 존재할 것이다.

이 로그를 데이터베이스에서 '파일'로 저장하고 싶다면 로그 기능이 삽입된 모든 메서드를 모두 찾아서 변경해야만 한다...,,

(하나의 책임이 여러 개의 클래스로 분리되어 있어서 생기는 문제)

 

이를 해결하기 위해서는 '부가 기능'을 별도의 클래스로 분리해 책임을 담당하게 하면 된다!!

AOP : 관심 지향 프로그래밍

횡단 코드를 Aspect라는 특별한 객체로 모듈화하고 Weaving이라는 작업을 통해 모듈화한 코드를 핵심 기능에 끼워넣는 것을 뜻한다.

이를 통해 기존의 코드를 전혀 변경하지 않아도 부가 기능을 효과적으로 변경할 수 있다. (Aspect만 변경하면 이를 사용하는 모든 위치의 기능이 바뀜)

 

3.2 개방 - 폐쇄 원칙 (OCP)

"기존의 코드를 변경하지 않으면서 기능을 확장할 수 있도록 설계되어야 한다"

 

기존 코드의 변경에는 닫혀있고 확장에는 열려있는 원칙!!

 

학생 관리 프로그램

학생 관리 프로그램에 도서관 대여 여부와 같은 새로운 매체에 학생의 대여기록을 출력하는 경우 도서관 대여 명부 클래스를 만들어 client와 연결해줘야만 한다.

 

하지만 이는 새로운 기능을 추가하기 위해 Clinet 클래스를 수정해야만 하므로 OCP에 위반 된다.

OCP 설계시 가장 중요한 것은 "무엇이 변하는 것인지, 무엇이 변하지 않는 것인지 구분하는 것" 이다.

 

위 설계를 OCP를 만족하는 설계로 수정하게 되면..

Clinet는 printable 인터페이스를 이용해 '구체적인 출력 매체'를 캡슐화 하도록 처리한다.

OCP는 클래스를 변경하지 않고도 대상 클래스의 환경을 변경할 수 있는 설계이다.

단위 테스트 = 빠른 테스트

모의 객체 = 테스트용 가짜 객체

3.3 리스코프 치환 원칙 (LSP)

"LSP는 부모 클래스와 자식 클래스 사이의 행위가 일관성이 있어야 한다는 의미이다."

LSP를 만족하면 부모 클래스의 인스턴스 대신에 자식 클래스의 인스턴스로 대체가 가능하다.

 

일반화 관계(상속)를 다시 한번 생각해보자. 일반화 관계는 'is kind of 관계'로 표현할 수 있다.

부모 클래스로 포유류, 자식 클래스를 원숭이로 가정해보자.

 

• 포유류는 알을 낳지 않고 새끼를 낳아 번식한다.
• 포유류는 젖을 먹여서 새끼를 키우고 폐를 통해 호흡한다.

위의 포유류의 특징을 원숭이도 가지고 있는가? -> 포유류를 원숭이로 바꿔서 해보자.

• 원숭이는 알을 낳지 않고 새끼를 낳아 번식한다.
• 원숭이는 젖을 먹여서 새끼를 키우고 폐를 통해 호흡한다.

전혀 문제가 없기 때문에 원숭이와 포유류의 행위(번식, 호흡, 양육)에 [일관성]이 있다고 말할 수 있다!!!!

 

그렇다면 자식 클래스가 부모 클래스의 인스턴스의 행위를 일관성있게 실행하려면 어떻게 해야할까??

명확한 방법은 바로 슈퍼 클래스에서 상속받은 메서드들이 서브 클래스에서 오버라이드(재정의)되지 않도록 하면 된다.

 

3.4 의존 역전 원칙 (DIP)

"의존 관계를 맺을 때 변화하기 쉬운 것보다는 거의 변화가 없는 것에 의존하라는 원칙이다"

어떤 객체가 의존하는 객체가 자주 변화한다면 객체의 수정이 잦아지게된다..

그렇기 때문에 객체는 변화가 적은 추상적인 객체에 의존해야한다.

 

추상적인 자동차에 의존하는 사람

위의 그림 처럼 사람이 추상적이 자동차에 의존하게 되면 실제로 BMW를 타던 벤츠를 타던 상관없이 자동차를 이용할 수 있게된다.

이러한 추상적인 것을 객체지향 관점에서는 '추상 클래스'와 '인터페이스'로 표현할 수 있다.

 

=> DIP를 만족하는 설계는 인터페이스나 추상 클래스에 의존관계를 맺게되고 이는 변화에 유연한 시스템 설계이다.

 

의존성 주입

만약 DIP를 만족하면 "의존성 주입"이라는 기술로 변화를 쉽게 수용할 수 있는 코드를 작성할 수 있다.

public class Kid{
  private Toy toy;

  public void setToy(Toy toy){
    this.toy = toy;
  }
  public int play(){
    sysout(toy.toString());  
  }
}

Kid는 장난감을 setToy()를 통해 로봇이든 자동차는 유연하게 선택할 수 있게 된다.

3.5 인터페이스 분리 원칙

인터페이스 분리 원칙(ISP)는 인터페이스를 클라이언트에 특화되도록 분리시키는 설계 원칙이다.

복합기의 클래스 다이어그램 (팩스, 프린터, 복사 클라이언트가 복합기를 사용)

복합기 기능을 제공하는 클래스는 '프린터', '복사', '팩스' 기능을 제공하지만 클라이언트가 이를 동시에 사용하지는 않는다.

클라이언트는 각 기능만을 이용하므로 '프린터' 기능만 사용할 때 '팩스' 기능의 변경이 생겼다고 영향을 받아서는 안된다.

 

즉, 클라이언트와 무관하게 발생한 변화로 클라이언트 자신이 영향을 받지 않으려면 범용의 인터페이스보다는 클라이언트에 특화된 인터페이스를 사용해야만 한다.

 

복합기 클래스에 ISP 원칙을 적용한 결과

복합기 클래스에 ISP를 적용한 예

복합기를 사용하는 객체(클라이언트)들마다 자신이 관심을 갖는 메서드들만 있는 인터페이스를 제공받도록 설계했다.

--> 이렇게 설계하면 얻는 장점 : 인터페이스가 방화벽 역할을 수행해 클라이언트는 자신이 사용하지 않는 메서드에 생긴 변화로 인한 영향을 받지 않게 된다.

 

SRP와 ISP 사이의 관계

어떤 클래스가 단일 책임이 아닌 여러 책임이 있다면 방대한 메서드를 가지기 때문에 비대한 클래스가 되고 이는 비대한 인터페이스를 제공하게 된다. 이렇게 비대한 클래스를 SRP에 따라 단일 책임 원칙을 갖는 여러 클래스들로 분할하고 각자의 인터페이스를 제공한다면 SRP와 ISP 둘다 만족시킬 수 있다.

 

그렇다면 ISP는 SRP를 만족하면 성립되는가?

위 질문에 대한 답은 "반드시 그렇다고 볼 수 없다" 이다.

 

가령 게시판의 여러 기능을 구현한 메서드에 글쓰기, 읽기, 삭제 등이 있다고 하자.
이는 게시판에 관련된 책임만 수행하므로 SRP를 만족하지만 클라이언트에 따라 (일반 사용자, 관리자 등) 기능이 달라지므로(글 삭제 권한 등) 하나의 인터페이스를 구현했다면 ISP를 위배한 설계가 되는 것이다.

 

SRP를 만족하더라도 ISP를 반드시 만족한다고 볼 수 없다