[CS]14. 디자인 패턴 & UML 다이어그램

디자인 패턴(Design Pattern)은 소프트웨어 디자인에서 문제 해결을 위해 반복적으로 사용되는 설계 기법이며, 설계 방법이다. 디자인 패턴을 사용하면 단지 코드만 재사용하는 것이 아니라, 소프트웨어 디자인의 일관성, 호환성, 재사용성을 높여 유지 보수성을 높게 유지할 수 있다.(프로그램의 복잡성이 증가할 때 매우 유용하다.) 디자인 패턴을 프로젝트에 상시 적용하여야 하는 것은 아니지만, 추후 재사용과 호환, 유지 보수시 발생하는 문제 패턴을 예방하기 위하여 패턴을 만들어 둔 것이다.

클래스 간의 관계를 설명하는 것이 디자인 패턴. 객체 지향적으로 프로그래밍을 하기 때문에 현실 세계에 있는 것을 컴퓨터로 가지고 와야 함...

+Design Smells

design smell이란 나쁜 디자인을 나타내는 증상같은 것으로, 4가지 종류가 있다.

1. Rigidity(경직성): 하나를 변경하고 싶을 때 다른 것까지 같이 변경해야 한다면 경직성이 높다고 할 수 있다.
2. Fragility(취약성): 어떤 부분을 수정하였는데 관련이 없는 부분에 영향을 주면 취약성이 높다고 할 수 있다. (관리 비용이 높고 신뢰도가 낮은 코드가 된다)
3. Immobility(부동성): 부동성이 높다면 재사용하기 위해서 시스템을 분리해서 컴포넌트를 만드는 것이 어렵다.
4. Viscosity(점착성): 점착성은 디자인 점착성과 환경 점착성으로 나눌 수 있다. 시스템에 코드를 추가하는 것보다 핵을 추가하는 것이 더 쉽다면 디자인 점착성이 높다고 할 수 있다. 환경 점착성은 개발환경이 느리고 효율적이지 못할 때 나타난다.

디자인 패턴의 원칙(SOLID 원칙)

1. Single Responsibility Principle
2. 하나의 클래스는 하나의 역할만 해야 함. 즉, 클래스는 오직 하나의 이유만으로 수정이 되어야 한다는 것을 의미한다.
3. Open - Close Principle
4. 자신의 확장(상속)에는 열려있고 주변의 변화에는 닫혀 있어야 한다는 것을 의미한다.
5. Liskov Substitution Principle
6. 자식이 부모의 자리에 항상 교체될 수 있어야 한다. 즉, base 클래스에서 파생된 클래스는 base 클래스를 대체해서 사용할 수 있어야 한다.
7. Interface Segregation Principle
8. 인터페이스가 잘 분리되어서, 클래스가 꼭 필요한 인터페이스만 구현하도록 해야 한다. 즉, 사용하지 않는 메소드에 의존하면 안 된다.
9. Dependency Inversion Property
10. 자신보다 변화하기 쉬운 모듈(하위 모듈)에 의존하면 안 된다.

디자인 패턴의 분류(목적을 잘 알아두는 것이 중요하다.)

1. 생성 패턴(Creational Pattern) - 객체의 생성 방식을 결정한다. 클라이언트와 그 클라이언트가 생성해야 하는 객체 인스턴스 사이의 연결을 끊어주는 패턴이다. 이 패턴은 객체를 생성하는 방법을 추상화하고, 유연하게 객체를 생성할 수 있다. ex) DBConnection을 관리하는 Instance를 하나만 만들 수 있도록 제한하여, 불필요한 연결을 막음.
2. 구조 패턴(Structural Pattern) - 객체 간의 관계를 조직한다. 클래스나 객체를 조합해 더 큰 구조를 만들 때 사용하는 패턴이다. 객체 사이의 관계를 더 쉽게 이해할 수 있도록 도와준다. ex) 2개의 인터페이스가 서로 호환이 되지 않을 때, 둘을 연결해주기 위해서 새로운 클래스를 만들어서 연결시킬 수 있도록 함.
3. 행동 패턴(Behavioral Pattern) - 객체나 클래스 사이의 알고리즘 및 역할 분배에 관련된 패턴이다. 객체의 행위를 조직하고 관리하고 연합하여 코드의 유지보수성이나 재사용성을 높인다. ex ) 하위 클래스에서 구현해야 하는 함수와 알고리즘을 미리 선언하여, 상속시 이를 필수로 구현하도록 한다.

생성 패턴

- 싱글턴 패턴: 어떤 클래스가 단 하나의 인스턴스만을 갖도록 보장하며, 이 인스턴스에 대한 전역적인 접근을 제공하는 방법이다. 싱글턴 패턴은 다수의 클라이언트에서 하나의 인스턴스를 공유하여 사용해야 하는 경우에 사용한다.

- 추상 팩토리 패턴:서로 관련된 객체들을 생성하는 인터페이스를 제공하는 방법으로, 추상 팩토리 패턴은 객체 생성과 관련된 복잡성을 숨기기 위해 사용한다.

- 팩토리 메소드 패턴: 객체 생성을 서브 클래스에서 결정하도록 하는 방법으로, 객체 생성과 관련된 복잡성을 숨기기 위해 사용된다. 서브 클래스 수가 많아지면 관리하기 어려워지고 객체 생성에 대한 일관성이 떨어질 수 있어서 추상 팩토리 패턴과 함께 사용하여 객체 생성과 관련된 복잡성을 숨기고 일관성있는 객체 생성을 보장할 수 있다.

