디자인 패턴

U_Uracil·2024년 3월 27일

지식정리

목록 보기

5/5

디자인 패턴 vs 아키텍처 패턴

디자인 패턴

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

-- Wikipedia

소프트웨어 개발 과정에서 발생하는 반복적인 문제에 대한 일반적이고 재사용 가능한 솔루션
여러 상황에서 사용할 수 있는 문제 해결법에 대한 설명 or 템플릿
프로그래머가 애플리케이션이나 시스템을 설계할 때 일반적인 문제를 해결하는 데 사용할 수 있는 공식화된 모범 사례

아키텍처 패턴

An architectural pattern is a general, reusable resolution to a commonly occurring problem in software architecture within a given context. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability and minimization of a business risk. Some architectural patterns have been implemented within software frameworks.

Architectural patterns are similar to software design patterns but have a broader scope.

-- Wikipedia

주어진 context에서 일반적으로 발생하는 문제에 대한 일반적이고 재사용 가능한 해결책
컴퓨터 하드웨어 성능 제한, 고가용성, 비즈니스 위험 최소화 등 소프트웨어 엔지니어링의 다양한 문제를 해결
아키텍처 패턴은 소프트웨어 디자인 패턴과 유사하지만 범위가 더 넓음

둘의 차이점

아키텍처 패턴은 소프트웨어 디자인의 상위 수준 추상화, 디자인 패턴은 특정 모듈 수준 문제에 대한 솔루션
아키텍처 패턴은 설계 단계에서 제공, 디자인 패턴은 구축 단계에서 제공
아키텍처 패턴은 청사진, 디자인 패턴은 실제 구현
모든 아키텍처 패턴은 디자인 패턴이지만, 모든 디자인 패턴이 아키텍처 패턴일 수는 없음

디자인 패턴의 종류(Gang of Four, GoF)

“Design Patterns: Elements of Reusable Object-Oriented Software(1994)” 라는 책에서 처음 공개됨
소프트웨어 개발의 일반적인 디자인 문제에 대한 입증된 솔루션을 제공
23개의 일반적인 소프트웨어 디자인 패턴을 2가지 기준(목적, 범위)에 따라 나눔

생성 패턴(Creational Pattern)

객체를 생성하는데 관련된 패턴
객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함

팩토리 메서드(Factory Method) 패턴

객체를 생성하기 위한 인터페이스를 정의하고, 서브 클래스에서 어떤 클래스의 인스턴스를 생성할지 결정하는 패턴
인스턴스 생성을 위한 뼈대와 실제 인스턴스를 생성하는 클래스를 분리함

추상 팩토리(Abstract Factory) 패턴

구체적인 클래스를 지정하지 않고 인터페이스를 통해 서로 연관되는 객체들을 그룹으로 표현하는 패턴
구현해야 하는 기능을 추상 팩토리 인터페이스에 정의해놓고, 해당 기능을 구현한 구상 팩토리를 통해 실제 기능 동작

싱글톤(Singleton) 패턴

하나의 클래스 인스턴스를 전역에서 접근 가능하게 하면서 해당 인스턴스가 한 번만 생성되도록 보장하는 패턴
장점
- 클래스가 하나의 인스턴스만 갖는다는 걸 보장
- 이 인스턴스에 대해 전역 접근 가능
- 단 한번의 인스턴스 생성으로 성능 향상
단점
- 단일 책임 원칙(SRP) 위배
- 유닛 테스트가 힘들어짐
- 모듈 간 결합도가 증가함

빌더(Builder) 패턴

복잡한 객체를 생성하는 클래스와 표현하는 클래스를 분리하여 동일한 절차에서도 서로 다른 표현을 생성하는 방법을 제공하는 패턴
클래스가 객체를 직접 생성하는 대신 빌더 객체에 객체 생성을 위임
장점
- 객체 생성 과정을 일관된 프로세스로 표현 ⇒ 직관적으로 값 세팅이 보이므로 많은 매개변수 설정이 필요한 객체 생성 과정에서 실수를 줄일 수 있음
- 디폴트 매개변수 생략을 간접적으로 지원
- 필수 멤버와 선택적 멤버를 분리 가능 ⇒ 필수 멤버는 빌더의 생성자로 받도록
- 유연성과 가독성 높임
- 변경 가능성 최소화 ⇒ Setter를 사용하면 불필요한 변경 가능성 생김. 빌더 패턴을 사용하면 객체의 멤버를 final로 설정하거나 Setter를 구현하지 않음으로써 불변성을 확보할 수 있음
단점
- 코드 복잡성 증가 ⇒ 빌더 패턴은 적용하는 클래스 수만큼 빌더 클래스가 필요하기 때문에 관리해야 할 클래스가 많아짐
- 생성자보다 낮은 성능 ⇒ 매번 메서드를 호출하여 인스턴스화하기 때문에 약간의 성능 하락이 있음

