디자인 패턴이란?
- 프로그램을 설계할 때 발생했던 문제점들을 객체 간의 상호 관계 등을 이용하여 해결할 수 있도록 하나의 규약 형태로 만들어 놓은 것.
디자인패턴 분류
23가지의 디자인 패턴이 존재한다. 각각의 디자인 패턴은 생성(Creational), 구조(Structural), 행위(Behavioral) 3가지로 패턴으로 분류된다.
생성 패턴 (Creational pattern)
- 객체 생성에 관련된 패턴이다. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.
구조 패턴 (Structural pattern)
- 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴이다. 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.
행위 패턴 (Behavioral pattern)
- 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴
- 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.
1.1 싱글톤 패턴 (Singleton pattern)
- 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴
- 하나의 클래스를 기반으로 단 하나의 인스턴스를 만들어 이를 기반으로 로직을 만드는 데 쓰임.
- 데이터베이스 연결 모듈에 많이 사용.
- 장점 : 하나의 인스턴스를 다를 모듈들이 공유하며 사용하므로 인스턴스 생성 비용이 줄어든다.
- 단점 : 의존성이 높아진다.
싱글톤 패턴의 단점
- TDD의 어려움
- 테스트 주도 개발 시엔 단위 테스트를 주로 하는데, 단위 테스트는 서로 독립적이어야 하며 테스트를 어떤 순서로든 실행할 수 있어야 함
- 싱글톤 패턴은 미리 생성된 하나의 인스턴스를 기반으로 구현해야 하므로 각 테스트마다 ‘독립적인’ 인스턴스를 만들기가 어렵다.
- 모듈 간의 결합도 상승
- 의존성 주입을 통해 해결
- 의존성 주입의 장점
- 일관된 의존성 방향
- 쉬운 애플리케이션 추론
- 모듈 간의 관계의 명확도 상승
- 의존성 주입의 단점
- 코드의 복잡성 증가
- 런타임 페널티
- 의존성 주입의 원칙
- 상위 모듈은 하위 모듈에서 어떠한 것도 가져와선 안 된다.
- 상위 모듈과 하위 모듈은 추상화에 의존해야 한다.
- 추상화는 세부 사항에 의존하지 말아야 한다.
1.2 팩토리 패턴
팩토리 패턴이란?
- 객체를 사용하는 코드에서 객체 생성 부분을 떼어내 추상화한 패턴이자 상속 관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴.
- 클래스의 인스턴스를 만드는 일을 서브 클래스에게 맡기는 일.
- 여러개의 서브 클래스를 가진 슈퍼 클래스가 있을 때, 인풋에 따라 하나의 자식 클래스의 인스턴스를 리턴해주는 방식.
- 상위 클래스와 하위 클래스의 분리 → 느슨한 결합도
- 상위 클래스에서는 인스턴스 생성 방식에 대해 전혀 알 필요가 없음 → 높은 유연성
- 객체 생성 로직이 따로 떼어져 있어 코드를 리팩터링하더라도 한 곳만 고칠 수 있음 → 유지 보수성 증가
1.3 전략 패턴
전략 패턴 (strategy pattern)
- 정책 패턴(policy pattern)이라고도 불림.
- 객체의 행위를 바꾸고 싶은 경우 ‘직접’ 수정하지 않고 전략이라고 부르는 **캡슐화한 알고리즘**을 컨텍스트 안에서 바꿔주며 상호 교체가 가능하게 만는 패턴
1.4 옵저버 패턴
옵저버 패턴
- 옵저버 패턴( observer pattern)은 주체가 어떤 객체의 상태 변화를 관찰하다가 상태 변화가 있을 때마다 메서드 등을 통해 옵저버 목록에 있는 옵저버들에게 변화를 알려주는 디자인 패턴.
- 이벤트 기반 시스템에서 사용
- MVC(Model-View-Controller) 패턴에서도 사용.
- 모델(주체)에 변경 사항이 생겨 update() 메서드로 뷰(옵저버)에 알려주고 이를 기반으로 controller가 작동.
1.5 프록시 패턴과 프록시 서버
프록시 패턴
프록시 패턴은 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴- 프록시 패턴(Proxy Pattern)은 대상 원본 객체를 대리하여 대신 처리하게 함으로써 로직의 흐름을 제어하는 행동 패턴
- 객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용
<aside> 💡 프록시 서버에서의 캐싱 캐시 안에 정보를 담아 두고, 캐시 안에 있는 정보를 요구하는 요청에 대해 다시 저 멀리 있는 원격 서버에 요청하지 않고, 캐시 안에 있는 데이터를 활용하는 것을 말한다. 이를 통해 불필요하게 외부와 연결하지 않기 때문에 트래픽을 줄일 수 있다는 장점이 있다.
</aside>
[프록시 패턴의 장단점]
프록시패턴 장점
- 사이즈가 큰 객체가 로딩되기 전에도 프록시를 통해 참조를 할 수 있다.
- 실제 객체의 public, protected 메소드를 숨기고 인터페이스를 통해 노출시킬 수 있다.
- 로컬에 있지 않고 떨어져있는 객체를 사용할 수 있다.
- 원래 객체에 접근에 대해 사전처리를 할 수 있다.
프록시패턴 단점
- 객체를 생성할 때 한 단계를 거치게 되므로, 빈번한 객체 생성이 필요한 경우 성능이 저하될 수 있다.
- 프록시 내부에서 객체 생성을 위해 스레드가 생성, 동기화가 구현되어야 하는 경우 성능이 저하될 수 있다.
- 로직이 난해해져 가독성이 떨어질 수 있다.
[프록시 패턴의 종류]
가상프록시
꼭 필요로 하는 시점까지 객체의 생성을 연기하고, 해당 객체가 생성된 것 처럼 동작하도록 만들고 싶을 때 사용하는 패턴이다. 프록시 클래스에서 작은 단위의 작업을 처리하고 리소스가 많이 요구되는 작업들이 필요할 경우만 주체 클래스를 사용하도록 구현한다.
원격프록시
원격 객체에 대한 접근을 제어 로컬 환경에 존재하며, 원격 객체에 대한 대변자 역할을 하는 객체
서로 다른 주소 공간에 있는 객체에 대해 마치 같은 주소 공간에 있는 것 처럼 동작하게 하는 패턴이다.(예: Google Docs)
보호프록시
주체 클래스에 대한 접근을 제어하기 위한 경우에 객체에 대한 접근 권한을 제어하거나 객체마다 접근 권한을 달리하고 싶을 경우 사용하는 패턴으로 프록시 클래스에서 클라이언트가 주체 클래스에 대한 접근을 허용할지 말지 결정하도록 할 수 있다.
프록시 서버
- 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.
- NGINX
- nginx는 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버
- 익명 사용자가 집접적으로 서버에 접근하는 것을 차단하고, 간접적으로 한 단계를 더 거치게 만들어 보안을 강화할 수 있다.
- CloudFlare
- 전 세계적으로 분산된 서버가 있고 이를 통해 어떠한 시스템의 콘텐츠 전달을 빠르게 할 수 있는 CDN(Content Delivery Network) 서비스.
- DDOS 공격 방어나 HTTPS 구축에 사용 됨.
- 서비스를 배포한 이후, 해외에서 의심스러운 트래픽이 많이 발생하면 CloudFlare가 판단해 CAPTCHA 등을 기반으로 일정 부분 막아주는 역할을 수행한다.
- CORS와 프런트엔드의 프록시 서버
- CORS(Cross-Origin Resource Sharing)는 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘.
1.6 이터레이터 패턴
이터레이터 패턴
행위 패턴
- Iterator를 사용하여 컬렉션(Collection)의 요소들에 접근하는 디자인 패턴
- 순회할 수 있는 여러 가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로 순회가 가능하다.
- 이터레이터 프로토컬
- 이터러블한 객체들을 순회할 때 쓰이는 규칙
- 이터러블한 객체
- 반복 가능한 객체로 배열을 일반화한 객체
1.7 노출모듈 패턴
노출모듈 패턴(Revealing module pattern)
- 즉시 실행 함수를 통해 public, private 와 같이 접근 제어자를 만드는 패턴
- 자바 스크립트에서는 접근 제어자가 존재하지 않아 전역 범위에서 스크랩트가 실행되므로 노출모듈 패턴을 통해 private와 public 접근 제어자를 구현함.
1.8 MVC 패턴
MVC 패턴(Model-View-Controller pattern)
- 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴.
- 애플리케이션의 구성요소를 세가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중하여 개발할 수 있다.
- 재사용성과 확장성이 용이하다는 장점이 있다.
- 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해 진다.
Model
- 애플리케이션의 데이터인 데이터베이스, 상수, 변수를 뜻함.
- 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신한다.
View
- inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 나타냄.
- 모델을 기반으로 사용자가 볼 수 있는 화면
- 모델이 가지고 있는 정보를 따로 저장하지 않아야 하며, 단순히 사각형 모양 등 화면에 표시하는 정보만 가지고 있어야 한다.
- 변경이 일어나면 컨트롤러에 이를 전달.
Controller
- 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할.
- 이벤트 등 메인 로직 담당.
- 모델과 뷰의 생성주기 관리
- 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성요소에 해당 내용에 대해 알려줌
Spring Framework
- MVC 패턴을 이용한 대표적인 프레임 워크
- 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크
- @RequestParam, @RequestHeader, @PathVariable 등의 어노테이션을 기반으로 사용자의 요청 값들을 쉽게 분석, 사용자의 어떠한 요청이 유효한 요청인지 쉽게 거를 수 있음.
1.9 MVP 패턴
- MVC 패턴으로부터 파생된 패턴
- Controller 대신 Presenter로 교체
- 뷰와 프레젠터는 일대일 관계.
- MVC 패턴보다 더 강한 결합을 지님.
1.10 MVVM 패턴
- MVC의 C에 해당하는 Controller가 뷰모델(View Model)로 바뀐 패턴
- 뷰모델 : 뷰를 더 추상화한 계층
- MVVM 패턴은 MVC 패턴과는 다르게 커맨드와 데이터 바인딩을 가지는 것이 특징.
- 커맨드 : 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법.
- 데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법으로, 뷰모델을 변경하면 뷰가 변경된다.
- 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원
- UI를 별도의 코드 수정 없이 재사용할 수 있고, 단위 테스팅하기 쉽다.
Vue.js
- MVVM 패턴을 가진 대표적인 프레임워크
- 함수를 사용하지 않고 값 대입만으로도 변수가 변경
- 양방향 바인딩, html을 토대로 컴포넌트를 구축할 수 있다.
- 재사용 가능한 컴포넌트 기반으로 UI를 구축할 수 있다.
'CS > 면접을 위한 CS 전공 지식 노트' 카테고리의 다른 글
면접 예상 질문 모음 (0) | 2023.11.09 |
---|---|
[CS] 프로세스와 스레드(1) (0) | 2023.07.27 |
[CS] 운영체제와 컴퓨터 (0) | 2023.07.20 |