이전 게시글 웹 보안
https://hoozy.tistory.com/entry/%EB%B0%B1%EC%97%94%EB%93%9C-%EC%9B%B9-%EB%B3%B4%EC%95%88
아키텍처 패턴
- 소프트웨어 시스템을 위한 검증된 구조적 도해이다. 패턴은 서브 시스템과 그들의 역할을 사전 정의해 놓은 하나의 Set이다.
- 패턴은 시스템들 사이의 관계를 정리하기 위한 규칙과 지침을 설명한다. 패턴은 경험이 많은 사람들에 의해 기록되어지고, 이렇게 많은 사람들의 경험에 의해 만들어지는 것이다.
패턴 사용의 효율성
- 어떠한 문제가 많은 개발자들에 의해 비슷한 방식으로 해결되고, 그 방법이 일반적으로 해당 문제를 해결하는 방식으로 받아들여질 때, 그 방식은 패턴이 되어 진다.
- 그래서 패턴은 반복 발생하고, 일반적 해결책이 많은 경험자들 사이에서 알려진 설계 문제를 다루고 있어서 패턴에 대한 문서가 있으며, 이는 잘 검증된 설계 문제의 해결책이 되는 것이다.
- 패턴을 기록하여 해결책을 재사용함이 쉬워진다.
- 패턴은 일반적인 어휘와 설계 솔루션에 대한 이해를 제공한다. 각 패턴의 이름은 널리 퍼진 디자인 언어의 일부가 되어가고 있다.
- 패턴은 특별한 문제에 대한 해결책에 대한 기나긴 설명의 필요를 제거한다. 그러므로 패턴은 소프트웨어 아키텍처를 문서화하는 방법이며, 이는 아키텍처의 오리지널 비전이 수정되거나 확장되어질 때 또는 코드 수정 등이 이루어질 때 아키텍처의 운영 관리를 지원하기도 한다. 패턴은 정의된 속성을 가지고 소프트웨어의 구축을 지원한다.
패턴 사용의 주의점
- 디자인 패턴의 과다한 사용은 불필요하게 복잡한 코드를 초래할 수 있다.
- 항상 가장 간단한 해결책으로 목적을 달성할 수 있도록 하고, 반드시 필요할 때만 디자인 패턴을 적용해야 한다.
- 코딩할 때 어떤 패턴을 사용하고 있는지 주석으로 적어준다.
- 클래스와 메서드 이름을 만들 때도 사용 중인 패턴이 분명하게 드러날 수 있도록 해야 한다.
- 다른 개발자들이 그 코드를 볼 때 무엇을 어떻게 구현했는지 훨씬 빠르게 이해할 수 있다.
국내에서 주로 사용하는 5 가지의 아키텍처 패턴
1) Layer 패턴
- 가장 일반적으로 사용하는 아키텍처 패턴으로서 subtask 들을 그룹으로 묶어 사용 허가 관계를 표시하는 패턴이다.
- 모듈의 재사용성을 높여 유지보수성이나 이식성에 좋은 패턴이다.
2) Broker 패턴
- 외부에 분산된 컴포넌트를 호출하려고 할 때 클라이언트 request의 분석하여 서버 컴포넌트에 전달하고 그 결과 값을 전달하는 역할을 하는 패턴을 브로커 패턴이라고 한다.
- 보안이나, 안정성을 높일 수 있는 패턴이다.
3) MVC 패턴
- 모델, 뷰, 컨트롤 세 개의 컴포넌트로 어플리케이션을 구분한 패턴으로 사용자 인터페이스를 가지고 있는 많은 어플리케이션에 사용된다.
- 모델은 기능과 데이터를 가지고 있고 뷰는 사용자의 화면 표시를 지원한다.
- 컨트롤러는 이들과의 관계를 가지고 사용자 이벤트나 모델의 변화를 감지하여 모델과 뷰에 전달하는 역할을 한다.
- 뷰와 모델 사의 사이의 일관성을 갖게 하여 변경용이성, 기능 확장성을 지원한다.
4) State-Logic-Display (3-tier) 패턴
- 비즈니스 애플리케이션을 개발할 때 가장 일반적으로 사용되는 패턴으로 사용자 인터페이스(UI)와 비즈니스 로직, 데이터를 구분하여 변경 용이성이 좋다.
- 게임, 웹 어플리케이션 등 많은 분야에서 사용되고 있다.
5) Sense-Compute-Control 패턴
- 일정한 시간 별로 센서의 값을 읽어 들이는 Sense와 센서의 값을 계산하여 해야 할 행위를 정의한 compute, actuator에 해야 할 기능이나 행위를 전달하는 control로 모듈을 구분하는 패턴을 말한다.
- 임베디드 애플리케이션을 개발할 때 주로 사용되는 패턴이다.
- 아키텍처 패턴은 지속적으로 발표되고 있고 웹과 서적을 통해 공유하고 있다.
- 또한 대부분의 아키텍트나 설계와 구현을 오래한 엔지니어들은 자신들의 경험을 정리한 패턴들을 갖고 있다.
- 중요한 것은 이러한 경험들을 재사용할 수 있도록 체계적으로 정리하고 관리하는 것이다.
디자인 패턴
- 프로그래밍을 하다 보면 반드시 라이브러리, 패키지, 모듈, 프레임워크 같은 것을 사용한다. 이 프로그래밍을 도와주는 도구들을 자유자재로 활용하려면 도구의 정확한 용도와 장단점, 핵심적인 특성, 사용 시 주의사항 등을 제대로 파악하고 있어야 한다.
- 라이브러리가 없다면 모든 프로그래머들이 시행착오를 반복하면서 클래스나 함수, 메소드 등을 직접 만들어 프로그래밍해야 한다.
- 디자인 패턴은 프로그램을 개발하는 과정에서 빈번하게 발생하는 디자인 상의 문제를 정리해서, 상황에 따라 간편하게 적용해서 쓸 수 있는 패턴 형태로 만든 것이다.
디자인 패턴 종류
1) Strategy 패턴
- 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다.
- 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.
- 일반적으로 서브클래스를 만드는 방법을 대신하여 유연성을 극대화하기 위한 용도로 쓰인다.
- EX) QuarkBehavior & FlyBehavior
2) Observer 패턴
- 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일 대 다(one-to-many) 의존성을 정의한다.
- 주제(Observable) & 옵저버(Observer) Observable에 register, remove, notify가 있고, Observer에 update가 있다. (notify에서 update를 호출)
- EX) 신문 구독 서비스, 기상관측 시스템
3) Decorator 패턴
- 객체에 추가적인 요건을 동적으로 첨가한다.
- 데코레이터는 서브 클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.
- EX) 스타벅스 커피
4) Factory 패턴
- 팩토리 메서드 패턴(Factory method pattern)
- 객체를 생성하기 위한 인터페이스를 정의하는데, 어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정하게 만든다.
- 클래스의 인스턴스를 만드는 일을 서브 클래스에 맡긴다.
- 제품을 생산하는 부분과 사용하는 부분을 분리시킬 수 있다.
- 추상 팩토리 패턴(Abstract Factory Pattern)
- 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고 생성한다.
- 구상 클래스는 서브 클래스에 의해 만들어진다.
5) Singleton 패턴
- 해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접근할 수 있도록(전역 접근) 하기 위한 패턴이다.
6) Command 패턴
- 요구사항을 객체로 캡슐화 할 수 있으며, 매개변수를 써서 여러 가지 다른 요구사항을 집어넣을 수 있다.
- 또한, 요청 내역을 큐에 저장하거나 로그로 기록할 수도 있으며, 작업 취소기능도 지원 가능하다.
- 서블릿의 doGet(), doPost() 또는 스트럿츠의 Action() 메서드도 Command 패턴일 것이다.
- EX) 리모컨
7) Adapter 패턴
- 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환한다.
- 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있다.
8) Facade 패턴
- 어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공한다.
- Facade에서 고수준 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용할 수 있다.
- 서브 시스템의 호출을 퍼사드에서 처리해 준다.(기본 명령 호출 정도)
- 일련의 클래스들에 대한 인터페이스를 단순화 시킨다.
- 각 패턴별 차이점은 다음과 같다.
- Decorator 패턴: 인터페이스는 바꾸지 않고 책임(기능)만 추가
- Adapter 패턴: 한 인터페이스를 다른 인터페이스로 변환
- Facade 패턴: 인터페이스를 간단하게 바꿈
9) Template Method 패턴
- 메서드에서 알고리즘의 골격을 정의한다.
- 알고리즘의 여러 단계 중 일부는 서브 클래스에서 구현할 수 있다.
- 템플릿 메서드를 이용하면 알고리즘의 구조는 그대로 유지하면서 서브 클래스에서 특정 단계를 재정의 할 수 있다.
- Strategy 패턴과 다른 점은 템플릿 메서드 패턴은 알고리즘의 개요를 정의하며 실제 작업 중 일부는 서브 클래스에서 처리한다.
- Strategy 패턴은 객체 구성을 통해서 알고리즘을 캡슐화하고 구현한다.
10) Iterator 패턴
- 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있게 해주는 방법을 제공한다.
- 컬렉션의 구현을 드러내지 않으면서 컬렉션에 있는 모든 객체들에 대해 반복 작업할 수 있다.
11) Composite 패턴
- 객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층 구조로 만들 수 있다.
- 이 패턴을 이용하면 클라이언트에서 개별 객체와 다른 객체들로 구성된 복합 객체(composite)를 똑같은 방법으로 다룰 수 있다.
- 클라이언트에서 객체 컬렉션과 개별 객체를 똑같은 식으로 처리할 수 있다.
- XMLObject 객체가 Composite 패턴을 구현
- EX) 트리 구조의 패턴, 디렉토리 구조
12) State 패턴
- 객체의 내부 상태가 바뀜에 따라서 객체의 행동을 바꿀 수 있다. 마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있다.
- 상태 전환의 흐름을 결정하는 코드를 상태 객체 또는 Context 객체 중 어느 쪽에 집어 넣을지 잘 고려해야 한다.
- 각 상태를 클래스로 캡슐화하여 나중에 변경시켜야 하는 내용을 국지화 시킬 수 있다.
Strategy 패턴: 어떤 클래스의 인스턴스를 만들고 그 인스턴스에게 어떤 행동을 구현하는 전략 객체를 제공
State 패턴: 컨텍스트 객체를 생성할 때 초기 상태를 지정해 주는 경우, 이후로는 컨텍스트 객체가 알아서 상태를 변경
13) Proxy 패턴
- 어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하는 객체를 제공하는 패턴이다.
- 다른 객체를 대변하는 객체를 만들어서 주 객체에 대한 접근을 제어할 수 있다.
- 원격프록시(remote proxy): 원격 객체에 대한 접근 제어 클라이언트와 원격 객체 사이에서 데이터 전달을 관리한다.
- 가상프록시(virtual proxy): 인스턴스를 만드는 데 많은 비용이 들어 생성하기 힘든 자원에 대한 접근을 제어한다.
- 보호프록시(protection proxy): 접근 권한이 필요한 자원에 대한 접근 제어, 호출하는 쪽의 권한에 따라서 객체에 있는 메소드에 대한 접근을 제어한다.
- 방화벽 프록시: 일련의 네트워크 자원에 대한 접근을 제어한다.
- 스마트 레퍼런스 프록시: 주 객체가 참조될 때마다 객체에 대한 레퍼런스 개수를 세는 등 추가 행동을 제공한다.
- 캐싱 프록시: 비용이 많이 드는 작업의 결과를 임시로 저장, 웹 서버 프록시 또는 컨텐츠 관리 및 퍼블리싱 시스템 등에서 사용한다.
- 동기화 프록시: 여러 스레드에서 주 객체에 접근하는 경우, 분산 환경 등에서 안전하게 작업을 처리할 목적으로 사용한다.
- 복잡도 숨김 프록시: 복잡한 클래스들의 집합에 대한 접근을 제어하고 복잡도를 숨겨주며 퍼사드 프록시라고도 한다. 프록시에서는 접근을 제어하지만 Facade 패턴에서는 대체 인터페이스만 제공한다.
- 지연 복사 프록시: 클라이언트에서 필요로 할 때까지 객체가 복사되는 것을 지연시켜 객체의 복사를 제어한다.
다음 게시글 가상화 / 컨테이너
참고 자료
https://velog.io/@formin/%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8C%A8%ED%84%B4Architecture-Patterns-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4Design-Pattern
https://bluayer.com/37
댓글