구조 패턴

- 데코레이터 패턴: 객체에 동적으로 새로운 기능을 추가할 수 있도록 해준다. 객체의 상태를 변경하지 않고도 새로운 기능을 추가할 수 있어서 객체의 유연성과 확장성을 높일 수 있다.

- 프록시 패턴: 원래 객체와 동일한 인터페이스를 제공해 클라이언트는 프록시 객체를 원래 객체와 같은 방식으로 사용할 수 있다. 

- 컴포지트 패턴: 객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층 구조를 만드는 방법을 제공하고, 이러한 구조를 통해 클라이언트는 개별 객체와 복합 객체를 모두 동일 방식으로 다룰 수 있다.

- 어댑터 패턴: 인터페이스가 다른 두 객체가 함께 동작할 수 있도록 중간에서 매개체 역할을 수행하는 어댑터 객체를 사용할 수 있다.

- 퍼사드 패턴: 복잡한 시스템의 각종 서브시스템들을 간단한 인터페이스로 제공하는 패턴이다.클라이언트는 복잡한 시스템의 내부 구조에 대한 지식 없이도 쉽게 시스템을 사용할 수 있다.

 

행동 패턴

- 템플릿 메소드 패턴: 알고리즘의 구조를 정의하고, 일부 단계를 서브 클래스에서 구현하도록 하는 방법이다. 코드의 중복을 피하고 유지보수성을 높일 수 있고, 알고리즘의 다양성을 쉽게 지원할 수 있다는 장점이 존재한다.

- 상태 패턴: 객체 내부의 상태에 따라 행동을 변경하는 방법이다. 객체가 상태에 따라 행동을 다르게 해야 하는 경우,  if문이나 switch문을 통해 구현이 가능하나 코드가 복잡해질 경우 효율성이 떨어진다. 이러한 경우 상태 패턴을 이용해 객체의 상태를 캡슐화하여 훨씬 간단하게 코드를 구현할 수 있다.

- 반복자 패턴: 컬렉션의 구조를 노출하지 않고 컬렉션의 요소를 순회하는 방법을 제공한다. 컬렉션과 반복자 간의 결합도를 낮춰 유지보수성과 확장성을 높인다. 또한, 컬렉션의 내부 구조를 노출하지 않고 요소에 대한 순회를 가능하게 하므로,  컬렉션의 구현이 바뀌더라도 순회 로직을 바꾸지 않아도 된다.

- 전략 패턴: 객체의 행위를 독립적으로 정의하고, 이를 필요에 따라 교체해서 사용하는 방법을 제공한다. 객체의 행위를 변경하고자 할 때, 이를 교체해서 사용할 수 있다. 전략 구현 클래스를 독립적으로 정의하고, 컨텍스트 클래스에서 이를 참조하여 사용해서 코드의 재사용성과 확장성을 높일 수 있다.

- 옵저버 패턴: 객체의 상태 변화를 다른 객체에게 알리는 방법을 제공한다. 일대 다 관계를 가진 객체 간에 효율적으로 정보를 전달할 수 있도록 해준다.

UML 다이어그램

UML(Unified Modeling Language)은 객체 지향 소프트웨어 개발에 사용되는 표준화된 언어이며, UML 다이어그램은 UML을 사용하여 소프트웨어 모델링을 수행하는 도구이다. UML 다이어그램은 소프트웨어 개발자들이 소프트웨어 시스템을 이해하고 설계하는 데 도움이 되며, UML 다이어그램은 크게 구조 다이어그램과 행위 다이어그램으로 나눌 수 있다.

1. 구조 다이어그램

• Class Diagram : 클래스, 인터페이스, 관계 등의 구조적 요소를 표현(시스템에서 사용하는 객체 타입을 정의하고 그들 간의 존재하는 정적 관계를 다양한 방식으로 표현한 다이어그램)
• Object Diagram : 클래스 다이어그램에서 정의한 클래스와 인스턴스를 표현
• Component Diagram : 시스템의 물리적인 구성요소와 그들 간의 관계를 표현
• Package Diagram : 패키지, 클래스, 인터페이스, 관계 등의 구조적 요소를 묶어서 표현(하나의 패키지가 다른 패키지를 사용하는 관계)

1. 행위 다이어그램

시스템이 수행하는 과정을 시각화하기 위한 다이어그램으로, Usecase다이어그램의 actor 개념 클래스 다이어그램의 객체 사이의 상호작용을 표현한다. UML에서는 두 가지 형태의 인터랙션 다이어그램이 있다.(객체 간의 메세지 흐름을 표현하기 위한 시퀀스 다이어그램과 커뮤니케이션 다이어그램)

• Use Case Diagram : 시스템과 사용자 간의 상호작용과 시스템의 기능을 표현(요구 분석 과정에서 시스템과 외부와의 상호작용 묘사)
• Sequence Diagram : 객체들 간의 메시지 전송 순서를 표현(시간적 흐름에서 분석)
• State Diagram : 객체의 상태 변화를 표현
• Activity Diagram : 시스템의 동적인 동작과 데이터 처리를 표현(객체의 로직이나 조건에 따른 처리 흐름을 순서에 따라 정의한 다이어그램)