디자인 패턴

소프트웨어는 변한다.

개발자들은 설계-> 개발 -> 배포 과정을 통해  완성된 SW를 배포했는데

복잡하게 구축된 이 논리 구축물을 변경해야 되는 일을 많이 겪게 된다.

하나를 고치면 또 다른 것에 영향을 미쳐서 다 찾아서 고쳐야 하며,

테스트도 다시 해야 한다.

애초에 어떻게 만들어 놓아야

이러한 피치 못할 변화들에 대해서

스트레스 안 받고, 시간 안 뺏길 수 있을까를 많이 고민하며 여러 디자인 패턴이 생겼다.

High Cohesion, Low Coupling (높은 응집도와 낮은 결합도)
높은 응집도
-> 하나의 클래스가 하나의 책임을 갖는다. 이 말인즉 하나의 클래스가 여러 개의 책임을 가지고 있지
않아야 하며, 하나의 책임이 여러 클래스에 걸쳐 있지 않아야 한다.
SRP; Single Responsibility Principle (단일 책임의 원칙)

낮은 결합도
클래스간에 의존성이 낮아야 한다.

바람 둥이 남자가 여러 여자들을 만나며
여러 여자들과 서로 "너 없인 못살아" 라는 관계가 되어 버렸다고 하면
인생이 복잡해지듯이,
클래스도 서로 없이 못사는 관계가 많으면 유지보수가 피곤해진다.

DIP : Dependency Inversion Principle (의존 관계 역전의 원칙)
A  라는 클래스에서 B라는 클래스를 사용하고 있다.

class A {
  B b = new B();
  int hey() {
      b.hey();
  }
}

위와 같이 해도 되지만, interface를 중간에 두고 사용하면 다음과 같이 할 수 있다.

A가 사용해야 될 B 의 기능들을 모아놓은 interface를 만든다.

interface MyFunc {
     public void hey();
}

B는 위 인터페이스를 구현한다.

class B implements MyFunc {
     public void hey() { }
}

그럼 처음 코드는 다음과 같이 변경 가능하다.

class A {
  MyFunc myFunc = new B();
  int hey() {
      myFunc.hey();
  }
}

class C 를 만들어서 역시 MyFunc를 구현하면
A에서는 쉽게 B->C로 갈아탈 수도 있고, B의 내용을 변경해도
서로 연결된 클래스에 영향을 적게 미친다.

그러나, 인터페이스 자체를 변경해야 될 경우, 구현한 모든 클래스를 고려해야 되긴 하다.

* Spring DI (Dependency Injection)
이름이 비슷해서 언급하고 넘어간다.
DI 란 외부 설정 파일 등을 통해 객체 내의 다른 객체 레퍼런스를 생성해서 넣어주는 방식이다.

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

인터페이스는 하나에 많은 함수를 두기 보다
필요한 뭉테기로 나눠서 여러 개의 인터페이스 두는게 낫다.

LSP : Liskov Substitution Principle (리스코프 대체 원칙)

OCP : Open Closed Principle (개방 페쇄 원칙)