CS면접 준비로 스터디를 시작했다
7월부터 마음에 드는 공고가 나오면 팍팍 지원할 것이기 때문
이번 기회에 디자인 패턴 확실하게 정리하고 넘어가자
- SingleTon 패턴
하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴. 하나의 인스턴스를 만들어 놓고 해당 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 인스턴스를 생성할 때 드는 비용이 줄어드는 장점.
의존성이 높아지는 건 단점.
싱글톤은 TDD(Test Driven Development)를 할 때 걸림돌. TDD를 할 때는 단위 테스트를 주로 하는데, 단위 테스트는 테스트가 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 함. 하지만 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현하는 패턴이므로 각 테스트마다 독립적인 인스턴스를 만들기가 어려움.
- Factory 패턴
객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴.
팩토리 메소드 패턴, 추상 팩토리 패턴이 있다.
상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴.
상위 클래스와 하위 클래스가 분리됨. 느슨한 결합.
구체적인 레시피는 하위 클래스에 들어있고 컨베이어 벨트를 통해 전달됨.
상위 클래스인 바리스타 공장에서 이 레시피들을 토대로 식음료 제품을 생산.
- 전략 패턴= 정책 패턴
객체의 행위를 바구고 싶은 경우
직접 수정하지 않고
전략이라고 부르는 캡슐화한 알고리즘을 컨텍스트 안에서 바꿔주면서 상호 교체가 가능하게 만드는 패턴.
컨텍스트 내부 전략 A,B,C. 결제를 네이버 페이로 할지 카카오페이로 할지. 전략을 교체.
- 옵저버 패턴
주체가 어떤 객체의 상태 변화를 관찰하다가
상태 변화가 있을 때마다 메서드 등을 통해
옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴.
주체: 객체의 상태 변화를 보고 있는 관찰자.
옵저버: 이 객체의 상태 변화에 따라 전달되는 메서드 등을 기반으로 '추가 변화 사항'이 생기는 객체들을 의미.
주로 이벤트 기반 시스템에 사용.
MVC패턴에도 사용. 주체라고 볼 수 있는 모델에서 변경사항이 생겨 업데이트 메서드로 옵저버인 뷰에 알려주고 이를 기반으로 컨트롤러 등이 작동.
JS에서 옵저버 패턴은 프록시 객체를 통해 구현할 수도 있다.
cf) Proxy 객체: 어떠한 대상의 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등) 의 작업을 가로챌 수 있는 객체.
- 프록시 패턴
대상 객체에 접근하기 전
그 접근에 대한 흐름을 가로채
대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴.
- 이터레이터 패턴
이터레이터를 사용하여 컬렉션의 요소들에 접근하는 디자인 패턴.
순회할 수 있는 여러 가지 자료형의 구조와는 상관없이
이터레이터라는 하나의 인터페이스로 순회가 가능.
- 노출모듈 패턴
즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴.
- MVC패턴
모델, 뷰, 컨트롤러. 애플리케이션의 구성 요소를 세 역할로 구분. 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발 가능.
재사용성, 확장성 용이.
애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점.
- MVP패턴
모델, 뷰, 프레젠터.
뷰와 프레젠터는 일대일 관계. MVC보다 더 강한 결합.
- MVVM패턴
모델, 뷰, 뷰모델.
뷰모델은 뷰를 더 추상화한 계층.
MVVM패턴은 MVC패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징.
뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며
UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점.
1.2. 프로그래밍 패러다임
프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론.
ex. 객체지향 프로그래밍, 함수형 프로그래밍.
프로그래밍 패러다임
/ \
선언형 명령형
/ / \
함수형 객체지향형 절차지향형
-선언형 프로그래밍: 무엇을 풀어내는가에 집중하는 패러다임. "프로그램은 함수로 이루어진 것".
-함수형 프로그래밍: 작은 '순수 함수'들을 블록처럼 쌓아 로직 구현. 고차 함수를 통해 재사용성 up.
-객체지향: 객체들의 집합으로 프로그램의 상호 작용을 표현. 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용.
설계 많은 시간 소요. 처리속도 느림. 추상화, 캡슐화, 상속성, 다형성.
설계원칙 SOLID!!
안보고 써보자
1.단일 책임원칙: 1 클래스 1책임
2. 개방-폐쇄: 수정에 폐쇄
확장에 오픈
기존 코드는 잘 변경하지 않으면서도 확장은 쉽게 할 수 있어야.
3. 리스코프 치환: 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것.
클래스는 상속되고. 부모, 자식 계층. 부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가야.
4. 인터페이스 분리: 각 인터페이스 분리. 1일반 인터페이스보다 구체적인 여러개의 인터페이스를 만들어야.
5. 의존 역전: 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙.
타이어 교체 툴 만들고. 다양한 타이어를 교체할 수 있어야.
프록시 서버: 서버 앞단에 둬서 캐싱, 로깅, 데이터 분석을 서버보다 먼저 하는 서버.
포트 번호를 바꿔서 사용자가 실제 서버의 포트에 접근하지 못하게 할 수 있음.
나쁜놈의 DDOS(리소스 소진 시도)차단
CDN: Content Delivery Network 지리적으로 분산된 서버들을 연결한 네트워크
마음편히 공부만 할 수 있는 마지막 한달
파이팅하자
'면접준비' 카테고리의 다른 글
[면접을 위한 CS 전공지식노트] 네트워크 (0) | 2024.07.07 |
---|---|
[면접 대비] 프론트엔드 개발자로서의 기술 질문 (0) | 2023.09.20 |
토익 단어 공부 - 파고다 토익 보카 (0) | 2023.03.12 |
Vegetable Shortage (0) | 2023.02.24 |