Part 3. 애플리케이션 설계 23.01.18(수)

5. 애플리케이션 설계 – 객체 지향 설계 – 객체 지향

1) 객체 지향 개념

객체 지향은 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법이다.

 

2) 객체 지향 구성요소

(1) 클래스(Class)

특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀

객체 지향 프로그래밍에서 데이터를 추상화하는 단위

하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현

속성은 변수의 형태로, 행위는 메서드 형태로 선언

 

(2) 객체(Object)

물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상

클래스에서 정의한 것을 토대로 메모리에 할당됨(일정한 기억장소를 갖고 있음)

객체마다 각각의 상태와 식별성을 가짐

 

(3) 메서드(Method)

클래스로부터 생성된 객체를 사용하는 방법

객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산

전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산 기능

 

(4) 메시지(Message)

객체 간 상호 작용을 하기 위한 수단

객체에서 어떤 행위를 하도록 지시하는 방법

객체 간의 상호 작용은 메시지를 통해 이루어짐

메시지는 객체에서 객체로 전달됨

 

(5) 인스턴스(Instance)

객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체

클래스에 속한 각각의 객체

실제로 메모리상에 할당

 

(6) 속성(Property)

한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의

성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값

 

3) 객체 지향 기법

(1) 캡슐화(Encapsulation)

서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 기법

결합도가 낮아지고 재사용이 용이

인터페이스가 단순화됨

정보 은닉과 관계가 깊음

변경 발생 시 오류의 파급 효과가 적음

 

(2) 상속성(Inheritance)

상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법

 

(3) 다형성(Polymorphism)

하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질

오버로딩, 오버라이딩이 대표적

* 오버로딩(Overloading)

매개변수의 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법

ex)

void fn(int a);

void fn(char a);

void fn(int a, int b);

 

* 오버라이딩(Overriding)

B클래스는 A클래스를 상속 상위 클래스(부모 클래스)가 가지고 있는 메서드를 하위 클래스(자식 클래스)가 재정의해서 사용하는 기법

ex)

class A{

void fn(int a);

}

class B : public A{

void fn(int a);

}

 

(4) 추상화(Abstraction) - 과자제

공통 성징을 추출하여 추상 클래스를 설정하는 기법

종류로는 과정 추상화, 자료 추상화, 제어 추상화가 있음

 

(5) 정보 은닉(Information Hiding)

코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술

필요하지 않은 정보는 접근할 수 없도록 하여 한 모듈 {또는 하부 시스템이 다른 모듈의 구현에 영향을 받지 않게 설계됨(고려되지 않은 영향인 Side-Effect들을 최소화)

모듈 내부의 자료 구조와 접근 동작들에만 수정을 국한하지 않기 때문에 요구사항 등 변화에 따른 수정이 가능

모듈 사이의 독립성을 유지하는 데 도움을 줌

설계에서 은닉되어야 할 기본 정보로는 IP 주소와 같은 물리적 코드, 상세 데이터 구조 등이 존재

 

(6) 관계성(Relationship)

두 개 이상의 엔터티 형에서 데이터를 참조하는 관계를 나타내는 기법

종류로는 연관화, 분류화, 집단화, 일반화, 특수화가 있음

 

1-연관화

is-member-of 관계

클래승놔 객체의 참조 및 이용관계

같은 계층에 속하는 클래스들 사이의 상호 의존성을 보여주는 비계층적 관계성을 나타냄

 

2-집단화

is part of 관계, part-whole 관계

서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 만드는 특징이 있음

일반화와 달리 상위 클래스의 성질들이 하위 클래스로 상속되지는 않음

 

3-분류화

is-instance-of 관계

공통된 속성에 의해 정의된 객체 구성원들의 인스턴스

 

4-일반화

is-a 관계

클래스들 간의 개념적인 포함 관계

상위 클래스의 특성을 하위 클래스가 상속받음

 

5-특수화

is-a 관계

상위 클래스의 특성들을 상속받으면서 하위 클래스에서 나름대로 수정을 가하고 자기 자신의 고유한 특성을 갖는 관계

 

4) 객체 지향 설계 원칙(SOLID)

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

하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙

객체 지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초 원칙

 

(2) 개방 폐쇄 원칙(Open Clods Principle)
- 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙

 

(3) 리스코프 치환의 원칙(Liskov Substitution Principle)

서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙

 

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

한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙

클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다는 원칙

 

(5) 의존성 역전의 원칙(Dependency Inversion Principle)

실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

* 의존성 역전의 원칙이 구체적으로 무엇인가?

의존성 관계를 맺을 때 변화하기 쉬운 것보다는 변화가 없는 것에 의존 관계를 맺으라는 이야기.

자주 바뀌는 클래스를 의존할 경우 변경요소가 발생할 경우 다른 의존 코드 부분까지 모두 수정이 필요

