1. Software Design Pattern

▣ 디자인 패턴(design pattern)이란?

영어 위키백과에 있는 정의를 통해 디자인 패턴의 정의가 무엇인지 알아보겠습니다.

 In software enginerring, a software design pattern is a general, reusable solution to a commonly ocurring problem within a given context in software design. It is not a finished design that can be transformed directly int 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 desigining an application or system.

https://en.wikipedia.org/wiki/Software_design_pattern

 

가장 중요한 핵심은, 소프트웨어 디자인 패턴(줄여서 디자인 패턴이라고 하겠습니다)이란 소프트웨어 디자인에서 발생하는 일반적인 문제를 해결하기 위한 일반적이고 재사용 가능한 솔루션이라는 것입니다. 즉, 이러한 패턴들은 특정 소스코드나 기계어로 직접적으로 변환되는 것이 아니라, 매우 다양한 상황에 대해서 어떻게 문제를 해결해 나갈지에 대한 템플릿(미리 짜여진 틀)이나 설명을 제공해 주는 것이라고 할 수 있습니다.

 

디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software, 1994)이라는 책을 쓴 사람들은 Gang of Four(GoF)라고 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides이라는 4명의 컴퓨터 과학자들입니다.  디자인 패턴이 무엇이고, 그들이 이 책을 쓴 이유가 무엇인지 좀 더 자세히 알아보기 위해 책 서문의 일부를 인용해보겠습니다.

The design patterns require neither unusual language features nor amazing programming tricks with which to astound your friends and managers. All can be implemented in standard object-oriented languages, though they might take a little more work than ad hoc solutions. But the extra effort invariably pays dividends in increased flexibility and reusability.

Once you understand the design patterns and have had an "Aha!" (and not just a "Huh?") experience with them, you won't ever think about object-oriented design in the same way. You'll have insights that can make your own designs more flexible, modular, reusable, and understandable—which is why you're interested in objectoriented technology in the first place, right?

A word of warning and encouragement: Don't worry if you don't understand this book completely on the first reading. We didn't understand it all on the first writing! Remember that this isn't a book to read once and put on a shelf. We hope you'll find yourself referring to it again and again for design insights and for inspiration.

 

요약해 보자면

● 디자인 패턴이란 놀라운 프로그래밍 트릭이나 일반적이지 않은 언어 특징을 필요로 하지 않고, 표준 객체 지향 언어로 실행될 수 있으며

 

●  이 디자인 패턴들을 이해하고 난 뒤에는 기존과 같은 방식의 객체 지향 방법론이 아닌, 더 유연하고, 모듈화 되며, 재사용 가능하며, 가독성 높은 자신만의 소프트웨어 디자인을 할 수 있고

 

●  이 디자인 패턴들을 한 번에 이해하지 못하더라도 좌절하지 말라는 것입니다.

 

적어도 디자인 패턴이 무엇이고 어떤 목적으로 만들어 졌는지는 이제 조금은 이해할 수 있을 것 같습니다.

 

▣ 좋은 소프트웨어란?

1968년 독일 가미시에서 열린 첫 번째 소프트웨어 공학 학회에서 F.L 바우어가 처음으로 '소프트웨어 위기(software crisis)'라는 용어를 사용했습니다. 또한 네덜란드의 전설적인 컴퓨터 과학자인 다익스트라(Edsger Wybe Dijkstra)가 1972년 튜링상 수상 당시 이런 말을 했다고 합니다.

컴퓨터 과학자, 에츠허르 다익스트라(1930 - 2002)

 소프트웨어 위기의 주요한 위기는 컴퓨터 성능이 몇수십배나 더 강력해졌기 때문입니다! 심하게 말하면, 컴퓨터가 없었을 때는 프로그래밍에는 전혀 문제가 없었습니다; 느린 컴퓨터 몇 개 뿐이었을 때는 프로그래밍이 조금 문제가 되었고, 이제는 거대한 컴퓨터에 프로그래밍도 비슷하게 거대한 문제가 되었습니다.

 

