오브젝트 디자인 스타일 #1 객체지향, 서비스 생성하기

책 원문

오브젝트 디자인 스타일 가이드 - YES24

해당 책을 바탕으로 제 생각을 섞어서 정리한 글입니다. 해당 책에는 없는 내용이 추가로 있을 수 있습니다 😀

 

[ #0. 객체지향 용어 ]

해당 글에는 아래와 같은 용어들이 사용된다. 생소한 용어들이 있다면 간단하게 보고 넘어가자.

• 클래스(class)와 객체(object)
   ➡ 객체는 실제로 존재하는 사물, 개념이며 클래스는 그 객체를 사용하기 위해 코드로 정의 해 놓은 것이다.
  
  
• 상태(State) 또는 속성(property)
   ➡ 객체는 상태 값(state)과 행위(behavior), 다른 말로 속성(property)과 기능(method)으로 구성된다.
   ➡ 속성에 포함되는 것: 클래스 멤버 변수(member variable), 인스턴스 필드(filed), 특성(attribute), 상태(state)
  
  
• 변경가능(mutable), 변경불가능(immutable)
   ➡ 외부에서 메서드 결과값에 영향(side-effect)을 못끼치게 객체 속성을 불변(immutable)하게 만들 수 있다.
  
  
• 행위(behavior)와 메서드(method)
   ➡ 객체가 가진 행위이다. 메서드(method), 함수(function)
  
  
• 의존성(dependency)
   ➡ 이 객체를 사용하는데 필요한 다른 객체를 의미한다. 다른 객체에 대한 의존성(dependency)
  
  
• 상속(inheritance, extend)
   ➡ 이해하기 쉽게 상속이라는 용어를 사용했지만, 따지고 보면 객체의 확장(extends)이 정확한 의미.
  
  
• 구성(composition, is - a)
   ➡ 흔히 상속과 비교되는 말로서, 객체를 상속히지 않고 내 속성에 다른 객체를 할당하여 사용하는 방법이다. 
  
  
• 반환(return)과 예외(exception)
   ➡ 객체에 문제가 발생했을 땐 특정 예외 값을 반환(return)하거나 예외(throw)를 발생시키는게 일반적이다.
  
  
• 단위테스트(unit test)
   ➡ 객체 단위의 유닛 테스트. 한글로 번역해서 조금 어색하다. 필요한 의존성은 테스트 더블(test double)로 대체하고 준비-실행-확인 (Arragne-Act,Assert 또는 Given-When-Then)으로 실패 테스트를 하나씩 만든다.
  
  
• 테스트 더블(test double)
   ➡ 영화배우의 스턴트 더블(stunt double)에서 따온 말로, 테스트를 위해 사용되는 임시 객체를 의미한다.
   ➡ 테스트 더블 객체에는 Dummy(아무것도 안함), Stub(특정 고정 값 반환), Fake(일부만 동작), Spy(Stub + logging),     Mock(프로그래밍된 가짜 객체, 적어논 시나리오대로 동작)등이 있다.
  
  

 

---

[ #1. 객체로 프로그래밍 하기 ]

객체지향 프로그래밍의 기본을 설명한다. 이미 잘 알고있다면 바로 [ #2 ] 로 넘어가는걸 추천한다.

📌 객체는 주어진 클래스를 바탕으로 인스턴스를 생성한다.

객체의 정의. 이를 다른 말로 객체의 모델링이라고도 한다.

클래스 상속, 인터페이스, 다형성등을 활용하여 객체를 모델링하고 인스턴스를 생성하여 사용한다.

현실 세계에서 존재하는 객체의 필요한 속성, 행위를 뽑아서 모델링한다.

public class Person {
    private String name;
    private int age;
    
    public void eat() {
        System.out.println("eat");
    }
    public void sleep() {
        System.out.println("sleep");
    }
}

public class Developer extends Person { // 상속을 이용해 객체를 확장한다.
    public void coding(){
        // Developer 는 eat, sleep 말고도 coding까지 가능하다. 
        System.out.println("coding");
    }
}

#1 객체지향 프로그래밍

 

 

📌 다른 객체의 의존성은 직접 가져오거나 생성자로 주입 받아 즉시 사용한다.

class ContentWriter {
    FileReader reader;  // 파일을 읽을 수 있는 FileReader 객체의 의존성이 필요하다.

    ContentWriter() {
        this.reader = new FileReader("hello.txt");
        // 이렇게 객체 안에서 필요한 다른 객체를 만드는 방법이 가장 쉬운 방법이긴 하다.
    }

    public void print() {
        String content = reader.readAll();
        System.out.println(content);
    }
}

이를 생성자 주입으로 바꾸면 아래와 같다.

생성자 주입을 사용함으로서 [객체 설정영역]과 [서비스 로직영역]을 분리시킬 수 있고 객체간의 결합도를 낮춘다.

그 대신 의존성을 주입해주는 컨테이너 객체를 만들어야하고, 의존 관계를 찾기 번거러워지는 단점이 있다.

class ContentWriter {

    FileReader reader;

    ContentWriter(FileReader reader) {
        this.reader = reader;
    }

    public void print() {
        String content = reader.readAll();
        System.out.println(content);
    }
}

 

 

📌 상속은 부모 클래스 구현의 재정의를, 인터페이스는 역할과 추상화만 제공한다.

상속을 이용하면 클래스를 쉽게 확장할 수 있다. 그러나 가능하면 상속은 피할 수 있으면 피하는 것이 좋다.

당장은 상속으로 깔끔하게 사용할 수 있으나 요구사항이 추가되고 코드가 수정되면 부모클래스가 바뀔 수 있다.

이 수정으로 인해 부모클래스에서 문제가 없더라도, 자식 클래스에서도 똑같이 문제가 없음을 보장할 수 없다.

또는 사료를 먹지않는 동물이 있다면? [모든 메서드를 포함한 SUPER 부모 메서드]를 만든다면 무슨 문제가 생길 수 있을까?

인터페이스는 실제 구현 코드가 아닌 역할(추상화, 이름)만 제공한다. 다중 상속하더라도 별 상관없다.

그래서 객체지향의 원칙을 잘 따르기위해선, 인터페이스를 많이 활용하는 것이 좋다.

물론 '인터페이스가 바뀌거나' , '부모 객체의 정보'가 필요한 경우에도 있기 때문에 인터페이스가 만능은 아니다. 

➡ 그래서 자바에서는 인터페이스의 기본 메서드(default, private)를 제공해주는 것이다.

➡ 객체를 바로 사용하지않고, 인터페이스를 거쳐 실제 객체를 받는 작업은 추가적인 비용이 든다는걸 알고있자.

 

 

📌 다형성은 다른 객체의 메서드를 이용할 수 있다. 인스턴스에 따라 행위가 달라진다.

다형성의 핵심은 역할과 구현의 분리이다.

다형성을 고려하지않고 무작정 인터페이스로 분리하는 건, 오히려 더 안좋은 결과를 만들 수 있다.

#1 객체지향 프로그래밍

 

 

📌 객체가 자신의 속성에 다른 객체를 할당하는 것을 구성(Composition)이라 한다.

4-1 상속, 인터페이스, 클래스의 권한 최소화(+Java9 모듈)

 

 

📌 단위 테스트는 '객체' 행위를 명시하고 확인한다. 의존성은 테스트 더블로 대체하자.

참고로 테스트 더블은 영화배우의 스턴트 더블(스턴트 대역)에서 따온 말이다. 테스트용 임시 객체.

다양한 테스트와 Test Double (+Mockist)

 

 

---

[ #2. 서비스 생성하기 ]

프로그램에서 사용되는 객체는 보통 2가지로 나눌 수 있다. [데이터를 담고있는 객체]와 [작업을 수행하는 서비스 객체]

 

[서비스 객체]는 한번 생성하면 여러번 사용할 수 있다. 하지만 자신을 바꿀 수 없고 생명주기도 단순하다.

[데이터 객체]는 자신을 이용해 작업을 완료한다. 서비스가 작동할 때 사용하는 재료이며 생명 주기기 복잡하다.

📌 의존성과 설정 값을 생성자 인자를 이용해 명시적으로, 한번에 제공하자.

[설정 영역]과 [서비스 영역]을 분리하자. 때론 객체의 의존성과 함께 파일 저장 위치나 키값등을 설정값으로 갖고 있어야 하는 경우가 있다. 이러한 설정값 또한 생성자 인자로 주입받자.

class FileLogger {

    private String logFilePath;
    Formatter formatter;
    
    FileLogger(Formatter formatter, String filePath) {
        this.formatter = formatter;
        this.logFilePath = filePath; // 설정 값을 주입받아 객체의 역할을 나누자.
    }
}

* 생성자가 아닌 수정자(Setter)로 주입하면 어느시점에 주입되는지 알 수 없고, 중간에 변경될 가능성이 생긴다.

 

 

📌 짝이 있는 설정 값은 객체로 묶어서 주자.

아이디와 패스워드처럼 항상 같이 다니는 값들을 따로 주입하면 코드의 응집력이 떨어지고 부수효과를 발생시킨다.

이러한 값들은 객체에 담아서 제공하도록 하자.

@Getter
final class UserData {
// 값 객체는 상속할 일이 없다.
    private String username;
    private String password;

}

class ApiClient {
    private User user;

//  public ApiClient(String username, String password) ❌
    public ApiClient(User user) {
        this.user = user;
    }
}

 

 

📌 필요한 것의 위치(Locate)가 아니라 필요한 것 자체를 주입하라.

대부분의 복잡한 프레임워크나 라이브러리에서는 모든 서비스와 설정값을 관리하는 특별한 객체를 제공한다. 흔히 이를 서비스 위치 지정자(Service Locator), 객체 관리자(Manager), 등록자(Registry), 앱 컨테이너(Container)라고 부른다.

 

그래서 이러한 관리 객체를 사용하다보면 아래와 같은 유혹이 있을 수 있다. 아예 컨테이너 자체를 주입해버리는 방법.

class HomeController {

    private ServiceLocator locator;

    public HomeController(ServiceLocator locator) {
        this.locator = locator; // 언제든지 사용할 수 있게 컨테이너를 자체를 받는다.
    }
    
    public void function(){
        // 그리고 컨테이너를 사용해 아래와 같이 깔끔한 코드를 작성한다...?
        User user = this.locator.get(EntityManager.className)
            .getRepository(User.className)
            .getById(request.get('userId'));
        
        ...
    }
}

이 방법은 매우 좋지않다.

1. [서비스] 에서 [설정 코드]를 다뤄야 한다. 애초에 User 의존성을 가져오는 방법을 서비스 객체가 알아야 한다.

2. Side Effect 발생 ➡ 해당 서비스가 필요하지않는 다른 의존성을 가져와서 마음대로 사용할 수 있다.

3. 서비스 객체가 가진 의존성이 무엇인지 알기 어렵다. '명시적으로 의존성을 가져온다' 라는 의미를 생각해보라.

 

필요한 것의 위치(Locator, Container)를 주입하지 말고 필요한 것 자체를 주입하라. 그럼 모든 문제가 해결된다.

위치라고 적은 이유는 컨테이너뿐 아니라 모든 곳에 적용되는 말이라서 그렇다. 필요한 의존성만을 주입하라.

class ApiClient {
    private User user;
    private ResponseFactory responseFactory;

    // 의존관계를 명시적으로 알 수 있다.
    public ApiClient(User user, ResponseFactory responseFactory) {
        this.user = user;
        this.responseFactory = responseFactory;
    }
}

 

Q. 가져오려는 컨테이너(또는 객체)의 모든 기능이 필요하다면요? 짝을 지어서 전달하라면서요?

이런 경우는 잘 없다. 이는 컨테이너가 존재할 필요가 없거나 한 객체가 너무 많은 책임을 지고 있다는 의미이다.

한 객체가 너무 많은 책임을 가지고 있지 않는가? 객체의 책임을 분리해보자.

// EntityManager는 컨테이너 객체이다. 아래의 코드는 EntityManager의 모든 서비스를 사용한다.
user = this.entityManager.getRepository(...).getUser(...);
user.changePassword(newPassword);

this.entityManager.flush();

// 이런 경우에는 한 객체가 너무 많은 책임을 지고 있는 경우가 많다.
// EntityManager의 모든 기능을 한 객체가 사용할 일은 거의 없다.
user = this.entityManager.getRepository(...).getUser(...);
user.changePassword(newPassword);

this.userRepository.save(user) // flush() 책임을 다른 객체로 분리

 

 

📌 서비스는 생성 후 변경 불가능 해야한다. 메서드의 행위가 바뀌면 안된다.

• 선택적인 의존성 같은건 없다. 모든 생성자의 인자는 필수여야 한다.
• 즉 서비스 객체는 생성 후 변경 불가능(immutable)하게 만들어라.

객체를 불완전한 상태로 생성하지 마라. null을 삽입해두고 중간에 setter로 의존성을 추가하는 건 매우 위험한 행위이다.

의존성은 필요하거나, 필요하지 않거나 둘 중 하나이다. 만약 사용하지 않는다면 아무런 동작을 하지 않는 더미(dummy)객체를 사용하라. 서비스의 동작을 예측 가능하게 만들어라.

final class NullLogger implements Logger {

    public void log(String message) {
        // 아무런 동작도 하지 않는다.
    }
}

서비스는 생성 후 변경 불가능해야한다. 만약 변경되었다면 속성을 바꿔서 메서드의 행위를 바꾸는 게 아니라, 새로운 서비스 객체를 만드는 것이 맞다.

 

Q. 만약 인스턴스마다 다른 작업 데이터값을 가져야한다면?

그때는 생성자나 Setter가 아닌 메서드로 주입받는 것이 맞다.

[ 작업 관련 데이터 ] 는 의존성이 아니다. 필드로 주입한다면 모든 작업에 대해 다시 인스턴스를 만들어야 할 것이다.

final class ContractRepository{

    private Session session; // 상태 정보를 객체가 생성자 주입으로 가지고 있다.

    public ContractRepository(Session session) {
        this.session = session;
    }
    
    public List getAllContracts(){
        return this.select()
            // HTTP 세션은 요청마다 새롭게 만들어진다.
            // getAllContracts() 의 인스턴스 또한 재사용 할 수없다. 새로 만들어야 한다.
            .where([this.session.userId, this.session.companyId])
            .getResult();
    }
}

작업 관련 데이터는 아래와 같이 메서드로 주입받는 것이 맞다. 

final class ContractRepository{

    public ContractRepository() {}
     
    public List getAllContracts(String userId, String companyId){
    // 메서드로 작업 데이터의 의존성을 주입받는다.
    // 이제 이 서비스 메서드는 재사용이 가능하다.
        return this.select()
            .where([userId, companyId])
            .getResult();
    }
}

 

📌 복잡한 함수를 객체 의존성으로 바꾸어라.

때때로 의존성은 함수 안에 숨어있는 경우가 있다.

보통 json_enode() 나 simplexml_load_file() 같은 이름의 외부 라이브러리들이 이에 속하는데, 이런 함수들을 감싸 객체로 만들고, 의존성을 주입받아라.

 

서비스에 필요없는 코드를 제거하고 해당 라이브러리에서 발생하는 예외나 설정들의 책임을 분리할 수 있다. 또한 의존성을 유연하게 관리하여 서비스 코드의 수정 없이 기능을 확장할 수 있다.

final class JsonEncoder {
    public String encode(...){
        try {
            json_encode(); // 의존성이 있는 메서드
            
        } catch (RuntimeException runtimeException) {
            // 이렇게 예외를 감싸 더 자세한 정보를 제공할 수도 있다.
            throw new RuntimeException("Failed to encode data : " + data);
        }
        
    }
}

final class Hello {
    private JsonEncoder jsonEncoder;

    public Hello(JsonEncoder jsonStringEncoder) {
        this.jsonEncoder = jsonStringEncoder; // 의존성을 주입받는다.
    }
    
    public void service(){
    	this.jsonEncoder.encode(...); // 객체에게 메시지를 전달한다.
    }
}

 

물론 그렇다고 String.replace("") 같은 인라인 함수까지 모두 객체로 감싸는 변태 짓을 하라는게 아니다.

• 이 의존성으로 제공한 행위를 나중에 대체하거나 개선하고 싶은가?
• 이 의존성의 행위가 복잡해서 단지 코드 몇 줄로는 해결하기 어려운가?
• 해당 함수를 기본타입(primitive) 값 대신 객체로 처리할 수 있는가?

이에 해당한다면 객체 의존성으로 바꾸는 것이 좋다. 이렇게하면 책임을 분리할 수 있고 단위테스트하기 용이하다는 장점도 생긴다. 핵심은 책임의 분리. 즉 서비스 코드를 건드리지 않고, 설정을 변경 할 수 있다는 것이다.

* 단 시스템 호출 함수는 예외이다. 시스템 호출은 객체로 감싸지 말고 명시적으로 사용해야 사이드 이펙트를 방지할 수 있다.

 

 

📌 생성자는 속성을 할당하고, 인자의 유효성을 검사하는 일에만 사용하라.

서비스 생성은 인자를 주입하고 유효성을 확인하는 절차이다. 즉 서비스를 사용할 수 있게 준비한다는 뜻이다.

실제 작업은 해당 객체의 메서드에서 이루어져야한다. 생성자에서 작업을 하지마라.

final class FileLogger implements Logger {

    private String logFileDir;

    public FileLogger(String logFileDir) {
        this.logFileDir = logFileDir;
        
        // 디렉토리가 존재하지 않으면 해당 디렉토리를 생성한다.
        if (!is_dir(logFileDir)) {
            mkdir(logFileDir, 0777, true);
        }
        ...
    }
}

 

이렇게 생성시점에 해줘야할 작업이 있다면, 생성자를 복잡하게 만들지 말고 Factory 클래스를 사용해라.

final class FileLogger implements Logger {

    private String logFileDir;

    public FileLogger(String logFileDir) {
        this.logFileDir = logFileDir;
    }
}

final class LoggerFactory{

    public static FileLogger createFileLogger(String logFilePath) {
        if (!is_dir(logFileDir)) {
            mkdir(logFileDir, 0777, true);
        }
        ... // 설정 작업
        return fileLogger;
    }
    
}

 

만약 아래와 같이 Factory 클래스를 사용하기 애매한 경우라면 어떻게 해야할까?

아래 코드를 외부의 Factory 클래스에서 할당하기는 애매하다. 할당 순서가 바뀌게 되면 오류가 일어나기 때문이다.

final class Mailer{

    private Translator translator;
    private String defaultText;

    public Mailer(Translator translator, String locale) {
        this.translator = translator; // 반드시 translator를 먼저 할당해야한다.
        this.defaultText = this.translator.translate("default", locale)
    }
}

 

특정 순서를 지켜서 할당해야 한다면, 생성자에는 무언가 추가 작업을 하고 있다는 말이다.

 

이때는 내 코드의 설계가 잘못된게 아닌가 한번 더 고민해보자. 이 경우 위에서 말했듯이 사용자의 위치(Locale)정보는 객체의 데이터이다. 생성자로 주입 받는게 아니라 메서드 인자로 전달받는 것이 적절하다.

 

📌 인자가 유효하지 않으면 예외를 일으켜라.

사용하는 클라이언트가 객체의 인자를 확인하도록 만들지마라. 생성시점에 인자가 유효하지 않다면 특정 값을 반환하는게 아니라 InvalidArgumentException 같은 예외를 일으켜 처리를 강제하도록 만들어라.

런타임 예외가 아니라면, 언어에서 제공하는 표준 예외를 사용하는 것이 확장성이나 가독성에 좋다.