디자인 패턴 소개

여러 가지 방법론

 

개발 방법론엔 프로세스 지향 방법, 데이터 지향 방법, 객체지향 방법, 컴포넌트 기반 방법 등 다양한 방법론이 있다.

 

 

 

프로세스 지향 방법

 

여러 방법론 중 프로세스 지향 방법으로 분류되는 절차적 방법 ( procedural approach )은 처리 순서를 구조화하는 방법이다.

대표적으로 DFD (Data Flow Diagram)을 사용한다.

DFD 예시

 

 

 

프로세스 지향 방법은 기능이 중심(우선)이 되고 그 기능을 수행하는 데 필요한 데이터가 참조되는 형태로 구성된다.

프로세스 지향 방법

 

 

이러한 방법은 다음과 같은 특징이 있다.

  • 프로세스와 데이터의 분리
    프로세스와 데이터가 각각 별개의 것으로 파악되고 분리되어 구조가 매우 복잡하며 유지보수가 어려움
  • 실세계를 컴퓨터 처리 방식으로 표현
    실세계를 원래의 형태가 아니라컴퓨터가 처리하는 방식으로 변환하여 표현해서 왜곡이 발생함
  • 함수 중심(우선)으로 모듈 구성
    모듈을 구성할 때 처리중심의 함수가 우선 결정, 함수들의 모임인 모듈로 구성된 시스템에 데이터가 별도로 존재하게 됨

 

 

 

 

데이터 지향 방법 data oriented approach

 

시스템이 취급하는 데이터에 관심이 있다. 즉, 데이터가 중심(우선)이 되어 데이터를 구조화한다.

대표적으로 정보공학 방법론이 있다.

 

이 방법론은 기업 비즈니스 시스템같은 대규모 시스템 구축의 체계적인 절차를 만들기 위해 개발되었다.

 

기업의 업무 프로세스는 수시로 변하지만 데이터는 대부분 그대로 있기 때문에

데이터 중심으로 분석하고 설계하면 시스템 유지보수 횟수를 줄이고 잦은 변화에 적극 대응 할 수 있다.

 

DB 설계를 위한 대표적 모델 표기법 E-R Entity-Relationship 다이어그램

 

 

 

 

프로세스 지향 방법과 데이터 지향 방법의 문제점

 

1. 변경이 미치는 영향이 큼

프로세스와 데이터를 각각 별개의 것으로 파악하기 때문에

한쪽이 바뀌면 다른 한쪽에 영향을 미치기 때문에 항상 수정전에 확인이 필요하다. (테스트)

 

2. 프로그램의 복잡도 증가

함수와 데이터가 분리되어 있기 때문

 

3. 프로그램 변경 시 프로그램 구조 파악 필요

프로그래머는 프로그램의 구조와영향을 미치는 곳도 파악해야 한다.

 

4. 재사용의 어려움

프로세스와 데이터가 분리된 구조 때문에 유지보수도 쉽지 않다.

 

 

 

 

객체지향 방법 object-oriented approach

 

위에서 말한 프로세스 지향 방법과 데이터 지향 방법의 문제점을 해결하기 위해 고안된 방법론이다.

 

기능이나 데이터 대신 객체가 중심이 되어 개발한다.

데이터(속성)를 가장 먼저 찾고 그 데이터를 조작하는 메서드(함수)를 찾아 그 둘을 객체라는 이름으로 묶는다.

그 객체를 중심으로 모듈을 구성한다.

 

필요 객체를 찾아 하나의 모듈 구성 -> 모듈들을 결합 -> 모듈간의 연관성을 식별하여 모델링 -> 이를 기반으로 소프트웨어 완성

 

객체지향 방법의 특징은 다음과 같다.

  • 실세계를 사람이 생각하는 방식으로 표현한다.
    사람이 생각하는 방식대로 표현하여 컴퓨터로 옮기는 방식으로, 개발 환경을 단순화한다.
  • 임의로 데이터에 접근할 수 없다.
    메서드와 데이터를 객체로 묶어 객체의 인터페이스만을 통하여 데이터 접근 가능하다.
  • 시스템은 객체들의 모임이다
    시스템은 객체의 모임인 모듈들로 구성된다.
  • 요구 사항 변경에 유연하게 대처할 수 있다
    객체의 추가/삭제가 쉬워서 변경이 많아도 대처가 가능하다.
  • 확장성과 재사용성이 높아진다.
    필요 객체를 추가하는 구조이므로 확장성, 재사용성이 높아 개발 시간과 비용이 감소한다.
  • 추상화를 통해 생산성과 품질이 높아진다
    시스템 추상화 기술을 이용하여 시스템 설계를 단순화한다.

 

 

 

 

 

디자인 패턴

 

자주 사용하는 설계 형태를 정형화해서 이를 유형별로 설계 템플릿을 만들어둔 것으로,

위에서 말한 객체 지향 방법론을 사용하여 설계 아이디어를 체계화시킨 것을 디자인 패턴이라는 개념으로 정리한 것이다.

 

 

디자인 패턴은 전문가의 노하우를 모아 놓은 경험이므로 좋은 설계가 되도록 도와주고,

자주 접하는 설계문서를 해결해주는 증명된 솔루션을 체계적으로 정리한 것이기 때문에 반복되는 설계 문제 해결에 도움이 된다.

 

 

 

특히 디자인 패턴의 장점으로

정형화된 패턴이기 때문에 소프트웨어 구조 파악에 용이하다.

