CHAPTER 1 - 디자인 패턴과 프로그래밍 패러다임

라이브러리: 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것
ex) numpy(수학 연산), pandas(데이터 처리), React(UI 라이브러리)

프레임워크: 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것
ex)Django(웹 개발), Spring(자바 웹 개발), React(UI 라이브러리지만 프레임워크처럼 사용 가능)

Section 1.1 디자인 패턴

디자인 패턴이란?
프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 '규약' 형태로 만들어 놓은 것이다.

1.1.1 싱글톤 패턴

하나의 클래스에 오직 하나의 인스턴스를 가지는 패턴이다.
싱글톤 패턴은 꼭 클래스를 기반으로 구현해야 하는 것은 아니며, 단 하나의 객체만 존재하도록 보장하는 것이 핵심이다.

• 인스턴스: 클래스를 기반으로 만들어진 실제 객체

# 클래스 정의
class Dog:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def bark(self):
        return f"{self.name}가 멍멍 짖어요!"

# 인스턴스 생성
dog1 = Dog("멍멍이", 3)  # dog1은 Dog 클래스의 인스턴스
dog2 = Dog("바둑이", 5)  # dog2도 Dog 클래스의 또 다른 인스턴스

# 인스턴스 사용
print(dog1.bark())  # 멍멍이가 멍멍 짖어요!
print(dog2.bark())  # 바둑이가 멍멍 짖어요!

• 싱글톤 패턴의 장점: 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점이 있다.

• 싱글톤 패턴의 단점: 의존성이 높아진다.

< 자바 스크립트의 싱글톤 패턴 >
예시부터 들어보면,

