디자인 패턴, 프로그래밍 패러다임

 

참고

면접을 위한 CS 전공지식 노트: https://www.gilbut.co.kr/book/view?bookcode=BN003386

 

디자인 패턴, Design Pattern

프로그램을 설계할 때 발생하는 특정 문제점을 해결하기 위한 특정 패턴

 

싱글톤 패턴, Singleton Pattern

하나의 클래스는 하나의 인스턴스만 가지는 패턴
하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반한 로직을 만들 때 사용

하나의 인스턴스를 다른 모듈들이 공유해 사용하기 때문에 인스턴스 생성 비용이 줄어들지만 의존성이 높아짐

 

싱글톤 패턴 단점
TDD에서 사용하기 어려움
TDD는 단위 테스트를 진행하는 데, 단위 테스트는 각자 독립적이어야 한다.
하지만 싱글톤 패턴은 하나의 인스턴스를 가지므로 각 테스트마다 독립적인 인스턴스를 만들기 어려움

 

의존성 주입
싱글톤 패턴은 사용하기 쉽고, 실용적이지만 모듈 간의 결합을 강하게 만듦
이때 의존성 주입을 통해 모듈 간의 결합을 느슨하게 만들어 해결할 수 있다.

 

의존성 주입 장점
모듈을 쉽게 교체할 수 있는 구조가 되어 테스트 용이, 마이그레이션 수월
구현 시 추상화를 통해 구현체를 주입하기 때문에 애플리케이션 의존성 방향 일관, 애플리케이션 추론 용이, 모듈 간 관계 명확

 

의존성 주입 단점
모듈이 분리되므로 클래스 수 증가 및 그로 인해 복잡성 증가, 런타임 페널티 발생

 

의존성 주입 원칙
상위 모듈은 하위 모듈에 의존하지 않아야 한다. 또한, 상위 모듈과 하위 모듈 둘 다 추상화에 의존해야 하며, 추상화는 세부 사항에 의존하면 안 된다.

 

팩토리 패턴, Factory Pattern

객체를 사용하는 코드에서 객체 생성 부분을 추상화한 패턴
상속 관계에 있는 두 클래스에서 상위 클래스가 중요 요소를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정

상위 클래스와 하위 클래스가 분리되기 때문에 결합이 느슨해지며, 상위 클래스는 인스턴스 생성 방식을 알 필요 없기 때문에 더 많은 유연성이 생김
객체 생성 로직이 분리되어 있기 때문에 한 부분만 리팩터링 하면 되니 유지 보수성 증가

 

전략 패턴, Strategy Pattern

객체의 행위를 바꿀 때, 직접 수정하지 않고 전략이라 불리는 캡슐화한 알고리즘을 바꿔주면서 상호 교체가 가능하게 만드는 패턴. 정책 패턴(Policy Pattern)이라고도 함

 

옵저버 패턴, Observer Pattern

주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때, 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 패턴

이벤트 기반 시스템에 주로 사용하며 MVC 패턴에도 사용

 

프록시 패턴, Proxy Pattern

대상 객체에 접근하기 전에 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
객체의 속성, 변환 등을 보완

 

프록시 서버, Proxy Server

서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 접속할 수 있게 해주는 응용 프로그램 혹은 컴퓨터 시스템

 

이터레이터 패턴, Iterator Pattern

이터레이터를 사용하여 컬렉션의 요소에 접근하는 디자인 패턴
여러 가지 자료형의 구조와 상관없이 이터레이터라는 하나의 인터페이스로 순회 가능

 

노출 모듈 패턴, Revealing Module Pattern

즉시 실행 함수를 통해 접근 제어자를 만드는 패턴
접근 제어자가 존재하지 않을 때, 노출 모듈 패턴을 통해 접근 제어자 구현

 

MVC 패턴, MVC Pattern

모델, 뷰, 컨트롤러로 이루어진 패턴. 애플리케이션의 구성 요소를 세 가지 역할로 구분

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

 

모델
애플리케이션의 데이터인 데이터베이스, 상수, 변수 등
뷰에서 데이터를 생성, 수정하면 컨트롤러를 통해 모델을 생성, 갱신

 

뷰
사용자 인터페이스 요소를 뜻함. 즉, 모델을 기반으로 사용자가 볼 수 있는 화면
모델이 가지고 있는 정보를 저장하지 않고, 사용자 인터페이스에 대한 정보만 가지고 있어야 함
또한, 변경 발생 시 컨트롤러에 전달해야 한다

 

