[Design Pattern] 디자인 패턴 개념

소프트웨어를 설계할 때 디자인 패턴이 중요하다는 얘기를 항상 들었지만, 왜 중요한 것이고 어떨 때 쓰이는 것인지 몰랐다. 그러다가 이번에 추천 시스템 어플리케이션을 만들면서, 디자인 패턴의 중요성을 크게 깨달았다.
프로젝트 내의 파일들이 많아지고, 한 클래스 내에서 너무 많은 기능들이 담겨있다보니 파일을 찾기 힘들고, 코드의 가독성이 좋지 않았다. 또한 클래스의 재사용성과 확장성이 좋지 않겠다는 생각이 들었다.
이래서 소프트웨어 설계를 철저히 하고 디자인 패턴을 적용시키는 것이구나하고 깨달았다... 이번에 제대로 디자인 패턴을 공부해서 적용시켜보려고 한다.

1. 디자인 패턴이란?

소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴이다.
즉, 설계에서 발생하는 문제에 대해 해결책을 정리한 것이다. 효율적인 코드를 만들기 위한 방법론도 된다.
(패턴 : 다양한 소프트웨어들로 각기 다른 프로그램을 개발하는 과정에서 공통적인(혹은 유사한) 문제점이 존재하고 이를 처리하는 과정도 공통점이 있는데 이 공통점을 뜻한다)
같은 실수를 반복하지 않기 위해 특정 상황에서 발생하는 문제 패턴을 발견하고 이에 대한 해결 방안을 기록으로 남긴 것이다.

실제로 이러한 해결책을 정해놓으면 의사소통이 매우 원활해진다.
특히 서로 같은 패턴을 알고 있을 때 간단한 소통이 가능하다.
다른 개발자와 문제 상황에 대해서 얘기하고 이에 대한 해결책을 장황하게 얘기할 필요 없이, 디자인 패턴 이름만 얘기해도 소통이 가능할 수 있다.
예) 오리들의 다양한 행동을 전략 패턴으로 구현하고 있습니다
-> 오리의 행동들이 클래스의 집합으로 캡슐화되어 있다

또한 소프트웨어 아키텍처를 쉽게 재사용할 수 있도록 한다.

2. 구성 요소

디자인 패턴은 아래와 같이 구성된다.

구성 요소	설명
패턴의 이름	디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형
문제 및 배경	디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미
솔루션	디자인 패턴을 이루는 요소들, 관계, 협동 가정
사례	디자인 패턴의 간단한 적용 사례
결과	디자인 패턴을 사용하면 얻게 되는 이점이나 영향
샘플 코드	디자인 패턴이 적용된 원시 코드

 

3. 디자인 패턴 유형

디자인 패턴 유형은 크게 목적, 범위로 나뉜다.

목적에 따른 디자인 패턴 종류
목적 : 패턴이 무엇을 하는지 정의

• 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴
• 구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴
• 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

 

범위에 따른 디자인 패턴 종류
범위 : 패턴을 클래스에 적용하는지 객체에 적용하는지에 따라 범위가 구분되는 패턴

• 클래스 : 클래스 간 관련성(상소 관계를 다루는 패턴), 컴파일 타임에 정적으로 결정
• 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 생성

 

4. 디자인 패턴 종류

 

생성 패턴	구조 패턴	행위 패턴
Builder Prototype Factory Method Abstract Factory Singleton	Bridge Decorator Facade Flyweight Proxy Composite Adapter	Mediator Interpreter Iterator Template Method Observer State Visitor Command Strategy Memento Chain of Responsibility

구조 패턴에는 MVC, MVVM과 같은 패턴들도 포함된다.
위의 GoF가 만든 23개의 패턴들은 각각의 특징들이 있는데 해당 특징들은 추후의 포스팅에서 정리해보도록 하겠다.
GoF : Gang of Four을 말한다. Erich Gamma, Richard Helm, Ralph johnson, john Vissides 총 4명이 있다.

5. 장단점

장점

구분	장점
요구사항은 수시로 변경될 수 있다	- 요구사항 변경에 따른 소스 코드 변경을 최소화할 수 있게 해줌 - 설계 변경 요청에 따라 유연한 대처 가능
여러 사람이 협업하는 팀 프로젝트 진행할 경우	- 범용적인 코딩 스타일 적용 가능 - 업무 논의 및 디자인 문서를 작성할 때 상호 간 의사 결정에 용여로 쓰임 - 개발자 간 원활한 의사소통 가능 - 재사용을 통한 개발 시간 단축 - 소프트웨어 품질과 생산성을 높임
상황에 따라 인수인계가 필요한 경우	- 소프트웨어 구조 파악이 용이 - 직관적인 코드 사용 - 시간과 비용이 절약

단점

• 객체 지향 설계/구현 위주로 사용 (객체 지향 위주 프로그래밍의 단점이 있다 예) 처리 속도가 비교적 느림, 객체가 많으면 용량이 커짐, 설계시 많은 시간과 노력이 필요)
• 초기 투자 비용의 부담

디자인 패턴이 반드시 객체 지향에 대한 개념은 아니다. 하지만, 디자인 패턴의 내용이 거의 객체 지향을 차용한 것이 많다.
디자인 패턴이 무조건 객체 지향을 따르는 것은 아니고, 객체 지향에 적절한 패턴이 아니어도 된다.
디자인 패턴과 객체 지향은 별개로 보면 될 것 같다.

그리고 디자인 패턴을 공부한다고 해서 잘 설계된 소프트웨어를 만들 수 있는 것도 아니다.
소프트웨어의 해당 문제 상황이 무엇인지 정의하고 이에 대한 해결책이 될 수 있는 디자인 패턴을 적절하게 적용하는 것이 중요하다.

디자인 패턴이라는 것이, 개인적으로 생각하기에 개념만 익힌다고 해서 공부가 되는 것이 아닌 것 같다.
따라서 실습을 하는 것이 중요하다고 생각하는데 안드로이드 디자인 패턴을 공부할 경우 구글의 Codelabs를 사용하는 것이 좋은 것 같다.

저장소 패턴

저장소 패턴  |  Android Developers

위 링크에는 Codelabs의 Repository Pattern의 실습 예제가 있다.
혹은 구글의 Sunflower 프로젝트를 통해 디자인 패턴을 맛볼 수(?) 있다.

Sunflower

GitHub - android/sunflower: A gardening app illustrating Android development best practices with Android Jetpack.

구글의 Sunflower 프로젝트로는 Jetpack 컴포넌트와 MVVM 패턴을 공부해볼 수 있다.

디자인 패턴에는 종류가 많아서 공부할 내용도 꽤 있지만, 공부해두면 어떤 프로젝트에 어떤 디자인 패턴을 적용할 지에 반드시 도움이 될 것 같다. 그리고 정말 간단한 프로젝트가 아닌 이상 디자인 패턴은 적용해야 할 것 같다.
채용 공고의 Job Description을 봐도 디자인 패턴 적용 경험을 많은 곳에서 요구하고 있다...
디자인 패턴의 이론과 동시에 실습을 공부하며, 추천 시스템 어플리케이션에도 적용해봐야 겠다.
하지만 이론을 무조건 외우는 것이 아닌 실습과 반드시 병행하여 자연스럽게 코드에 녹아들게 해야할 것 같다.

참조

• 윤영빈 서용욱 김학배 박인상 NCS 정보처리기술사 연구회, 2022 수제비 정보처리기사 필기, 건기원
• 한빛출판네트워크
• 엠아이노의 iOS
• CodeDragon
• koyo.log