구조 패턴(Structural Pattern)

프로그램 구조와 관련된 패턴
프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 활용할 수 있는 패턴

어댑터(Adaptor) 패턴

기존 클래스의 인터페이스를 다른 인터페이스로 사용할 수 있도록 하는 패턴
기존 클래스의 소스 코드를 수정하지 않고 다른 클래스와 함께 작동하도록 하는 데 자주 사용됨
Legacy 인터페이스를 감싸서 새로운 인터페이스로 변환하기 때문에 Wrapper 패턴이라고도 함
객체 어댑터와 클래스 어댑터로 나뉨
객체 어댑터
- 합성(Composition)된 멤버에게 위임을 이용한 어댑터 패턴

💡 위임 : 자기가 해야 할 일을 클래스 맴버 객체의 메소드에게 다시 시킴으로써 목적을 달성하는 것

클래스 어댑터
- 클래스 상속을 이용한 어댑터 패턴
- Adaptee(어댑터 대상 객체)를 상속하기 때문에 따로 객체 구현 없이 코드 재사용 가능
- 하지만 Java에서는 다중 상속 불가 문제 때문에 권장되지 않는 방식

프록시(Proxy) 패턴

대상 원본 객체를 대리하여 대신 처리하게 함으로써 로직의 흐름을 제어하는 행동 패턴
프록시의 기능
- 보안(Security) : 프록시는 클라이언트가 작업 수행 권한이 있는지 확인하고 권한이 있는 경우에만 대상에서 작업 실행
- 캐싱(Caching) : 프록시가 내부 캐시를 유지하여 데이터가 캐시에 존재하지 않는 경우에만 대상에서 작업 실행
- 데이터 유효성 검사(Data validation) : 입력 값을 대상으로 전달하기 전에 유효성 검사
- 지연 초기화(Lazy initialization) : 대상의 생성 비용이 비싸다면 실제 대상이 사용되기 전까지 연기
- 로깅(Logging) : 메소드 호출과 매개 변수를 인터셉트하고 기록
- 원격 객체(Remote objects) : 원격 위치에 있는 객체를 가져와 로컬처럼 보이게 함

행위 패턴(Behavioral Pattern)

반복적으로 사용되는 객체들의 상호작용을 패턴화한 것

옵저버(Observer) 패턴

옵저버가 관찰하고 있는 대상자의 상태 변화가 있을 때마다 대상자는 직접 목록의 각 옵저버에게 통지하고, 옵저버는 알림을 받아 조치를 취하는 행동 패턴
다른 디자인 패턴과 다르게 일대다 의존성을 가짐
Pub/Sub 모델로도 알려짐

전략(Strategy) 패턴

동일 계열의 알고리즘군을 정의하고 캡슐화하여 상호 교환이 가능하도록 만든 패턴
어떤 일을 수행하는 알고리즘이 여러 가지이고 이 알고리즘의 교체가 빈번하게 일어날 때 적합

Model-View 계열 디자인 패턴

MVC 패턴(Model-View-Controller)

애플리케이션을 Model, View, Controller의 세 부분으로 나누어 구조화한 패턴
소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 둠

Model

데이터와 비즈니스 로직을 관리
Controller에게 받은 데이터를 조작 및 가공하는 역할을 수행
규칙
1. 사용자가 편집을 원하는 모든 데이터를 가져야 함
2. View와 Controller에 대해 어떤 정보도 알지 말아야 함
3. 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야 함

View

사용자 인터페이스 요소를 나타냄
Controller로부터 받은 Model의 데이터를 사용자에게 보여주는 역할을 수행
규칙
1. Model이 가진 정보를 따로 저장하면 안됨
2. Model와 Controller에 대해 어떤 정보도 알지 말아야 함
3. 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야 함

Controller

Model과 View 사이에서 데이터 흐름을 제어함
사용자가 접근한 URL에 따라 요청을 파악, 알맞은 메서드를 호출하여 Service에서 비즈니스 로직 처리 후 Model에 저장해 View에 전달하는 역할 수행
규칙
1. Model이나 View에 대해서 알고 있어야 함
2. Model이나 View의 변경을 모니터링 해야 함

MVC 패턴의 장단점

장점
- 비즈니스 로직과 UI 로직의 분리로 유지보수를 독립적으로 수행 가능
- Model과 View가 다른 컴포넌트에 종속되지 않아 애플리케이션의 확장성, 유연성이 높음
- 여러 개발자가 모델, 뷰, 컨트롤러를 동시에 개발 가능
단점
- 규모가 커질수록 Controller의 역할이 과도하게 커지고 복잡해짐

MVC 패턴의 대안

MVP 패턴(Model-View-Presenter)