변화가 없는 것, 즉 추상 클래스 또는 인터페이스를 참고하게 될 경우 변경에 따른 추가 수정이 없어도 됌

 

5) 객체 지향 방법론 종류

(1) OOSE(Object Oriented Software Engineering) - 만든이 : 야콥슨

유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용되는 방법론

분석, 설계, 구현 단계로 구성

기능적 요구사항 중심의 시스템

 

(2) OMT(Object Modeling Technology) - 만든이 : 럼바우

그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론

분석 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행 – 객동기

 

1-객체 모델링(Object Modeling)

정보 모델링이라고도 하며, 시스템에서 요구하는 객체를 찾고 객체 간의 관계를 정의하는 모델링

가장 중요하며 선해오디어 진행

객체 다이어그램을 활용하여 표현

 

2-동적 모델링(Dynamic Modeling)

시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링

상태 다이어그램을 활용하여 표현

 

3-기능 모델링(Functional Modeling)

프로세스들의 자료 흐름을 중심으로 처리 과정을 표현하는 모델링

자료 흐름도(DFD)를 활용하여 표현

 

(3) OOD(Object Oriented Design) - 만든이 : 부치

설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론

분석과 설계의 분리가 불가능

분석하는 데 이용된 객체 모델의 설계 시 적용

 

*추가적으로 Coad와 Yourdon 방법론은 E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법이다.

 

*Wirfs-Brock 방법론은 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 분석 방법이다.

 

6. 애플리케이션 설계 – 객체 지향 설계 – 디자인 패턴

1) 디자인 패턴(Design Pattern) 개념

디자인 패턴은 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴이다.

디자인 패턴을 참고하여 개발할 경우 개발의 효율성과 유지보수성, 운용성 등의 품질이 높아지며, 프로그램의 최적화에 도움이 된다.

 

2) 디자인 패턴 구성요소

(1) 패턴의 이름 : 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형

(2) 문제 및 배경 : 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미

(3) 솔루션 : 디자인 패턴을 이루는 요소들, 관계, 협동 과정

(4) 사례 : 디자인 패턴의 간단한 적용 사례

(5) 결과 : 디자인 패턴을 사용하면 얻게 되는 이점이나 영향

(6) 샘플 코드 : 디자인 패턴이 적용된 원시 코드

 

3) 디자인 패턴 유형

(1) 생성(Creational) 패턴

객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴

 

(2) 구조(Structural) 패턴

더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴

 

(3) 행위(Behavioral) 패턴

클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

 

4) 디자인 패턴 종류 – 생성 패턴

(1) Builder : 생성과 표기를 분리해서 복잡한 객체를 생성

(2) Prototype : 기존 객체를 복제함으로써 객체를 생성

(3) Factory Method : 생성할 객체의 클래스를 국한하지 않고 객체를 생성

(4) Abstract Factory : 동일한 주제의 다른 팩토리를 묶음

(5) Singleton : 한 클래스에 한 객체만 존재하도록 제한

 

5) 디자인 패턴 종류 – 구조 패턴

(1) Bridge : 구현뿐만 아니라, 추상화된 부분까지 변경해야 하는 경우 활용

(2) Decorator : 객체의 결합을 통해 기능을 동적으로 유연하게 확장

(3) Facade : 통합된 인터페이스 제공

(4) Flyweight : 여러 개의 ‘가상 인스턴스’를 제공하여 메모리 절감

(5) Proxy : 특정 객체로의 접근을 제어하기 위한 용도로 사용

(6) Compsite : 복합 객체와 단일 객체를 동일하게 취급

(7) Adapter : 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움

 

6) 디자인 패턴 종류 – 행위 패턴

(1) Mediator : 상호 작용의 유연한 변경을 지원

(2) Interpreter : 문법 자체를 캡슐화하여 사용

(3) Iterator : 내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 하는 행위 패턴

(4) Template Method : 상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행

(5) Observer : 객체의 상태 변화에 따라 다른 객체의 상태도 연동, 일대다 의존

(6) State : 객체의 상태에 따라 행위 내용을 변경

(7) Visitor : 특정 구조를 이루는 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원하는
행위

(8) Command : 요구사항을 객체로 캡슐화

(9) Strategy : 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환

(10) Memento : 객체를 이전 상태로 복구시켜야 하는 경우, ‘작업취소(Undo)’ 요청 기능

(11) Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리

 

7) 디자인 패턴의 장단점

(1) 장점

요구사항 변경에 따른 소스 코드 변경을 최소화할 수 있게 해줌

소프트웨어 코드의 품질을 향상시킬 수 있음

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

범용적인 코딩 스타일 적용 가능

개발자 간의 원할한 의사소통 가능

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

소프트웨어 구조 파악이 용이

객체 지향 설계 및 구현의 생산성을 높이는 데 적합

소프트웨어의 품질과 생산성을 향상시킬 수 있음

 

(2) 단점

객체 지향 설계 / 구현 위주로 사용

초기 투자 비용의 부담