[Software Architecture] Pattern 에 대해서

패턴

• 구현, 설계하는 도구 (업계에서 통용되는 언어)
• 패턴은 
  • Interface + Concrete class 형태로 구성되어 있음
    
    • 이런 패턴들이 여러가지가 있어 -> 생성시 사용되면 Factory pattern 등
  • 여러개의 패턴이 뭉쳐서 움직인다
  • 팀 내 의사 소통의 수단이 되기 위해선, 팀원들의 이해가 필요한다
  • 패턴의 남용
    • 리소스 제약이 심한 시스템에 유연성 추가하기?
      -> 성능상에 문제가 발생하는 경우
    • 패턴의 Side-effect가 굉장히 크기 때문에 이에 대한 부분을 확인을 해야 함
• 추천
  • 알기쉬운 디자인 패턴
  • Head First Design Pattern
  • Java 언어로 배우는 디자인 패턴 입문
  • POSA 1
    • 거대한 구조를 잡을 때 쓰는 패턴
    • Layer, Pipe & Filter, Broker, Master Slave, Client-Dispatcher, Forwarder-Receiver, MVC
  •  POSA 2 ** 
    • 서버, 네트워크를 만드는 패턴
  • POSA 3
    • 리소스를 관리하는 패턴
  • Patterns for fault tolerent software

 

 

POSA 1 - 아키텍처 패턴 (아키텍처를 다루는 패턴 / 현업에서 사용중인 패턴의 동작방식을 이해가 필요)

• Layer (의존성관리)
  • Dependency를 잘 관리하기 위해서 만들었다
    하나의 Layer가 변경이 되면 그 상위 Layer에서만 영향을 흡수한다
  • 과도한 계층 통과로 성능 저하 발생
• Pipe & Filter (유연한 Pipe-Filetr 조립)
  • 각 필터(Layer)를 거쳐감에 따라 데이터를 삽입, 변경, 조작 함으로써 원하는 형태대로 데이터 변경됨
  • 가장 느린 필터로 인해 전체 성능이 저하될 수 있음
• Broker
  • 클라이언 - 서버와 언어/플랫폼이 다른 경우 통신방법에 대한 패턴
    -> 중간의 데이터 형태로 변화되어서 전송되어야 함
  • 이런 애들이 있어
    • COBA - 너무 느려서 안쓰다가 Apache Trift에서 엄청 개선됨
    • Apache Trift
    • Google protocol buffers 
    • Embeded에서도 많이 사용함
      • Android에서 Binder를 통해서 구동되도록
  • 서로 다른 언어, 플랫폼에도 통신 가능
  • 데이터 마샬링/언마샬링 고려 필요
• Master Slave
  • 요즘은 Primary-Secondary 
  • Slave 교체나 확장이 가능 / 효율성 향상
  • 종속성이 강하고, FailOver Engineering 준비 필요
  • 예) ProxySQL Cluster
• Client-Dispatcher
  • 서버에 Dispatcher 를 구성하는 패턴 (프로토콜 추가/삭제/변경을 쉽게 할 수 있는 패턴)
  • Reactor/Proactor/Con-Acc 패턴으로 진화
• Forwarder-Receiver (P2P 패턴)
  • Sersor 
• Publisher-Subscribe
  • Observer 패턴과 동일
  • 변경이 되면 등록된 주소(Reference list)로 Client로 쏴주는 패턴
  • 계속 Polling해서 묻는 것보다 의존관계를 역전시켜서 트래픽 축소
  • 하나의 주제가 아닌 다양한 주제를 다루거나, 서브셋을 다룰때 비효율적인 이슈 발생
    -> Event Channel로 진화 (Filter를 적용)
• MVC
  • View - Model - Control
  • DB/Proxy 등의 의존성을 분리할때 주로 사용
• Presentation-Abstraction-Control
  • 다루고자 하는 Context와 관련된 UI로 변경할 때 사용하는 패턴
  • 다루는 Context에 따라서 능동적인 UI 제공
  • 제어하는 컴포넌트의 복잡도가 증가
• Reflection
  • Runtime시에 객체를 생성하는 패턴
  • SW의 시스템 변경이 쉽고 인터페이스가 동일하다는 전제가 핵심
  • 늦은 속도 문제 -> 현업에서는 Reflection 보다 BCI (Byte Code Instrumentation) 선호
• Counted Pointer
  • Reference Count
  • 공유하고 있는 자원을 언제 릴리즈 할 것인지? 자원을 사용하는 수를 카운트하여 0이 될때 내리자
  • 참조 카운트이며 자원의 적절한 해제 시점을 알려줌
  • Theread 환경에서 Counted point 사용시 주의 필요
• Blackboard
  • 해결 전략이 알여지지 않은 여러 모듈들을 매칭하여 해결하는 패턴
  • 인공지는 후보모델을 여러개 돌리는 경우
  • 예를 들어 Exception handler 같은 애들
  • 정형화 되지 않은 상황에 따라 솔루션이 능동적으로 변경할 때 사용하는 패턴
  • Real time solution = 주어진 Dead line에 동작하도록 하는 솔루션 (각 Dead line별 솔루션을 가지고 있어야함)