[Clean code] Chapter 11. System

Clean Code 클린 코드 - 로버트 C. 마틴 저
를 읽고, clean code 해설 강의를 통해 제가 이해한 바를 정리한 글입니다. 

 

 

이번 장을 읽으면서 머리가 많이 복잡했다. 

아직까지도 시스템이라는건 너무 광범위하게만 느껴져서

• 온보딩 프로젝트에서 배운 3 Layer Architecture와 Dependency Injection,
• 머신러닝 코드를 리펙토링 할 때 머리싸매며 고민한 class의 적절한 사용, 디자인 패턴
• 아직도 누가 객체 지향 프로그래밍이 뭐냐고 물어보면 어버버 할 것 같은 그 객체 지향
• 확장성,
• 설계,
• ...
• 더 나아가선 MSA, 애자일까지..

실무에서 경험하긴 했지만 아직 내 안에서는 정리되지 않은 채 파편화되어 있는 개념과 경험들이 떠올랐기 때문이다. 

 

그러면서 동시에 앞으로 추구하고 싶은 커리어 방향성을 알 것 같았다. 

학생 때는 할 줄 아는 기술 스택들이 많은게 간지인 줄 알고, 유지보수나 확장성 등은 고려하지도 않은 아니고 제출 하는데만 의의를 둔 토이 프로젝트들에 기뻐하던 우물 안 개구리(나)는 요즘 실무에서 시스템, 아키텍쳐 설계가 많은 희노애락을 좌우한다는 것을 깨닫고 있다. 

그리고 완성도 높은('오 이 사람 많은 고민과 해결을 위한 노력을 했구나'라는 게 느껴질 정도) 설계를 하기 위해서는 여러 개발 및 협업 경험과 기술에 대한 깊은 이해가 필요하다고 생각한다. 

 

그래서 나는

• 비즈니스를 이해하고, 확장성 있는 시스템을 구상하고, 미팅을 이끌어 갈 수 있는 능력
• 복잡한 도메인/sustainable하고 scalable한 시스템 설계 및 운영 능력

이 있는 Backend Engineer로서 성장해 나가고 싶다. 

기반이 탄탄한 SW Backend Engineer(요즘 거의 DevOps는 포함)로 성장을 우선시 하고, 점차 Data Engieering, MLOps 등 관련 역량을 확장해 나가는 것을 희망한다. 

 

 

이처럼 여러 생각이 든 Chapter 11. System을 읽은 후 정리 해 볼 것은 

객체 지향 프로그래밍의 다형성 특징이 있는 시스템 설계의 본질을 알아보기 위해
    1) 객체 지향 프로그래밍이란
    2) 다형성 특징에 맞는 시스템 설계
    3) 역할과 구현을 분리
    4) 시작에 대한 관심사 분리

이다. 

 

각 제목은 11장. System에서 다루는 <시스템 제작과 시스템 사용을 분리하라>와 <의존성 주입>을 나름 이해한 흐름대로 정리하기 위해서 정한 것이지 각각을 깊이 다루지는 않는다. 

객제지향 프로그래밍에 대해서는 좀 더 깊은 이해가 필요하다고 생각해서 <객체 지향의 사실과 오해>를 읽으며 공부 중이다. 

조만간 해당 책도 정리해서 올리고자 한다. 

---

객체 지향 프로그래밍의 다형성을 만족하는 시스템 설계

객체 지향 프로그래밍

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉, "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다. 
• 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 

프로그램이 유연하고 변경에 용이하다는 것은 레고 블럭 조립하듯이, 컴퓨터 부품 갈아 끼우듯이 컴포넌트를 쉽게 변경하면서 개발할 수 있다는 의미이며, 객체 지향 특징 중 '다형성'이라는 특징을 가진다라고 할 수 있다. 

 

다형성 특징에 맞는 시스템 설계

다형성의 예를 운전자와 자동차의 관계로 들어보자. 

운전자 역할과 자동차 역할이 있다. 이 자동차는 K3, 아반떼, 테슬라.. 등등으로 구현될 수 있다.

이렇게 역할과 구현이 명확하게 나눠져있으면 운전자는 자동차의 역할에만 의존하고 있기때문에, 자동차의 구현된 종류가 무엇이든 운전자에게는 영향을 주지 않는다. 

또한 자동자의 종류도 얼마든지 확장이 가능해진다. 

 

이렇게 역할과 구현이 분리되어 있으면 구현된 컴포넌트가 무엇이든 쉽게 변경이 가능하고(변경하면서 개발할 수 있고), 기능 추가 등의 확장도 편리해진다. 

즉, 

• 클라이언트는 대상의 역할만 알면 된다. 
• 클라이언트는 구현 대상의 내부 구조를 몰라도 된다. 
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다. 
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다. 

 

역할과 구현을 분리

그러면 객체를 설계할 때 역할과 구현을 명확히 분리해서 설계해야하나는데, 프로그램에서의 역할은 뭐고, 구현은 뭘까?

• 역할 = 인터페이스
• 구현 = 인터페이스를 구현한 클래스, 구현 객체

즉, 객체 설계시 인터페이스(역할)를 먼저 부여하고, 그 역할을 수행하는 클래스(구현 객체)를 만들면 된다.

이런식으로 설계하고자 한다면, 