컨트롤러
하나 이상의 모델과 하나 이상의 뷰를 잇는 다리. 이벤트 등의 메인 로직을 담당
모델과 뷰의 생명주기 관리, 모델과 뷰의 변경에 대한 처리 담당

 

MVP 패턴, MVP Pattern

MVC 패턴에서 파생된, MVC의 컨트롤러가 프레젠터로 교체된 패턴
뷰와 프레젠터는 1:1 관계로 MVC 패턴보다 더 강한 결합을 지닌 패턴

 

MVVM 패턴, MVVM Pattern

MVC 패턴에서 파생된, MVC의 컨트롤러가 뷰 모델로 교체된 패턴

 

뷰모델
뷰를 한층 더 추상화한 계층. MVC 패턴과 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징
뷰와 뷰 모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없는 재사용, 단위 테스팅이 용이하다는 장점 보유

 

프로그래밍 패러다임

프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론

크게 선언형과 명령형으로 나뉨
선언형은 함수형으로 나뉨
명령형은 객체지향, 절차지향으로 나뉨

 

선언형과 함수형 프로그래밍

선언형 프로그래밍(declarative programming)이란 무엇을 풀어내는가에 집중하는 패러다임
"프로그램은 함수로 이루어진 것"이라는 명제가 담긴 패러다임

함수형 프로그래밍(functional programming)은 선언형 프로그래밍 패러다임의 일종
순수 함수들의 조합으로 로직을 구현하고, 고차 함수를 통해 재사용성을 높인 패러다임

 

순수 함수
출력이 입력에만 의존하는 함수

 

고차 함수
함수를 매개변수로 받아 로직을 생성할 수 있는 함수

 

일급 객체
고차 함수를 사용하기 위해 언어가 지녀야 하는 전제 조건

변수나 메서드에 함수를 할당할 수 있어야 하고, 함수 안에 함수를 매개 변수로 사용할 수 있으며, 함수가 함수를 반환할 수 있어야 한다.

 

객체지향 프로그래밍, OOP, Object Oriented Programming

객체들의 집합으로 프로그램의 상호 작용을 표현하며, 데이터를 객체 취급하여 객체 내부에 선언된 메서드를 활용하는 패러다임
설계에 많은 시간이 소요되며, 다른 패러다임에 비해 상대적으로 느림

 

객체지향 프로그래밍 특징
추상화, 캡슐화, 상속성, 다형성을 지님

 

추상화, Abstraction
복잡한 시스템에서 핵심 개념 또는 기능을 간추려낸 것

 

캡슐화, Encapsulation
객체의 속성과 메서드를 하나로 묶고, 일부를 외부에 감춰 은닉하는 것

 

상속성, Inheritance
상위 클래스의 특성을 하위 클래스가 상속받아 재사용하거나 추가 혹은 확장하는 것

 

다형성, Polymorphism
하나의 메서드나 클래스가 다양한 방법으로 동작하는 것. 오버로딩과 오버라이딩이 대표적

 

오버로딩, Overloading
같은 이름을 가진 메서드를 여러 개 두는 것. 메서드 타입, 매개변수 타입, 매개변수 개수 등이 있으며 컴파일 타임에 발생하는 정적 다형성

 

오버라이딩, Overriding
주로 메서드 오버라이딩을 의미. 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것. 런타임 타임에 발생하는 동적 다형성

 

단일 책임 원칙, SRP, Single Responsibility Principle
모든 클래스는 각각 하나의 책임만 가져야 한다
어떤 로직 A가 존재할 때, 어떤 한 클래스는 A에 관한 클래스여야 하며, 이를 수정해도 A와 관련된 수정이어야 한다

 

개방 폐쇄 원칙, OCP, Open Closed Principle
코드는 확장에는 열려있고, 수정에는 닫혀 있어야 한다
기존의 코드를 자주 변경하지 않으면서도 확장은 쉽게 가능해야 한다

 

리스코프 치환 원칙, LSP, Liskov Substitution Principle
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 한다
하위 계층을 상위 계층에 대입해도 문제가 없어야 한다

 

인터페이스 분리 원칙, ISP, Interface Segregation Principle
하나의 일반적인 인터페이스 대신 구체적인 여러 개의 인터페이스를 만들어야 한다

 

의존 역전 원칙, DIP, Dependency Inversion Principle
상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립되어야 한다

 

절차형 프로그래밍

로직이 수행되어야 할 연속적인 계산 과정으로 이루어진 패러다임
코드의 가독성이 좋고, 실행 속도가 빠르다는 장점과 모듈화가 어렵고 유지 보수성이 떨어진다는 단점 존재