디자인 패턴이란

[디자인 패턴]

 클래스 구조를 갖는 프로그래밍을 하다보면 클래스간에 구조가 짜여지고 다양한 방법으로 객체가 생성되며 관계에 따라 여러가지 형태의 행동들이 나타난다.

  그런데 기초 설계가 제대로 되어있지 않은 상태로 프로그래밍이 시작된다면 얼마 못가 클래스 관계가 꼬일대로 꼬여 누더기 진흙탕 코드덩어리로 변하게된다. 엄청나게 뛰어난 사람이어서 초기 요구에 맞춰 잘 짜여진 클래스관계를 만든다 해도 요구 사항이 바뀌게되면 쉽게 대응하지 못한다. 이미 갈 때 까지 간 코드를 뒤엎는건 그만큼 큰 비용을 감수해야하는 행동이다.

  분명 클래스 구조의 프로그래밍을 했는데도 프로젝트가 진행되다보면 데이터의 은닉과 캡슐화, 코드의 재사용성과 확장성 등은 누더기 코드에 가려 보이지 않는다.
  제대로된 OOP를 하지 못했다는 이야기이다. 그렇다면 제대로된 OOP란 무엇을 말하는것인지 의문이 생긴다. 많은 사람들이 이에대해 고민했고 프로그램의 목적이 어떻든간에 프로그램안에 클래스들이 갖는 구조에는 일정한 '형태' 혹은 '패턴' 이 존재한다는 것을 인지하기 시작했다.
  이를 바탕으로 클래스간의 관계, 클래스간의 행동양식을 분류하고 각각에 대해 객체지향적인 설계를 따르는 노하우들이 차곡차곡 정리되어 객체지향적으로 합당한 클래스 설계 형태를 정립하기 시작했고 이를 클래스 디자인 패턴 이라 이름붙이게 되었다.

  클래스 디자인 패턴은 "'이러한 상황' 이라면 '이러한 형태의 클래스 디자인'을 하는게 대게 좋더라" 라고 말해주는것이다. 프로젝트 규모가 커지고 협업 인원이 많아질수록 이러한 기준은 일을 효율적으로 처리할 수 있게 만들어준다. 하지만 주의해야한다.
  표준화된 작업은 여러가지 상황을 고려하며 만들어지기 때문에 대체로 효율성이 떨어지기 마련이다. 또한 패턴간의 관계를 생각하지 못하면 설계를 복잡하게 만드는 요소가 되어버린다. 그렇기 때문에 클래스 설계자는 분류된 디자인 패턴의 사용 목적, 장단점, 강점과 약점에 대한 충분한 이해와 패턴간의 융합에 발생할 수 있는 문제점들을 확실히 예상할 수 있어야 하며 이를 바탕으로 디자인 패턴을 적용해야한다. 무분별한 패턴의 남용은 오히려 프로그램을 망치게된다.

 

---

[클래스 디자인 원칙]

디자인 패턴은 아무개의 코딩 기법이 뚝 하고 패턴으로 만들어진것이 아니다. 많은 연구자, 개발자들에 의해서 연구되고 축적된 지식이 패턴으로써 나타나는 것이다. 이들은 클래스의 설계에 아래 설명할 몇가지 중요한 원칙을 이해하고 있었는데, 이를 바탕으로 만들어진 디자인 패턴들에는 이 설계 원칙들이 녹아있는것을 볼 수 있을것이다.

1) Open close principle : 클래스나 모듈, 기능들에 있어서 확장에 대해서는 열려있으며 변경에 대해서는 닫혀있어야 한다.

2) Dependency inversion principle : 클래스들이 의존관계를 가질때, 높은 수준(클라이언트와 가까운쪽)의 모듈이 낮은 수준(시스템과 가까운쪽)의 모듈에 의존성을 가지면 안되며, 추상화된 대상이 상세화된 대상에 의존하면 안된다.

3) Interface segregation principle : 클라이언트는 자신이 사용하지 않는 인터페이스에 의존관계를 가지면 안된다.

4) Single responsibility principle : 클래스가 변경되어야 한다면 오직 하나의 원인만 용납된다.

5) Likov's substitution principle : 파생 클래스는 부모 클래스로 대체 가능해야 한다.

이러한 원칙들은 디자인 패턴 전에 온전한 클래스 설계에 필수적인 요소이므로 충분히 이해하는것이 중요하다.