클라이언트는 역할에만 의존하고 있기때문에 (운전자의 역할이 자동차라는 역할에만 의존하고 있듯이) 역할 자체가 변하면 클라이언트 서버 모두에 큰 변경이 발생하게 된다. 그래서 처음부터 인터페이스를 안정적으로 잘 설계하는 것이 중요해진다. 

 

정리하면, 수많은 객체 클라이언트와 객체 서버가 서로 연결되어 요청/응답을 보내며 협력관계를 가지는데,  클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경 가능한 다형성의 정점을 활용하기 위해선 객체 설계시 (역할)를 먼저 부여하고, 그 역할을 수행하는 클래스(구현 객체)를 만드는 식으로 역할과 구현을 구분하는 것이 좋다.

역할과 구현의 분리 예시 다이어그램 출처: 인프런 스프링 핵심 원리 기본편

 

 

시작에 대한 관심사 분리

(생성과 사용의 분리)

소프트웨어 시스템에서는 객체의 생성과 객체를 사용하는 부분이 분리되는 것이 좋다. 

좀 더 자세히 말하면 소프트웨어 시스템은 

- 준비과정: 애플리케이션이 객체를 생성하고 의존성을 서로 연결하는 과정 과

- 런타임 로직: 준비과정 이후 이어지는 객체를 사용하는 애플리케이션 실행 시점

을 분리해야 한다. 

 

생성에 대한 관심사를 분리하면 객체의 생성은 시작 단계에서 객체의 생성을 맡기고,

객체가 잘 생성되었다고 가정하고 개발자는 비지니스 로직에서 객체를 사용해 개발하는데만 집중 할 수 있다.

FixDiscountPolicy에서 RateDiscountPolicy로 할인정책이 변경되어도 구성영역에만 영향을 받고 사용 영역은 전체 영향을 받지 않는다.&nbsp;

이렇게 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 그 참조값을 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입(DI; Dependency Injection)이라고 한다. 

 

 

지금까지 알아본 객체 지향 프로그래밍의 다형성 특징이 있는 시스템 설계의 본질을 정리해보면 아래와 같다. 

• 다형성의 본질을 이해하려면 객체 사이의 관계가 협력관계라는 것을 이해하는 것부터가 시작이다.
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다. 
• 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 할 수 있다. 

 

좋은 객체 지향 설계의 원칙

SRP, DIP, OCP

아래 Bad Case와 이를 수정한 Good Case를 보며 SRP, DIP, OCP 원칙이 Bad Case에서는 왜 지켜지지 않았고, Good Case에서는 어떻게 충족이 됐는지 확인 할 수 있다. 

Bad Case

public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    ....
}

할인 정책을 변경하려면 클라이언트인 OrderServiceImpl 코드를 수정해야한다.

public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    // private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
    ....
}

Good case

public class AppConfig {
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        ths.discountPolicy = discountPolicy;
    }
}

public class OrderApp {

    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        OrderService orderService = appConfig.orderService();

        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP
        Order order = orderService.createOrder(memberId, "itemA", 20000);

        System.out.println("order = " + order);
    }
}

1. SRP 단일 책임 원칙

Bad: 클라이언트 객체가 직접 구현 객체를 생성하고, 연결하고, 실행하는 다양한 책임을 가지고 있음

Good: 클라이언트 객체는 실행하는 책임만 담당하고, AppConfig가 구현 객체를 생성하고 연결하는 책임을 담당하도록 관심사를 분리하여 단일 책임 원칙을 따르게 함.

 

2. DIP 의존관계 역전 원칙

Bad: 새로운 객체가 적용되려면 클라이언트 코드도 함께 수정되어야 했음

Good: 클라이언트 코드를 추상화 인터페이스에만 의존하도록 수정하고, AppConfig가 사용되어야 할 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입했다.

 

3. OCP 개방 / 폐쇄 원칙

Bad: 클라이언트 코드가 변경에 닫혀있지 않고 기존 코드가 변경되어야 했음

Good: 클라이언트 코드를 추상화 인터페이스에만 의존하도록 수정하고, AppConfig가 사용되어야 할 객체(새로운 객체여도 상관 없음)를 생성해서 주입해주므로 클라이언트 코드는 변경이 필요 없다. 

 

---

AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 DI 컨테이너라고 한다. 

Java Spring은 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI하던 것을 스프링 컨테이너를 사용해서 제어의 역전(IoC), 의존관계 주입(DI; Dependency Injection)등으로 다형성을 극대화해서 이용할 수 있게 도와준다. 

 

하지만 나는 Typescript와 Python를 사용하고 있기때문에 Spring은 잘 모르지만 Typescript Nodejs와 Python Flask에서는 어떻게 DI를 활용할 수 있는지 추후에 정리해보고자 한다. 언어/프레임워크에 관계 없이 DI의 중요성을 알고, 이를 위한 패턴을 사용할 줄 아는 것이 중요하다고 생각하기 때문이다. 

 

 

 

Reference

클래스 기반으로 ExpressJS 앱 작성하기

스프링 핵심 원리 기본편 정리

Bulletproof node.js project architecture 🛡️
Express.js is great frameworks for making a node.js REST APIs however it doesn't give you any clue on how to organizing…softwareontheroad.com

파이썬에서의 의존성 주입 문제 해결

Python Dependency Injection with flask-injector