class Singleton {
    constructor() {
        if (!Singleton.instance) {
            Singleton.instance = this
        }
        return Singleton.instance
        getInstance() {
            return this
        }
const a = new Singleton()
const b = new Singleton()
console.log(a === b) // true

위의 코드는 Singleton.instance라는 하나의 인스턴스를 가지는 Singleton 클래스를 구현한 모습이다.
이를 통해 a와 b는 하나의 인스턴스를 가진다.

< 데이터베이스 연결 모듈 >

const URL = 'mongodb://localhost:27017/kundolapp' // MongoDB에 연결할 DB URL을 변수 URL에 저장, 로컬에서 실행 중인 MongoDB 서버의 kundolapp 데이터베이스를 가리킨다.
const createConnection = url => ({"url" : url}) // 자바스크립트에서 객체는 키와 값으리 쌍으로 구성된 데이터 구조이고, {"키":값} 형태로 표현한다. 다음은 화살표 함수를 사용하여 객체 리터럴을 반환하는 코드이다.
class DB {
    constructor(url) {
        if (!DB.instance) {
            DB.instance = createConnection(url)
        }
        return DB.instance
    }
    connect() {
        return this.instance
    }
}
const a = new DB(URL)
const b = new DB(URL)
console.log(a === b) // true

< 자바에서의 싱글톤 패턴 >
자바로는 다음과 같이 중첩 클래스를 이용해서 만드는 방법이 가장 대중적이다.

class Singleton {
    private static class singleInstanceHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

public class HelloWorld {
     public static void main(String[] args) {
        Singleton a = Singleton.getInstance();
        Singleton b = Singleton.getInstance();
        System.out.println(a.hashCode());
        System.out.println(b.hashCode());
        if (a == b) {
         System.out.println(true);
        }
     }
}
/*
705927765
705927765
true
*/

< mongoose의 싱글톤 패턴 >

Mongoose.prototype.connect = function(uri, options, callback) {
    const _mongoose = this instanceof Mongoose ? this : mongoose;
    const conn = _mongoose.connection;
    return _mongoose._promiseOrCallback(callback, cb => {
         conn.openUri(uri, options, err => {
             if (err != null) {
                 return cb(err);
             }
             return cb(null, _mongoose);
         });
     });
});

< MySQL의 싱글톤 패턴 >
Node.js에서 MySQL 데이터베이스를 연결할 때도 싱글톤 패턴이 쓰인다.
앞의 코드처럼 메인 모듈에서 데이터베이스 연결에 관한 인스턴스를 정의하고 다른 모듈인 A 또는 B에서 해당 인스턴스를 기반으로 쿼리를 보내는 형식으로 쓰인다.

// 메인 모듈
const mysql = require('mysql');
const pool = mysql.createPool({
    connectionLimit: 10,
    host: 'example.org',
    user: 'kundol',
    password: 'secret',
    database: '승철이디비'
});
pool.connect();

// 모듈 A
pool.query(query, function (error, results, fields) {
    if (error) throw error;
    console.log('The solution is: ', results[0].solution);
});

// 모듈 B
pool.query(query, funtion (error, results, fields) {
    if (error) throw error;
    console.log('The solution is: ', results[0].solution);
});

< 싱글톤 패턴의 단점 >
싱글톤 패턴은 TDD(Test Driven Development)를 할 때 걸림돌이 된다.
TDD를 할 때 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 한다.

• TDD란?
  테스트 주도 개발로, 테스트를 먼저 작성한 후 코드 구현을 진행하는 개발 방식이다.
  일반적인 개발 방식과는 반대로, 테스트 코드를 먼저 작성하고, 그 테스트를 통과하는 최소한의 기능을 구현하면서 개발을 진행하는 방식이다.

하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 '독립적인' 인스턴스를 만들기가 어렵다.

< 의존성 주입 >
싱글톤 패턴은 사용하기가 쉽고 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있다는 단점이 있다.
이때 의존성 주입(DI, Dependency Injection)을 통해 모듈 간의 결합을 조금 더 느슨하게 만들어 해결할 수 있다.

참고로 의존성이란 종속성이라고도 하며 A가 B에 의존성이 있다는 것은 B의 변경 사항에 대해 A 또한 변해야 된다는 것을 의미한다.

앞의 그림처럼 메인 모듈이 '직접' 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자가 이 부분을 가로채 메인 모듈이 '간접'적으로 의존성을 주입하는 방식이다.

이를 통해 메인 모듈(상위 모듈)은 하위 모듈에 대한 의존성이 떨어지게 된다.
이를 '디커플링이 된다'고도 한다.

+ 의존성 주입의 장점
모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션하기도 수월하다.
구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수 있으며, 모듈 간의 관계들이 조금 더 명확해진다.

+ 의존성 주입의 단점
모듈들이 더욱 더 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있으며 약간의 런타임 페널티가 생기기도 한다.

+ 의존성 주입 원칙
의존성 주입은 "상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다. 또한, 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 합니다." 라는 의존성 주입 원칙을 지켜주면서 만들어야 한다.

1.1.2 팩토리 패턴

팩토리 패턴(factory pattern)은 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴이다.

상위 클래스와 하위 클래스가 분리되기 때문에 느슨한 결합을 가지며 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문에 더 많은 유연성을 갖게 된다.
그리고 객체 생성 로직이 따로 떼어져 있기 때문에 코드를 리팩터링하더라도 한 곳만 고칠 수 있게 되니 유지 보수성이 증가한다.

< 자바스크립트의 팩토리 패턴 >
자바스크립트에서 팩토리 패턴을 구현한다면 new Object()로 구현할 수 있다.

const num = new Object(42)
const str = new Object('abc')
num.constructor.name; // Number
str.constructor.name; // String

전달받은 값에 따라 다른 객체를 생성하며 인스턴스의 타입 등을 정한다.

1.1.3 전략 패턴

전략 패턴(strategy pattern)은 정책 패턴(policy pattern)이라고도 한다.
객체의 행위를 바꾸고 싶은 경우 '직접' 수정하지 않고 전략이라고 부르는 '캡슐화한 알고리즘'을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴이다.

1.1.4 옵저버 패턴

옵저버 패턴(observer pattern)은 주체가 어떤 객체(subject)의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴이다.

여기서 주체란 객체의 상태 변화를 보고 있는 관찰자이며, 옵저버들이란 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들을 의미한다.

또한, 앞의 그림처럼 주체와 객체를 따로 두지 않고 상태가 변경되는 객체를 기반으로 구축하기도 한다.

옵저버 패턴을 활용한 서비스로는 트위터가 있다.

옵저버 패턴은 주로 이벤트 기반 시스템에 사용하며 MVC(Model-View-Controller) 패턴에도 사용된다.

예를 들어 주체라고 볼 수 있는 모델(model)에서 변경 사항이 생겨 update() 메서드로 옵저버인 뷰에 알려주고 이를 기반으로 컨트롤러 등이 작동하는 것이다.

1.1.5 프록시 패턴과 프록시 서버

< 프록시 패턴 >
대상 객체(subject)에 접근하기 전 그 접근에 대한 흐름을 가로채 해당 접근을 필터링하거나 수정하는 등의 역할을 하는 계층이 있는 디자인 패턴이다.

이를 통해 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용한다.
이는 앞서 설명한 프록시 객체로 쓰이기도 하지만 프록시 서버로도 활용된다.

< 프록시 서버 >
프록시 서버(proxy server)는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램이다.

프록시 서버로 쓰는 nginx와 CloudFlare가 있다.

1.1.6 이터레이터 패턴

이터레이터 패턴(iterator pattern)은 이터레이터(iterator)를 사용하여 컬렉션(collection)의 요소들에 접근하는 디자인 패턴이다.

1.1.7 노출모듈 패턴

노출모듈 패턴(revealing module pattern)은 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴을 말한다.

1.1.8 MVC 패턴

MVC 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴이다.

재사용성과 확장성이 용이하다는 장점이 있고, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.

< 모델 >
애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻한다.

< 뷰 >
inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타내며, 모델을 기반으로 사용자가 볼 수 있는 화면을 뜻한다.

< 컨트롤러 >
하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며 이벤트 등 메인 로직을 담당한다.

1.1.9 MVP 패턴

MVP 패턴은 MVC 패턴으로부터 파생되었으며 MVC에서 C에 해당하는 컨트롤러가 프레젠터(presenter)로 교체된 패턴이다.

뷰와 프레젠터는 일대일 관계이기 때문에 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴이다.

1.1.10 MVVM 패턴

MVVM 패턴은 MVC의 C에 해당하는 컨트롤러가 뷰모델(view model)로 바뀐 패턴이다.

여기서 뷰모델은 뷰를 더 추상화한 계층이며, MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징이다.