🖋 애플리케이션 설계 #2 - 객체지향, 디자인패턴

 

👍 객체지향이란?

 

실 세계의 개체(Entity)를 "속성"과 "메서드"가 결합된 형태의 객체로 보고 구현대상을 객체와 객체들 간 관계로 모델링하는 방법

객체는 클래스의 인스턴스이며, 추상화, 상속, 다형성, 캡슐화, 정보은닉의 특징을 가진다.

 

🙌 추상화

객체를 모델링할 때 필요로 하는 만큼만 속성과 메서드를 추출해내는 것

모델에 무엇을 포함하고 무엇을 뺄 것인지 아는 것이 가장 중요

 

🙌 상속

상위 클래스의 속성과 행위를 하위 클래스가 그대로 이어받는 것

상속을 이용하면 구현이 편리해지고 유지보수가 용이

 

🙌 다형성

상속을 받으면서 자신만의 커스터마이징이 가능함

메소드 오버라이딩(로직수정), 메소드 오버로딩(파라미터에 따라 다른 동작시키기 ) 등이 있다.

 

🙌 캡슐화

객체가 자신의 동작 원리를 클래스라는 껍데기로 감추는 것

해당 객체를 제외하고는 원리를 알 길이 없다.

 

🙌 정보은닉

캡슐화된 항목의 인터페이스와 구현을 명확히 분리하여 각 클래스의 내부 항목에 관한 정보를 다른 객체로부터 숨긴다.

메시지 전달에 의해 다른 클래스 내의 메서드가 호출된다.

---

👍 클래스 간의 관계

🙌 연관 관계

클래스는 서로 특정 의미를 가짐

 

🙌 일반화 - 특수화 관계

두 클래스 간 상속관계를 나타낸 것으로, 위로 갈수록 추상/일반화, 아래로 갈수록 구체/특수화

 

🙌 집합관계

하나의 클래스가 독립 가능한 여러 컴포넌트 클래스로 구성

관계도에서 전체 클래스 쪽에 빈 마름모를 그린다.

 

🙌 복합관계

하나의 클래스가 독립 불가능한 여러 컴포넌트 클래스로 구성

관계도에서 전체 클래스 쪽에 색칠한 마름모를 그린다.

 

---

👍 클래스 설계원칙

 

🙌 단일 책임 원칙

클래스는 한 가지 책임(기능)만 갖도록 설계한다.

 

🙌 개방 폐쇄의 원칙

확장(상속)에는 열려있고, 변경에는 닫혀있어야 한다.

 

🙌 리스코프 교체의 원칙

상위 클래스는 하위 클래스로 대체할 수 있어야 한다.

 

🙌 의존 관계 역전의 원칙

클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다.

 

🙌 인터페이스 분리의 원칙

하나의 일반적인 인터페이스보다는 구체적인 여러 인터페이스가 낫다.

 

---

👍 디자인 패턴

많은 개발자들이 경험으로 체득한 설계 지식을 검증하고 이를 추상화하여 일반화한 템플릿

 

디자인패턴의 장단점

장점

개발자(설계자) 간 원활한 의사소통

소프트웨어 구조 파악 용이

재사용성을 통한 개발 시간단축

설계 변경 요청에 대한 유연한 대처

 

단점

객체지향 설계/구현 위주

초기투자 비용부담

 

목적과 범위에 따른 분류

범위 \ 목적	생성패턴 (객체의 생성과정에 관여)	구조패턴 (클래스나 객체의 합성에 관여)	행위패턴 (클래스나 객체들의 상호작용과 책임을 분산)
클래스	Factory Method	Adapter	Interpreter Template Method
객체	Abstract Factory Builder Prototype Singleton	Adapter Bridge Composite Decorator Facade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

 

🙌 생성패턴

Factory Method

객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴

상위 클래스에서 인스턴스 작성법의 뼈대를 세우고 구체적인 작성은 하위 클래스에서 실행하는 패턴

상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당

 

Abstract Factory

클래스가 아닌 인터페이스를 통해 연관된 부품을 조합해서 인스턴스 생성을 실행하는 패턴

 

Builder

복잡한 인스턴스를 조립하여 만드는 구조로, 객체를 생성하는 방법과 객체를 구현(표현)하는 방법을 분리하는 패턴

 

Prototype

모형이 되는 인스턴스를 복사해서 새로 인스턴스를 만드는 패턴

 

Singleton

특정 클래스의 인스턴스가 오직 하나만 존재하도록 제한하는 패턴

여러 프로세스가 동시에 참조할 수 없어 불필요한 메모리 낭비를 최소화할 수 있음

---

🙌 구조패턴

Adapter

서로 다른 인터페이스를 가져 호환성이 없는 클래스의 인터페이스를 이용할 수 있도록 연결하는 패턴

 

Bridge

구현부에서 추상층을 분리하여 서로 독립적으로 확장할 수 있도록 구성한 패턴

기능과 구현을 두 개의 별도 클래스로 구현

 

Composite

여러 객체를 트리구조로 하여 재귀적으로 다룸

 

Decorator

객체에 부가적인 기능을 추가하기 위해 다른 객체를 덧붙이는 것

 

Facade

복잡하게 얽힌 클래스를 개별 제어하는 것이 아니라 창구 역할을 하는 클래스를 상위에 하나 더 배치해서 시스템 전체의 조작성을 향상

 

Flyweight

인스턴스가 필요할 때마다 매번 생성하는 것이 아니라 가능한 한 공유함으로써 메모리를 절약

 

Proxy

접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 함으로써 네트워크/대용량 객체에 이용

---

🙌 행위패턴

Interpreter

문법 규칙을 클래스로 표현하는 패턴

 

Template Method

상위 클래스에서 처리의 뼈대를 세우고, 구체적인 처리를 하위 클래스에서 실행하는 패턴

 

Chain of Responsibility

요청이 처리되지 못하면 연결되어 있는 내부의 다른 객체로 토스하는 패턴

 

Command

요청을 클래스의 형태로 캡슐화하여 기록

 

Iterator

자료구조처럼 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴

 

Mediator

서로 다른 객체 사이에 중재자 역할을 하는 클래스를 두어 객체 사이의 의존성을 줄임

 

Memento

특정 시점에서의 객체 상태를 저장하여 Undo 기능이 가능하도록 하는 패턴

 

Observer

상태가 변화하면 상속되어 있는 다른 객체들에게 변화를 통지하는 패턴

 

State

객체의 상태를 클래스로 표현하여, 상태에 따라 다른 동작을 처리할 수 있게 하는 패턴

 

Strategy

동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴

클라이언트는 독립적으로 알고리즘을 선택하고 전부 교체하여 수정하기 쉽다.

 

Visitor

각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴

분리된 처리 기능은 각 클래스를 Visit(방문)하여 수행