Controller 대신 Presenter가 있는 패턴
Controller와 View는 1:N인 반면, Presenter와 View는 1:1 관계임
MVC의 단점이었던 View ↔ Model의 강한 결합을 해결하기 위해 View와 Model을 인터페이스로 만들고, 이를 Presenter가 연결해줌으로써 View와 Model의 결합도를 낮춤
하지만 인터페이스 구현 과정에서 중복 코드가 많아지고, 프로젝트가 커짐에 따라 View ↔ Presenter 간의 결합도가 증가하는 문제가 있음

MVVM 패턴(Model-View-ViewModel)

Model, View 그리고 View를 추상화한 ViewModel로 이루어진 패턴
ViewModel은 Model과 View 간의 인터페이스 역할을 함
ViewModel은 View로부터 요청 받은 데이터를 처리하여 Model을 갱신하고, 갱신된 Model에 따라 자신이 소유한 데이터도 업데이트함
MVP 패턴과의 차이점으로는 Presenter는 View에 대한 참조를 가지고 있지만 ViewModel은 그렇지 않다는 점
ViewModel은 양방향 바인딩을 통해 View를 업데이트함
장점
- View와 Model이 서로 알지 못하기 때문에 독립성을 유지
- 효율적인 유닛 테스트
- View와 ViewModel을 바인딩하기 때문에 코드 양 감소
단점
- 간단한 UI에서 ViewModel을 설계하는 어려움이 있음
- 데이터 바인딩이 필수로 요구됨
- 표준화된 틀이 존재하지 않아 사람마다 이해가 다름

References
디자인패턴과 아키텍처 패턴
https://en.wikipedia.org/wiki/Software_design_pattern
https://onlyfor-me-blog.tistory.com/766
https://singhdivesh.medium.com/according-to-wikipedia-b1afa6de08c
https://www.linkedin.com/pulse/architectural-pattern-vs-design-praveen-kumar-kushwaha/
GoF 디자인패턴
https://4z7l.github.io/2020/12/25/design_pattern_GoF.html
https://realzero0.github.io/study/2017/06/12/디자인-패턴-정리.html
추상 팩토리
https://gmlwjd9405.github.io/2018/08/08/abstract-factory-pattern.html
https://refactoring.guru/ko/design-patterns/abstract-factory
싱글톤
https://blog.hexabrain.net/394
https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html
빌더
https://mangkyu.tistory.com/163
https://4z7l.github.io/2021/01/19/design_pattern_builder.html
https://inpa.tistory.com/entry/GOF-💠-빌더Builder-패턴-끝판왕-정리
어댑터
https://inpa.tistory.com/entry/GOF-💠-어댑터Adaptor-패턴-제대로-배워보자
https://refactoring.guru/ko/design-patterns/adapter
https://en.wikipedia.org/wiki/Adapter_pattern
프록시
https://inpa.tistory.com/entry/GOF-💠-프록시Proxy-패턴-제대로-배워보자
https://yaboong.github.io/design-pattern/2018/10/17/proxy-pattern/
옵저버
https://inpa.tistory.com/entry/GOF-💠-옵저버Observer-패턴-제대로-배워보자
https://coding-factory.tistory.com/710
https://refactoring.guru/ko/design-patterns/observer
전략
https://inpa.tistory.com/entry/GOF-💠-전략Strategy-패턴-제대로-배워보자
MVC 패턴
https://m.blog.naver.com/jhc9639/220967034588
https://velog.io/@langoustine/여기도-MVC-저기도-MVC-MVC-패턴이-뭐야
https://developer.mozilla.org/ko/docs/Glossary/MVC
MVVM 패턴
https://jhtop0419.tistory.com/21
https://developer-tj.tistory.com/30
https://devowen.com/457

U_Uracil

기억은 유한, 기록은 무한

이전 포스트

디자인 패턴

지식정리

디자인 패턴 vs 아키텍처 패턴

디자인 패턴

아키텍처 패턴

둘의 차이점

디자인 패턴의 종류(Gang of Four, GoF)

생성 패턴(Creational Pattern)

팩토리 메서드(Factory Method) 패턴

추상 팩토리(Abstract Factory) 패턴

싱글톤(Singleton) 패턴

빌더(Builder) 패턴

구조 패턴(Structural Pattern)

어댑터(Adaptor) 패턴

프록시(Proxy) 패턴

행위 패턴(Behavioral Pattern)

옵저버(Observer) 패턴

전략(Strategy) 패턴

Model-View 계열 디자인 패턴

MVC 패턴(Model-View-Controller)

Model

View

Controller

MVC 패턴의 장단점

MVC 패턴의 대안

MVP 패턴(Model-View-Presenter)

MVVM 패턴(Model-View-ViewModel)

Intellij 프로젝트 폴더 안보일 때

0개의 댓글