[디자인패턴-java] 디자인 패턴을 배우는 이유

내가 고민 많이하면서 개발했던 부분에 의심이 있었는데 해당 강의를 들으면서 그래도 현재 요구사항으로써는 잘못된 설계 방법은 아니었다는 것에 인정을 받은 것 같았다... 좋았다.... ㅎㅎㅎ

대학교 때 수업들으면서 그냥 저냥 들었던게 이렇게 지금에서야 뼈저리게 다가올 줄 그땐 ...몰랐지...

 

중요성을 깨달았으니 다시 정리하자!! 

 

해당 글은 "박은종의 객체지향 설계를 위한 디자인 패턴 with 자바" 1강 를 듣고 정리한 것이다. 

 

---

디자인 패턴 생겨난 이유 

 

- 소프트웨어를

    재사용할 수 있고, 유연하고, 확장성 있고, 유지보수가 용이하게

만드는 것은 매우 어려운 일임

- 기술, 재능, 노력,창의성, 직관력 등등이 필요하지만, 무엇보다 경험이 중요

 

※ 시스템을 개발하는 비용과 유지보수에 들어가는 비용을 비교했을 때, 대체적으로 유지보수에 들어가는 비용이 더 높음 -> 따라서 유지보수가 좋게 만드는게 중요함

 

 

 

- 디자인 패턴은

    이미 수많은 문제들이 존재했고, 이를 해결한 좋은 설계법들이 존재했으며, 

    네 명의 학자(GoF: Gang of Four) 들이 이러한 사례와 시스템 등을 분석하여 좋은 설계에 대한 23가지 패턴을 제안한 것이다.

 

 

- 디자인 패턴을 알고 적용할 수 있다면,

     이미 검증된 방법으로 좋은 설계를 할 수 있고,

     결합력이 높은 시스템에 대한 리팩토링을 할 수 있게 하며,

     결과적으로 유지보수에 들어가는 비용을 절약할 수 있다.                                                                                                                                                                                                                                                                                                      

 

디자인 패턴 종류

생성 패턴 (Creational Pattern)

추상 팩토리 (Abstract Factory)

빌더 (Builder)

팩토리 메서드 (Factory Method)

프로토타입 (Prototype)

싱글톤 (Singleton)

구조 패턴 (Structural Pattern)

어댑터 (Adapter)

브릿지 (Bridge)

컴포지트 (Composite)

데코레이트 (Decorate)

퍼사드 (Facade)

프라이웨이트 (Flyweight)

프록시 (Proxy)

행위 패턴 (Behavioral Pattern)

책임연쇄 (Chain of Responsibiltiy)

커맨드 (Command)

인터프리터 (Interpreter)

반복자 (Iterator)

중재자 (Mediator)

메멘토 (Memento)

옵서버 (Observer)

상태 (State)

전략 (Strategy)

템플릿 매소드 (Template Method)

비지터 (Visitor)

 

---

 

객체지향 프로그래밍과 객체지향 설계

추상화

- 어떤 영역에서 팰요로 하는 속성이나 기능을 추출하는 작업

- 데이터 구조, 표현방법에 대한 추상화

- 처리 과정에 대한 추상화 

캡슐화

- 데이터를 감싸서 외부에서 사용 가능한 부분만을 제공 (Information hiding) - private

- 사용하는 코드(클라이언트 코드)가 세부적인 사항을 알 필요가 없음 (내 로직을 보호함)

- 단순한 접근을 제공하여 오류가 생길 부분을 감소함

상속성 

: 코드 재사용을 위해서 상속을 하는 것이 아님! 

- 일반적인 개념의 객체에서 보다 구체적인 개념의 객체의 관계를 표현 

- 상속관계의 클래스는 상위 클래스의 타입을 포함

- 상위 클래스의 속성과 기능을 하위클래스는 사용하거나 재정의 할 수 있음

다형성 

- 같은 메시지, 같은 기능에 대해 각 객체가 다른 표현과 결과를 나타내는 것 

 

 

Design Heuristics

추상화 클래스 vs 구체적인 클래스 

클래스 상속 vs 객체 합성 

: 클래스 상속- 상속은 상위클래스의 성격을 포함하는 클래스를 생성하는 것이며, 따라서 결합도가 높아짐 

: 객체 합성 - 내 클래스 내에서 외부 클래스를 인스턴스화하여 사용하는 것

 

 

응집도(Cohesion)

클래스가 가지는 성격에 필요한 메소드 및 속성들만을 정의해 놓은 것으로,

클래스 성격과 맞지 않는 기능들을 포함하게 되면 응집도는 낮아지며, 이는 클래스의 성격을 모호하게 함.

따라서 클래스에는 해당 성격을 나타내는 기능들만을 포함하여 응집도를 높여야 함.

( 하나의 책임만을 가져 높은 응집도를 지녀야 함)

결합도(Coupling)

결합도는 클래스들 간의 관계를 의미하며,

결합도가 높으면 하나의 객체를 수정할 때 다른 객체를 수정해야 하는 경우가 발생하게 됨.