그리고 이미 개발자들 사이에서 알고 있는 개념이기 때문에 서로 원활한 의사소통이 가능하다.

 

 

하지만 디자인 패턴은 객체지향 설계 / 구현 위주이기 때문에

C 언어 등의 구조적 설계 / 구현에는 복잡해서 적합하지 않다.

 

게다가 어쩔 수 없는 초기 투자 비용을 부담해야 하기 때문에 시간과 노력이 더 필요하다.

 

 

 

 

 

code complete에 있는 Heuristics

 

일반적인 객체 지향처럼 위에 설명한 객체를 식별하고, 추상화를 적용하거나 세부 사항은 캡슐화를 해라 등등~ 여러가지 코드에 좋은 조언들이 있다.

 

비록 설계에는 정답이 없다지만 이런 휴리스틱들을 적용하면 좋은 설계를 얻을 수 있다.

 

 

여러가지 있지만.. 그 중 강조하고 싶은 부분은

상속 보다는 합성을 사용할 것

소프트웨어 설계에서 배웠던 느슨한 결합, 강한 응집도

디자인 패턴 사용하기

 

이 3가지 사항과 객체지향 원칙을 지키면 좋은 설계가 가능하다.

 

 

 

참고로 위 예시가 상속이다.

이런 구조는 추상화를 지향하지만 캡슐화를 깨기 때문에 웬만해선 지양해야 한다.

Is-a 관계라고 한다.

 

 

합성은 중복되는 논리 코드를 객체로 만들어서 사용하는 것이다. (결합이 약해짐)

이 객체를 호출하여 캡슐화는 유지하고 재사용성을 높일 수 있다.

Has-a 관계라고 한다.

 

 

 

다음 휴리스틱인 디자인 패턴은 소프트웨어에 자주 나오는 구조를 말한다.

코드나 디자인 자체가 아니라 그냥 일종의 템플릿이다.

 

실제 설계에서 모아 추상화를 해서 클래스, 협동, 책임 등을 정리한 것이다.

이러면 구현할 때 장단점이 기술된다.

 

 

개발자는 이런 장단점을 보고 패턴 이용에 대해서 저울질을 한다.

어떤 패턴이 좋은지 판단하고, 패턴을 코드로 구현한다.

 

 

다시 말하지만, 패턴을 사용하면 개발자들끼리 이미 알고 있는 용어가 통용되므로, 새로 온 개발자가 더 빠르게 일할 수 있기에 필수적이다.

 

 

 

 

 

Gangs of Four (GoF) 패턴

 

Gangs of Four(GoF) 패턴은 객체 지향 소프트웨어 디자인 패턴을 체계적으로 설명한 책 "Design Patterns: Elements of Reusable Object-Oriented Software"에서 제안된 디자인 패턴들을 의미한다. 

이 책을 쓴 네 명의 저자를 가리켜 'Gang of Four'라고 부른다.

 

 

GoF 패턴은 소프트웨어 설계에서 자주 등장하는 문제들을 해결하기 위한 23개의 디자인 패턴을 설명한다.

이 패턴들은 크게 세 가지 범주로 나눌 수 있다.

 

  1. 생성 패턴 (Creational Patterns)
    • 객체 생성 메커니즘을 다루며, 객체 생성 과정에서의 유연성과 재사용성을 제공한다.
      주로 추상 객체 인스턴스화를 다룬다.
    • 예시: 싱글턴 패턴(Singleton), 팩토리 메서드 패턴(Factory Method), 추상 팩토리 패턴(Abstract Factory), 빌더 패턴(Builder), 프로토타입 패턴(Prototype)
  2. 구조 패턴 (Structural Patterns)
    • 클래스와 객체를 조합하여 더 큰 구조(시스템)를 형성하는 방법을 다룬다.
    • 예시: 어댑터 패턴(Adapter), 브리지 패턴(Bridge), 컴포지트 패턴(Composite), 데코레이터 패턴(Decorator), 퍼사드 패턴(Facade), 플라이웨이트 패턴(Flyweight), 프록시 패턴(Proxy)
  3. 행동 패턴 (Behavioral Patterns)
    • 객체나 클래스 사이의 상호작용과 책임 분배를 다룬다. 알고리즘과 흐름 제어를 정의하는 방법을 설명한다.
    • 예시: 책임 연쇄 패턴(Chain of Responsibility), 커맨드 패턴(Command), 인터프리터 패턴(Interpreter), 이터레이터 패턴(Iterator), 중재자 패턴(Mediator), 메멘토 패턴(Memento), 옵서버 패턴(Observer), 상태 패턴(State), 전략 패턴(Strategy), 템플릿 메서드 패턴(Template Method), 방문자 패턴(Visitor)

 

 

여기에 나와있는 모든 패턴을 전부 기록하진 못하겠지만.. 유명하고 특히 자주 쓰이는 패턴을 하나씩 알아보자.

 

음.. 글이 조금 길어졌으니 다음에 이어서 알아보자 ㅋㅋ..

https://guhonga.tistory.com/148

 

Singleton , Strategy , Adapter , Template Method Pattern

Singleton 패턴 Singleton 은 ‘정확히 하나의 요소만 갖는 집합’ 이라는 뜻으로, 클래스가 하나의 객체만을 생성하도록 제한한다. 이 말은 즉, 생성자를 통해서 여러 번 호출이 되더라도 인스턴스

guhonga.tistory.com