0. 디자인 패턴에 대해

1. 디자인 패턴?

• 훌륭한 객체지향 디자인이라면 재사용성, 확장성, 관리의 용이성을 갖춰야 한다
• 훌륭햔 객체지향 디자인 품질을 갖추고 있는 시스템을 만드는 방법을 제공해 준다

2. 디자인 원칙

 

1) 디자인을 잘 하기 위해서 아래와 같은 사항을 고려하는게 좋다.

 

  (1) 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.

• 즉, 달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 캡슐화한다.
• 모든 디자인 패턴의 기반을 이루는 원칙이다.
• 코드를 변경하는 과정에서 의도하지 않은 일이 일어나는 것을 줄인다.
• 시스템의 유연성을 향상시킬 수 있다.

  (2)구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.

• 상위 형식에 맞춰서 프로그래밍을 한다는 것을 뜻한다.
• 반드시 자바의 인터페이스를 사용하라는 것은 아니다.
• 실제 실행시에 쓰이는 객체가 코드에 의해 고정되지 않도록, 어떤 상위 형식에 맞춰서 프로그래밍 함으로써 다형성을 활용해야 한다.

  (3) 상속보다는 구성을 활용한다.

• 유연성을 크게 향상시킬 수 있다.

2) SOLID 원칙(위의 내용을 구체화한 규칙)

 

  (1) Single Responsibility Principle : 단일 책임 원칙

     - 모든 클래스는 하나의 책임만을 가지며 그 클래스는 그 책임을 완전히 캡슐화하여야 한다.

 

  (2) Open Close Principle : 개방 - 패쇄 원칙

    - 소프트웨어의 클래스 모듈 그리고 기능은 확장엔 열려 있어야하며 변경에는 닫혀 있어야한다.

 

  (3) Liskov's Substitution Principle : 리스코프 교체 원칙

    - 자식클래스는 언제나 부모 클래스의 역할을 대체할 수 있어야한다. 즉, 자식 클래스는 부모 클래스의 책임을

      무시하거나 재정의하지 않고 확장만 수행하도록 해야한다. (오버라이딩은 가급적 피하는게 좋다는말)

 

  (4) Interface Segregation Principle : 인터페이스 격리 원칙

    - 클라이언트가 사용하지 않는 인터페이스 때문에 클라이언트가 영향을 받아서는 안된다. 즉, 자신이 사용하지 않는        인터페이스는 애초에 구현하지 않는게 좋다.

 

  (5) Dependency inversion Principle : 의존관계 역전 법칙

    - 고수준의 모듈은 저 수준에 모듈에 의존하여서는 안돼고 두 모듈은 반드시 추상적이여야 한다.

    - 추상적 개념은 세부적인 것에 의존하여서는 안되며 세부적인 사항들은 추상적이여야 한다.

    - 말 그대로 자신보다 변하기 쉬운 것에 의존하지 말라는 말이다.

    - Client가 Abstraction에 의존해야지 Concretion에 의존하면 안된다. (그냥 MVC에서 Service와 ServiceImple의

                                                                                            관계를 생각해보면 될거같다.)

 

3. 결론

  사실 디자인 패턴은 객체간의 관계를 정의하는 것이라고 볼 수 있다. 그리고 이 관계를 정의하기 위해서 캡슐화와 상속을 통한 다형성 그리고 이를통한 의존관계를 주로 이야기하는데, 이 관계를 통해 시스템의 유연성을 확장시키는데 도움을 주는 것이라고 볼 수 있다.