이는 유지보수를 어렵게 하는 원인이 되므로, 결합력을 낮추도록 노력해야 함

 

=> 잘 만들어진 소프트웨어는 응집도는 높고, 결합도는 낮아야 한다.

 

---

 

SOLID 원칙

객체에서 중요한 것 - 역할(이 클래스는 어떤기능을 해야한다), 책임(해야 하는 기능), 협력 

 

단일 책임 원칙(Single Responsibility Principle)

- 그 클래스가 해야하는 역할에 초점을 맞춰야 한다. 

하나의 클래스는 하나의 기능만을 구현하도록 한다. 즉, 어떤 클래스를 변경하는 이유는 하나여야 한다. 

한 클래스에서 여러 기능을 제공하게 되면 유지보수가 어려움 

 

-> 예를 들어, Student 클래스에 유틸리티 기능 등 Student 와 관련 없는 기능들을 포함하면 안된다는 것이다.

이는 Student 클래스가 변경되는 이유가 Student와 관련 없는 다른 이유로 변경될 가능성이 있다는 것이며, 유지보수를 어렵게 하는 원인이 된다는 것이다.

개방 폐쇄의 원칙(Open-Closed Principle)

객체 자신의 수정에 대해서는 유연하고, 다른 클래스가 수정될 때는 영향을 받지 않는다.

인터페이스나 추상클래스를 통해 접근 하도록 하여, 유연한 대처를 할 수 있도록 한다.

 

->예들 들어, 자바 JDBC 같은 경우에는 JDBC를 사용한 클라이언트 코드 입장에서는 내부 데이터베이스가 어떤 것으로 변경되었든 영향을 받지 않으며, 데이터베이스는 언제든지 필요에따라 변경이 가능할 수 있다.

리스코프 치환 원칙 (Liskov Subsititution Principle)

하위 클래스는 항상 상위 클래스로 교체 될 수 있어야 한다. 

즉 하위 클래스는 상위 클래스의 모든 기능을 포함하고 있어야 한다.

의존 역전 원칙 (Dependency Inversion Principle)

의존 관계는 구체적인 것보다 추상적인 것(인터페이스, 추상클래스)에 의존한다.

구체적인 것은 이미 구현되어 있고 추후 변할 가능성이 크다는 것을 의미하기 때문이다.

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

제공하는 기능에 대한 인터페이스에만 종속적이어야 한다. 

하나의 객체가 여러기능을 제공한다면,  이를 사용하는 클라이언트 코드는 불필요한 기능을 사용해야 할 수있다. 이러한 상황을 피하기 위해, 여러 인터페이스로 기능들을 분리하여 클라이언트에 불필요한 기능을 제공하지 않도록 한다.

 

---

클래스 다이어그램

: 여러 클래스의 상호관계를 나타내는 다이어그램 ( 표기법 중에는 OMG, UML이 있음 )

: 클래스 간의 관계를 설계할 때  유용

연관관계

클래스 간에 연관 관계가 있음

단방향 연관관계 화살표(→)로 표시

양방향 연관관계 직선(-)으로 표시

클래스 간의 연관된 개체 수를 표현하는 경우 선 끝에 다중성(multiplicity)을 나타냄

 

아래 그림은, 

Student 는 Subject를 한개 이상 가지고 있는 단방향 관계를 나타낸 것이다. 

코드  상으로는 다음과 같다. 

 

class Student{

 ArrayList<Subject> subjects;

}

의존관계

연관관계 보다는 짧은 life time을 가지며, 프로그램 내에서 참조 변수가 매개변수나 지역 변수로 구현됨

즉, A와 B클래스가 연관 관계를 맺고 있으나, 경우에 따라서 그 연관 관계의 클래스가 자주 바뀔 수 있다는 것이다.

 

아래 그림에서 보면,

takeBus 에서의 Bus 파라미터, ( 1234 번 버스, 3456 번 버스 .... )

takeUsbway 에서의 Subway 파라미터가 ( 5호선, 7호선.... )

Student 클래스와 연관관계를 맺고 있지만 그 주기가 길지 않다는 것이다. 

 

집합관계

클래스 간의 포함관계를 나타냄

집약관계

클래스 다이어그램에서 마름모◇로 표시

전체 객체와 부분 객체의 life time이 독립적이므로, 전체 객체가 사라져도 부분 객체는 사라지지 않음

ex) 공유하는 리소스

전체 객체가 생성될 때 매개변수로 전달 받음

합성관계

클래스 다이어그램에서 채워진 마름모◆로 표시

전체 객체의 life time에 부분 객체가 종속되어, 전체 객체가 사라지면 부분 객체도 사라짐

ex) 주로 멤버 변수로 사용

전체 객체 생성자에서 부분 객체가 생성됨

일반화 관계

클래스의 상속관계

실체화 관계

인터페이스에 대하여, 구체적 기능을 구현해야할 책임이 있는 관계

접근 제어자 표시

public	+	모두 접근 가능
protected	*	같은 패키지, 상속관계의 클래스에서 접근 가능
default	~	같은 패키지 접근 가능
private	-	동일한 클래스에서만 상속 가능