Index
- 디자인 패턴이란?
- 디자인 패턴의 분류
- 디자인 패턴과 좋은 설계
Introduction
회사에서 일을 진행하면서, 유지보수 혹은 기능 확장을 할 때마다, 기존 구조에 불편함을 느끼고 있었다. 이러한 이유는 아마도, 개체지향 프로그래밍의 이점을 활용하지 않고, 설계 및 개발을 진행했기 때문이라 생각한다. ( 능력부족, 생각부족 ....)
요번에 프로젝트에 비지니스 로직이 대폭 확장되어야하는 상황에서 기존의 방식대로 개발하기에는 유지보수에 굉장히 어려워질 것으로 판단해서 좋은 구조를 찾다보니, 디자인패턴의 이야기까지 다다랐다.
이제 막 디자인 패턴을 공부하고 적용시켜보는 도입단계이기도 하고, 도입 후, 유지보수 일을 진행해보지 않아서, 얼마나 편한지? 기존과 어떻게 다른지 체감은 하지 못했지만, 훨씬 더 편하게(직관적으로) 유지보수 할 수 있지 않을까 생각한다.
또 기존 프로젝트를 얼마나 확장성이 안 좋은지 대략적으로나마 이해하게 되었다. 프로젝트를 진행할 때, 설계의 중요성을 다시 한 번 깨달았다.
( 작은 기능을 추가하더라도, 기존 코드와의 확장성 여러가지 요소를 고려해야할 필요성을 느꼈다. 이같은 부분에서는 늘 내가 하는 프로젝트의 동작 구조 는 인지하고, 고민하고 있어야 한다고 생각한다.)
자 그럼 이제부터 디자인 패턴의 개념부터 정리해보자
디자인패턴이란?
디자인 패턴이란 프로그램을 개발하는 과정에서 빈번하게 발생하는 구조적인 문제를, 어떠한 클래스,인터페이스 구조를 활용하여 개체 지향적으로 개발하는 방식이라고 할 수 있다.
이 디자인 패턴이란, 1+1=1 이다 라는 것처럼 딱 떨어지는 것이 아니다.
( 즉, 무조건 이렇게 해야해! 라고 정해져있는 것이 아니다)
여러 현상을 겪고 그것을 프로그램으로 구현할 때 공통적으로 생긴 문제들을 해결한 어떤 방식을 일컫는 말이다.
여기서 중요한 점은, 디자인 패턴이란 어떤 프로그램을 만드는 여러 방법 중 한 방법이며, 반드시 따라야 하는것이 아니라는 점이다. 나의 문제 상황에 맞춰 새로운 패턴을 만들 수도 있다는 이야기이다.
(대체적으로 이미 많은 방식들이 있어서, 새로운 패턴을 만들어 내는 것이 가능할지는 모르겠지만 말이다.)
그렇다면 디자인 패턴의 종류에는 어떤 것들이 있을까?
디자인 패턴의 종류
디자인 패턴의 종류는 크게 3가지로 분류할 수 있다.
- 생성 패턴
- 객체 인스턴스를 생성하는 패턴으로, 클라이언트와 클라이언트가 생성해야하는 객체 인스턴스 사이의 연결을 끊어 주는 패턴이다.
- Ex) 싱글턴, 빌더, 추상 팩토리, 팩토리 메소드, 프로토 타입
- 행동 패턴
- 클래스와 객체들이 상호작용하는 방법과 역할을 분담하는 방법을 다루는 패턴이다.
- Ex) 템플릿 메소드, 싱글턴, 반복자, 옵저버, 전략
- 구조 패턴
- 클래스와 객체를 더 큰 구조로 만들 수 있게 구성을 사용하는 패턴이다.
- Ex) 프록시, 퍼사드, 컴포지트, 어댑터, 데코레이터
3가지로 분류되어있는 것을 확인할 수 있는데, 아직 패턴에 대한 설명이 와닿지는 않는다. 앞으로 하나씩 공부해 나가면서 분류의 의미를 알아가보도록 해야겠다.
요번에 사내 프로젝트에 적용한 패턴은 팩토리패턴 (Factory method), 전략패턴 (Strategy) 두 가지이니, 간단하게 두 가지 정의를 보고 이해해보자. 다음 글에 구체적인 내용을 작성할 예정이다.
- 팩토리 메서드 패턴 : 객체 생성할 때, 필요한 인터페이스를 만듭니다. 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정한다. 팩토리 메서드 패턴을 사용하면 클래스 인스턴스를 만드는 일을 서브클래스 에게 맡기게 된다.
- 사내 프로젝트는 Spring boot로 진행되었는데, 상황마다 필요한, interface의 구현체들이 여러개 존재하였다. 이 때, 팩토리 메소드를 호출하여, 필요한 interface 구현체들을 얻어 활용하였다.
- 전략 패턴: 알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘 군을 수정해서 쓸 수 있게 해줬다. 전략패턴을 사용하면, 클라이언트로부터 알고리즘을 분리해서 사용할 수 있다.
- 사내 프로젝트에서, 상황마다 다른 로직이 필요했고, 행위는 같은 것이였다. 예를들어 계약서를 작성하는데, 계약서에 특정 조건이 붙을 때, 다르게 수행해야하는 알고리즘들이 있었다. 이 때 전략패턴을 활용하여 개체간에 의존성을 최소화하고, 런타임 중에 알고리즘을 바꿔서 사용할 수 있도록 했다.
디자인 패턴과 좋은 설계
디자인 패턴을 공부하면서 좋은 설계가 무엇인지 고민하고 여러 글들을 읽어보았다.
우선 내가 생각하는 좋은 설계란
너무나 당연한 이야기지만, 유지보수에 용의하고, 기능 확장에 유연하게 대응할 수 있는 것을 좋은 설계라고 생각한다. 깊게 고민해보고 생각해본적이 없어서 지금 떠오르는건 요정도다.
여타 따른 글들에서는 좋은 설계란 무엇이라고 말할까?
협력하는 개체들 사이의 의존성을 조절함으로써 변경에 용이하게 만드는 것을 의미한다.
개체지향의 본질은 개체들 간의 공동체를 창조하는 일이다.
핵심은 적절한 협력을 식별하고, 협력에 필요한 역할을 정의 한 후, 역할을 수행할 수 있는 적절한 개체에게 적절한 책임을 할당하는 것이다.
좋은 설계인지 판단하는 척도는 다음과 같다.
- 캡슐화 : 불안정한 부분과 안정적인 부분을 분리해서 변경의 영향 통제 가능하다.
- 캡슐화는 변경 가능성이 높은 부분을 개체 내부로 숨기는 추상화 기법이다.
- 불안정한 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화 하는것이다.
- 가장 대표적인 예가 객체의 인터페이스 와 구현을 분리하는 것
- 응집도 : 모듈에 포함된 내부 요소들이 연관되어 있는 정도를 나타낸다.
- 하나의 목적을 위해 긴밀하게 협력한다면, 높은 응집도를 갖는다.
- 모듈 내의 요소들이 서로 다른 목적을 추구하면, 낮은 응집도를 갖는다.
- 유지보수할 때, 높은 응집도는 수정할 곳이 적지만, 낮은 응집도는 여러곳을 수정해야할 수 있다.
- 결합도 : 의존성 정도를 나타내며, 다른 모듈에 얼마나 많은 지식을 갖고 있는지 나타내는 척도이다.
- 내부 구현을 변경했을 때, 외부 다른 모듈에 영향을 미치는 경우 결합도가 높다고 표현한다.
- 높을 수록, 유지보수할 때 고칠부분이 많아진다
캡슐화를 지키면 , 모듈 안의 응집도는 높아지고, 모듈 사이의 결합도는 낮아진다고 한다.,
우선 이정도로만 개념을 잡고 각 디자인 패턴을 이해해보자.
Reference
https://eunjin3786.tistory.com/324
https://refactoring.guru/ko/design-patterns/factory-method
https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS8616098823
