[정보처리기사][서버 프로그램 구현] 객체지향(Object-Oriented)

객체지향 - Object-Oriented

각 요소들을 객체(Object)로 만든 후, 객체들을 조립해서 소프트웨어를 개발하는 기법

 

• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 사용되고 있습니다.
• 재사용성 및 확장이 용이하고, 유지보수가 쉬워 빠른 개발을 할 수 있습니다.

 

1. 객체 지향의 구성 요소

• 객체(Object)
• 클래스(Class)
• 메시지(Message)

1.1 객체 - Object

데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈

• 데이터 : 객체가 가지고 있는 정보
• 함수 : 객체가 수행하는 기능

1.2 클래스 - Class

공통된 속성과 연산을 갖는 객체의 집합

각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀

클래스에 속한 각각의 객체를 인스턴스(Instance)라고 합니다.

 

1.3 메시지 - Message

객체들 간의 상호작용을 하는 데 사용하는 수단

 

 

2. 객체지향의 특징

• 캡슐화(Encapsulation)
• 상속(Inheritance)
• 다형성(Polymorphism)
• 연관성(Relationship)

2.1 캡슐화 - Encapsulation

외부에서의 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것

• 캡슐화된 객체는 외부 모듈 변경으로 인한 영향이 적다.
• 객체들 간에 메시지를 주고받을 때 세부 내용은 알 필요가 없다 (은닉됨)
• 인터페이스가 단순해진다.
• 객체 간의 결합도가 낮아진다.

2.2 상속 - Inheritance

상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것

• 하위 클래스는 물려받은 속성과 연산을 재정의하지 않아도 즉시 자신의 속성으로 사용할 수 있다.
• 하위 클래스는 상속받은 속성과 연산 외 추가적인 속성과 연산을 정의하여 사용할 수 있다.
• 재사용성의 증가

2.3 다형성 - Polymorphism

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

• 여러 가지 형태를 가질 수 있다는 의미가 빈다.
• 즉, 하나의 메시지에 대해 여러 가지 형태의 응답 및 처리가 가능합니다.

2.4 연관성 - Relationship

두 개 이상의 객체들이 상호 참조하는 관계

• 종류
  • is member of(연관화) - 2개 이상의 객체가 상호 관련되어 있음을 의미
  • is instance of(분류화) - 동일한 형을 갖는 객체들을 모아 구성 
  • is part of(집단화) - 관련 있는 객체들을 묶어 하나의 상위 객체로 구성
  • is a (일반화) - 공통적인 성질들을 추상화해 상위 객체를 구성
  • is a (특수화 또는 상세화) - 상위 객체를 구체화하여 하위 객체를 구성

객체지향 분석 및 설계

1. 객체지향 분석 - OOA : Object Oriented Analysis

사용자의 요구사항과 관련된 객체, 속성, 연산, 관계등을 정의하여 모델링하는 작업

• 개발에 필요한 업무를 객체와 속성 / 클래스와 멤버 / 전체와 부분 등으로 나누어서 분석합니다.
• 클래스를 식별하는 것이 객체지향 분석의 주요 목적입니다.

1.1 객체지향 분석의 방법론

Rumbaugh(럼바우)	객체 모델 / 동적 모델 / 기능 모델로 나누어 분석활동을 하는 방법
Booch(부치)	미시적, 거시적 개발 프로세스를 모두 사용하는 방법
Jacobson	유스케이스를 강조하여 사용하는 방법
Coad & Yourdon	E-R다이어그램을 사용하여 모델링하는 방법
Wirfs-Brock	분석과 설계의 구분이 없으며, 고객 명세서를 평하해서 설계 작업까지 연속적으로 수행하는 방법

 

1.1.1 Rumbaugh(럼바우)

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

객체 모델링 기법(OMT:Object Modeling Technique)라고도 한다.

• 객체 모델링 → 동적 모델링 → 기능 모델링 순으로 이루어집니다.

2. 객체지향의 설계 원칙 - SOLID 원칙

변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 원칙

• 종류
  • 단일 책임 원칙 (SRP : Single Responsibility Principle)
    • 객체는 단 하나의 책임만 가져야 한다는 원칙
  • 개방 - 폐쇄 원칙 (OCP : Open Close Principle)
    • 기존 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 된다는 원칙
  • 리스코프 치환 원칙 (LSP : Liskov Subsitution Principle)
    • 자식 클래스는 최소한 부모 클래스의 모든 기능을 수행할 수 있어야 한다는 원칙
  • 인터페이스 분리 원칙 (ISP : Interface Segregation Principle)
    • 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
  • 의존 역전 원칙 (DIP : Dependency Inversion Principle)
    • 의존 관계 성립 시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