[JSP] 디자인 패턴 및 SOLID 원칙

 

디자인 패턴(건축쪽에서 사용하는 용어)

 

 

이름의 중요성.

디자인 패턴이란 기존 환경 내에서 반복적으로 일어나는 문제들을 어떻게 풀어나갈 것인가에 대한 일종의 솔루션 같은 것입니다.
디자인 패턴 계의 교과서로 불리는 [GoF의 디자인패턴]에서는 객체지향적 디자인 패턴의 카테고리를

---

  "생성 패턴(Creational Pattern)"
  - 객체를 생성하는데 관련된 패턴들
    객체가 생성되는 과정의 유연성을 높이고 코드의 유지를 쉽게 함
    
, "구조 패턴(Structural Pattern)"
  - 프로그램 구조에 관련된 패턴들
    프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는데 활용할 수 있는 패턴들
    
, "행동 패턴(Behavioral Pattern)" 
  - 반복적으로 사용되는 객체들의 상호작용을 패턴화 해놓은 것들
  

---

3가지로 구분하고 있습니다.


객체지향 소프트웨어를 '잘' 설계한다는 것은 쉬운 일이 아니다.
게다가, 재사용할 수 있는 객체지향 소프트웨어를 만드는 것은 더 힘들기 때문에
설계를 할 때에는 지금 당장 갖고 있는 문제를 해결할 수 있어야 
하지만, 나중에 생길 수 있는 문제나 추가된 요구 사항들도 수용할 수 있도록 일반적이고 포괄적이어야 합니다.

이를 위해 설계할 때 고려사항으로 SOLID 원칙 등 객체지향적 소프트웨어 설계 방법론이 있고, 현업에서는 이에 따라 개발하기 위해 노력하고 있습니다.
개발의 경험이 쌓이다 보면 자신들이 전에 사용했던 코드와 유사한 기능을 구현해야 해서 이전의 코드를 들여다보는 경험을 종종 하게 됩니다.

그러다 전에 사용했던 해결책을 그대로 반복해서 사용하기도 하고, 변형해서 쓰기도 하고, 혹은 상황에 맞지 않다고 판단하여 다른 방향의 구현을 고민하기도 합니다.

디자인 패턴은 설계자로 하여금 재사용이 가능한 설계는 선택하고, 재사용을 방해하는 설계는 배제하도록 도와줍니다.
또한 패턴을 쓰면 이미 만든 시스템의 유지보수나 문서화도 개선할 수 있고, 클래스의 명세도 정확하게 할 수 있으며, 객체 간의 상호작용 또는 설계 의도까지 명확하게 정의할 수 있습니다.
간단하게 말해서 디자인 패턴은 설계자들이 "올바른" 설계를 "빨리" 만들 수 있도록 도와줍니다.

 

 

---

SOLID 원칙

 

S : SRP(Single Responsiblity Principle 단일 책임 원칙)

 - 소프트웨어의 설계 부품(클래스, 함수 등)은 단 하나의 책임만을 가져야 한다.
 - 응집도는 높고 결합도는 낮은 프로그램을 뜻한다.
 - 하나의 클래스, 메서드에 많은 기능을 넣지 말고, 하나의 기능에 집중
   그렇지 않다면 유지보수 시 너무 힘들다.

 

 

 

O : Open-Closed Principle (개방-패쇄 원칙)

 - 기존의 코드를 변경하지 않고(Closed) 기능을 수정하거나 추가할 수 있도록(Open) 설계해야 한다.
   OCP에 만족하는 설계를 할 때 변경되는 것이 무엇인지에 초점을 맞춘다.
   자주 변경되는 내용은 수정하기 쉽게 설계 하고, 
   변경되지 않아야 하는 것은 수정되는 내용에 영향을 받지 않게 하는 것이 포인트다. 
   이를 위해 자주 사용되는 문법이 인터페이스(Interface)이다.
   유지보수 비용을 줄여주고 코드의 가독성 또한 높아지는 효과를 얻을 수 있다.

 

 

L : Liskov Substitution Principle (리스코프 치환 원칙)
 
 - 자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다.  - 리스코프 치환 원칙은 MIT 컴퓨터 사이

   언스 교수인 리스코프가 제안한 설계 원칙이다.
   부모 클래스와 자식 클래스 사이의 행위에는 일관성이 있어야 한다는 원칙이며,
   이는 객체 지향 프로그래밍에서 부모 클래스의 인스턴스 대신 자식 클래스의 인스터스를 사용해도 문제가 없어야

   한다는 것을 의미한다.

 

 

 

I : Interface Segregation Principle (인터페이스 분리 원칙)

  - 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다. 하나의 일반적인 인터페이스보다는,

    여러개의 구체적인 인터페이스가 낫다.
  - 우리는 스마트폰으로 전화, 웹서핑, 사진 촬영 등 다양한 기능을 사용할 수 있다. 
    그런데 전화를 할 때에는 웹서핑, 사진촬영 등 다른 기능은 사용하지 않는다. 
    따라서 전화기능과 웹서핑 기능 사진 촬영 기능은 각각 독립된 인터페이스로 구현하여,
    서로에게 영향을 받지 않도록 설계해야 한다. 
    
  - 이렇게 설계된 소프트웨어는 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정,

    재배포를 쉽게 할 수 있다.

 

 

D : Dependency Inversion Principle (의존 역전 원칙)

  - 의존 관계를 맺을 때, 변화하기 쉬운것 보단 변화하기 어려운 것에 의존해야 한다는 원칙이다. 
  - 변화하기 어려운 것이란 추상적인 것을 말한다. 
    객체지향적인 관점에서 보자면 변화하기 쉬운것이란 구체화 된 클래스를 의미하고, 변화하기 어려운 것은

    추상클래스나 인터페이스를 의미한다

  - 의존관계를 맺을 때, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺는다는 것을 의미한다.