개발자면접을 위한 CS전공지식 | CS면접 - 디자인패턴

디자인패턴

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

 

#_라이브러리와 프레임워크의 차이

라이브러리 : 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것, 프레임워크에 비해 자유로우며 컨트롤주체는 '내'가 됨

프레임워크 : 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것, 라이브러리에 비해 엄격하며 컨트롤주체는 '도구'가 됨

 

#_싱글톤패턴(singleton pattern) : 하나의 클래스에 오직 하나의 인스턴스만 가짐, 일반적으로 DB연결 모듈에 사용, 인스턴스 생성시 비용 감소, 의존성이 높아짐 /  미리 생성된 하나의 인스턴스 기반으로 독립적인 인스턴스 생성이 어려워 TDD(Test Driven Development)의 독립적인 단위테스트에 적합 x

#_의존성 주입(DI, Dependency Injection) : 메인모듈과 하위모듈사이에 의존성 주입자가  존재함으로써 메인 모듈이 '간접'적으로 의존성을 주입하는 방식, 의존성저하, 서비스를 사용하려는 수신객체(클라이언트)가 해당 서비스의 구성방법을 알 필요가 없게 하는 것, 런타임에 종속성 해결, 프레임워크가 아닌 디자인패턴

  장점 : 모듈 교체 용이 -> 테스팅ㆍ마이그레이션 수월, 통일된 의존성 방향, 모듈간 관계 명확

  단점 : 분리된 모듈들의 클래스 수 증가로 복잡성 증가, 런터임 패널티 발생

 

#_옵저버패턴(observer pattern) : 주체(상태변화를 보는 관찰자)가 어떤 객체(subject)의 상태변화가 생길 때 메서드 등을 통해 옵저버 목록에 있는 옵저버(객체의 상태변화에 따라 전달되는 메서드 등을 기반으로 '추가변화사항'이 생기는 객체들)들에게 변화를 알려주는 디자인패턴, 주체와 객체를 따로 두지않고 변경되는 객체를 기반으로 구축하기도 함, 이벤트 기반 시스템에 사용, MVC패턴에 사용

자바 : 상속(추가 및 확장, 재사용성과 중복성의 최소화 / 일반클래스, abstract 클래스 기반 구현)과 구현(메서드 재정의 필수 / 인터페이스 기반 구현)

 

#_프록시패턴 : 대상객체(subject)에 접근 전 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴, 객체의 속성ㆍ변환 등을 보완, 보안ㆍ데이터검증ㆍ캐싱ㆍ로깅에 사용

ex) 프록시 서버(proxy server) : 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른네트워크 서비스에 간접적으로 접속가능하도록하는 컴퓨터시스템이나 응용 프로그램

CloudFlare : 전 세계적으로 분산된 서버를 통해 시스템의 컨텐츠 전달을 빠르게 할 수 있는 CDN 서비스, 웹사이트 접속시 CloudFlare(프록시 서버로 사용)를 통해 보호

CORS(Cross-Origin Resource Sharing) : 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP헤더 기반 메커니즘

* 오리진 : 프로토콜과 호스트 이름, 포트의 조합 http://kundol.com:12010/test 의 밑줄이 오리진

프록시 서버의 역할

 

#_MVC 패턴 : 모델(Model)-뷰(View)-컨트롤러(Controller)로 이루어진 디자인 패턴, 개발 프로세스에서 구성요소를 세가지로 구분하여 각각의 구성요소에만 집중한 개발 가능, 재사용성ㆍ확장성 용이, 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해짐

모델(model) : 애플리케이션의 데이터인 데이터베이스, 상수, 변수 / 데이터에 관한 정보 보유, 뷰에서 데이터를 생성 및 수정시 컨트롤러를 통해 모델 생성ㆍ갱신

뷰(view) : inputbox, checkbox, textarea 등 사용자 인터페이스 요소로 모델을 기반으로 사용자가 볼 수 있는 화면, 모델이 가진 정보를 별도 저장하지않고 화면에 표시하는 정보만 가짐, 변경발생시 컨트롤러에 전달

컬트롤러(controller) : 하나 이상의 모델과 하나 이상의 뷰를 잇는 역할(일대다, 다대일), 이벤트 등 메인 로직 담당, 모델과 뷰의 생명주기 관리, 모델이나 뷰의 변경 발생시 해석 및 전달 ex) 데이터 aggregate, 액션에 대한 validate검사, 데이터 캐싱

 

#_MVP 패턴 : MVC의 컨트롤러가 프레젠터(presenter)로 교체된 패턴, 뷰와 프레젠터는 일대일 관계로 MVC패턴보다 강한 결합을 지닌 디자인패턴

 

#_MVVM 패턴 : MVC의 컨트롤러가 뷰모델(view model, 뷰를 더 추상화한 계층)로 바뀐 패턴, MVC패턴과 다르게 커맨드와 데이터 바인딩을 가짐, 뷰와 뷰모델 사이의 양방향 데이터 바인딩 지원, 별도 코드수정없이 UI 재사용 가능, 단위테스팅 용이 ex) 뷰, 안드로이드

커맨드 : 여러가지 요소에 대한 처리를 하나의 액션으로 처리가능하게 하는 기법, V에 입력이 들어오면 '커맨드 패턴'으로 VM에 명령 요청을 객체의 형태로 캡슐화하여 작업수행 및 트리거할 수 있도록 하는 패턴, command, receiver, invoker, client로 이루어짐

데이터바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법, 뷰모델 변경시 뷰 변경

디자인패턴의 목표 : 애플리케이션에 대한 시각화, 데이터 처리 등의 관리 책임 분리

	MVC	MVP (모델 뷰 발표자)	MVVN (모델 뷰 뷰모델)
V vs C(P, VM)	1 : N	1 : 1	1 : N
V의 C(P, VM)에 대한 참조	참조x	참조o	참조o
단위테스트 난이도	보통	어려움 (의존성이 커서)	가장 쉬움
Android API에 대한 의존도/종속성	높음 / -	- / 보통	- / 낮음