이 말은 현재 진행형인 것 같습니다. 하드웨어 자원이 급속히 향상되면서, 우리는 점점 컴퓨터에 더 많은 요구들을 하고 있습니다. 예를 들어, 컴퓨터가 개발되던 초기에는 간단한 워드 프로세싱 작업이나 사칙연산들을 수행했겠지만, 현재는 컴퓨터로 게임, 그래픽 작업, 대규모 데이터베이스 저장 등 초기의 컴퓨터의 하드웨어 성능으로는 상상할 수 없는 작업들을 하고 있죠. 이러다보니 소프트웨어 개발이 복잡해지고, 그 규모가 방대해지는 것은 당연한 것 일겁니다.

 

소프트웨어가 복잡해지고, 규모가 거대해지는 것은 소프트웨어 위기의 원인으로 꼽히고 있습니다. 소프트웨어 개발 납기일에 맞추기 위해 무리한 일정을 계획하게 되고, 그러다 보니 효율적이지 못한 소스코드를 작성하게 되어 성능 및 유지 보수성이 하락하게 됩니다. 무리한 일정으로 겨우 짜여진 소스코드들이 어찌저찌 소비자들에게 전달되어 사용되더라도, 그것들을 유지, 보수하는데 있어서 큰 비용이 발생할 것은 자명합니다.

 

좋은 소프트웨어란 결국 소비자가 원하는 기능을 다하는 것 뿐만 아니라, 효율성, 유지보수성, 재사용성, 가독성 등을 모두 갖춘 소프트웨어를 말합니다. 좋은 소프트웨어는 중복이 없고, 다른 개발자가 봤을 때 이해하기가 쉬워 유지, 보수, 수정이 간편합니다. 결국 이런 장점들은 향후 비용감소로 이어집니다.

▣ 디자인 패턴 분류

GoF는 디자인 패턴을 크게 생성 패턴(Creation Patterns), 구조 패턴(Structural Patterns), 행위 패턴(Behavioral Patterns)으로 나뉘고 또 각각의 세부적인 패턴으로 나누어 총 23가지로 정리했습니다.

 

■ 생성 패턴 : 객체의 생성 과정과 연관된 패턴

- 추상 팩토리(Abstract Factory)

- 빌더(Builder)

- 팩토리 메소드(Factory Method)

- 프로토타입(Prototype)

- 싱글턴(Singleton)

 

■ 구조 패턴 : 클래스나 객체의 합성/집약에 관련된 패턴

- 어댑터(Adapter)

- 브리지(Bridge)

- 컴포지트(Composite) 

- 데코레이터(Decorator) 

- 퍼사드(Façade) 

- 플라이웨이트(Flyweight) 

- 프록시(Proxy)

 

■ 행위 패턴 : 클래스나 객체들이 상호작용하는 방법과 책임을 분산시키 는 방법을 정의하는 패턴

- 책임 연쇄(Chain of Responsibility)

- 커맨드(Command)

- 인터프리터(Interpreter)

- 반복자(Iterator)

- 미디에이터(Mediator)

- 메멘토(Memento)

- 옵서버(Observer)

- 스테이트(State)

- 스트래티지(Strategy)

- 템플릿 메소드(Template Method)

- 비지터(Visitor)

 

여담이지만 정보처리기사 자격증을 공부할 때 생성패턴의 제일 앞글자를 따서 '생빌프로팩앱싱' 이런 식으로 외웠던 것이 기억이 나네요. 하여튼 위에 있는 패턴들을 전부 다루진 않을 것이고, 이 중 자주 쓰이는 것들 위주로 다루겠습니다. (그 이유는 학교에서 일부만 배워서 그렇습니다) 포스팅 예정인 주제들은 위의 볼드 처리된 것 들입니다. 기회가 된다면 볼드 처리되지 않은 주제들도 다루어 보겠습니다.

 

※ 디자인 패턴 주제의 포스팅에서 Java의 사용법이나 문법에 대해서는 자세히 다루지 않을 생각입니다. Java의 문법에 대해 알고 싶으시거나 복습하고 싶으신 분들은 아래 위키독스링크에 잘 나와있으니 참고하시면 좋을 것 같습니다.

https://wikidocs.net/book/31

점프 투 자바

 

참고자료

[1] 조용주, 고급객체지향프로그래밍