[1] 디자인 패턴과 프로그래밍 패러다임
면접을 위한 CS 전공지식 노트 CHAPTER 1
SECTION 1.1 디자인 패턴
📌 디자인 패턴 정의
프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 ‘규약’ 형태로 만들어 놓은 것
📌 디자인 패턴 종류(목적에 따른 분류)
| 생성 패턴 | Builder, Prototype, Factory, Singleton |
| 구조 패턴 | Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter |
| 행위 패턴 | Template Method, Command, Observer, State, Strategy, Mediator, Interpreter, Iterator, Visitor, Memento, Chain of Responsibility |
1.1.1 싱글톤 패턴(생성 패턴)
- 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
- 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용
- 보통 데이터베이스 연결 모듈에 많이 사용함
장점: 사용하기 쉬움, 실용적, 인스턴스 생성할 때 드는 비용이 줄어듦
단점: 의존성이 높아짐, TDD 할 때 단위 테스트에서 걸림돌 됨
싱글톤 패턴 코드
데이터베이스 연결 모듈 코드
의존성 주입
1.1.2 팩토리 패턴(생성 패턴)
- 객체 생성 부분을 떼어내 추상화한 패턴
- 상위 클래스가 중요한 뼈대를 결정, 하위 클래스에서 객체 생성에 관한 구체적인 내용 결정
- 느슨한 결합, 유연성, 유지 보수성 증가
팩토리 패턴 코드
CoffeFactory: 상위 클래스(중요한 뼈대 결정) / LatteFactory: 하위 클래스(구체적인 내용)
의존성 주입: LatteFactory에서 생성한 인스턴스를 CoffeeFactory에 주입
1.1.3 전략 패턴(행위 패턴)
- 객체의 행위를 바꾸고 싶은 경우 전략이라고 부르는 ‘캡슐화 알고리즘’을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만듦
- 컨텍스트: 상황, 맥락, 문맥 / 어떠한 작업을 완료하는 데 필요한 모든 관련 정보
- 페이나 인증 구현할 때 많이 사용
1.1.4 옵저버 패턴(행위 패턴)
- 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려줌
- 주체: 객체의 상태 변화를 보고 있는 관찰자 / 옵저버: 추가 변화 사항이 생기는 객체들
- ref나 reactive로 정의할 때 DOM 값이 변경 되는 것
트위터 예시
주체가 포스팅 올리면 새로운 트윗을 옵저버들에게 알림
MVC 패턴
Model에서 변경 사항이 생기면 옵저버인 View에 알려주고 이를 기반으로 Controller가 작동
옵저버 패턴 코드
1.1.5 프록시 패턴(구조 패턴)
- 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 함
- 보안, 데이터 검증, 캐싱, 로깅
CORS
1.1.6 이터레이터 패턴(구조 패턴)
- 이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴
= 순회할 수 있는 여러 가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로 순회 가능
1.1.7 노출모듈 패턴
- 즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴
- js는 접근 제어자가 없기 때문에 이 패턴으로 접근 제어자를 구현함
노출모듈 패턴 코드
a, b는 private / c, d는 public
- public: 클래스에 정의된 함수에서 접근 가능/자식 클래스와 외부 클래스에서도 접근 가능
- private: 클래스에 정의된 함수에서 접근 가능/자식 클래스와 외부 클래스에서는 접근 불가능
1.1.8 MVC 패턴
- 모델(Model), 뷰(View), 컨트롤러(Controller)
- 각각의 구성 요소에만 집중해서 개발 가능
장점: 재사용성, 확장성 용이
단점: 앱이 복잡해질수록 모델과 뷰 관계가 복잡해짐
구성요소 세가지
1.1.9 MVP 패턴
- MVC 패턴으로 부터 파생
- 모델(Model), 뷰(View), 프리젠터(Presenter)
- 뷰와 프리젠터는 일대일 관계, 더 강한 결합
1.1.10 MVVM 패턴
- MVC 패턴으로 부터 파생
- 모델(Model), 뷰(View), 뷰모델(View Model)
- 뷰모델: 뷰를 더 추상화한 계층
- 커맨드와 데이터 바인딩을 가짐
- 양방향 데이터 바인딩은 UI를 별도의 코드 수정 없이 재사용 가능, 단위 테스팅 쉬움
3. MVC 패턴 구성요소 중 다리 역할을 하며변경 통지를 받으면 이를 해석하여 각각의 구성요소에 전달하는 요소는?
정답 보기
컨트롤러SECTION 1.2 프로그래밍 패러다임
📌 프로그래밍 패러다임 정의
- 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론
- 객체지향: 프로그램을 객체들의 집합으로 봄
- 함수형: 프로그램을 함수 값들의 연속으로 봄
분류
1.2.1 선언형과 함수형 프로그래밍
- ‘무엇을’ 풀어내는가에 집중
- ‘프로그램은 함수로 이루어진 것이다’
- ‘순수 함수’들을 블록처럼 쌓아 로직을 구현하고, ‘고차 함수’를 통해 재사용성을 높인 프로그래밍
- Javascript, Python 등
순수함수
출력이 입력에만 의존
const pure = (a, b) => {
return a + b;
};
고차 함수
- 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것
- 해당 언어가 일급 객체여야함
- 변수나 메서드에 함수 할당 가능
- 함수 안에 함수를 매개변수로 담는 것 가능(콜백 함수)
- 함수가 함수 반환 가능
1.2.2 객체지향 프로그래밍
- 데이터를 객체로 취급, 객체 내부에 선언된 메서드를 활용하는 방식
- 설계에 많은 시간 소요, 처리 속도 느림
특징 4가지
-
추상화
복잡한 시스템으로부터 핵심적인 개념 또는 기능을 간추려내는 것 -
캡슐화
객체의 속성과 메서드를 하나로 묶고 일부를 외부에 감추어 은닉하는 것 -
상속성
상위 클래스의 특성을 하위 클래스가 이어받아서 재사용, 추가, 확장하는 것 -
다형성
하나의 메서드나 클래스가 다양한 방법으로 동작하는 것
- 오버로딩: 같은 이름을 가진 메서드를 여러개 두는 것(매개변수로 식별 가능)
- 오버라이딩: 상위 클래스로부터 상속받은 메서드를 하위 클래스가 재정의하는 것(자식꺼로 됨)
설계 원칙(SOLID)
1)SRP(Single Responsibility Principle): 단일 책임 원칙
모든 클래스는 각각 하나의 책임만 가져야 하는 원칙
-
OCP(Open Close Prinsiple): 개방-폐쇄 원칙
유지 보수 때는 쉽게 확장, 수정할 때는 닫쳐있어야 하는 원칙 -
LSP(Liskov Substitution Principle): 리스코프 치환 원칙
객체 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것 -
ISP(Interface Segregation Principle): 인터페이스 분리 원칙
하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙 -
DIP(Dependency Inversion Principle): 의존 역전 원칙
변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙
1.2.3 절차형 프로그래밍
- 연속적인 계산 과정
- 장점: 가독성 좋음, 실행 속도 빠름
- 단점: 모듈화 어려움, 유지 보수성 떨어짐
1.2.4 패러다임의 혼합
- 비즈니스 로직이나 서비스의 특징을 고려해서 패러다임을 정하는 것이 좋음
- 패러다임 간의 장점만 취해 개발하는 것이 좋음
퀴즈
1. 상위 클래스가 중요한 뼈대를 결정하고 하위 클래스에서 객체 생성에 관한 구체적인 내용 결정하는 패턴은?
정답 보기
팩토리 패턴2. 다음 코드에서 public한 변수와 private한 변수를 구분하시오.
const pukuba = (() => {
const a = 1;
const b = () => 2;
const public = {
c: 2,
d: () => 3,
};
return public;
})();
댓글남기기