[프로그래밍] 객체 지향 개요.

1. 객체 지향(OOP : Object-Oriented Programming)은 무엇일까.

위키백과에서는 객체 지향 프로그래밍은 컴퓨터 프로그래밍을 바라보는 견해나 사고를 규정하는 인식의 체계 중 하나로, 컴퓨터 프로그램을 명령 목록으로 보는 시각에서 벗어나 여려 독립된 단위로 서의 "객체*"의 모임으로 파악하고자 하는 것으로 정리하고 있다.

 

객체 지향이라는 페러다임이 가져온 의미에 대해 생각컨데, 컴퓨터처럼 생각하는 사람이 아니라.

컴퓨터가 사람처럼 생각하도록 프로그래밍 되어야한다는 의미로 생각된다.

 

객체* : 여기서 객체라 함은 사람의 말로 표현이 가능한 모든 것을 말한다.

2. 장점

객체 지향의 뚜렷한 장점은 재사용성 및 은닉화이다.

때문에 프로그램을 유연하고, 변경이 쉽도록 작성하여 대규모 소프트웨어 개발에 많이 사용된다.

또한 프로그래밍을 더 배우기 쉽게 하고 소프트웨어 개발과 보수를 간편하게 하며, 보다 직관적인 코드 분석을 가능하게 한다.

 

2.1. 장점의 근거.

소프트웨어 공항의 관점에서 볼 때에 S/W의 품질*을 향상시키기 위해 다음의 두 가지를 따라야할 필요가 있다.

가. 강한 응집력(Strong Cohesion)

  OOP의 경우 하나의 문제 해결을 위한 데이터를 클래스에 모아 놓아 응집력을 강화한다.

나. 약한 결합력(Weak Coupling) 

  클래스 간에 독립적인 디자인을 함으로써 결합력을 약하게 한다.

 

S/W의 품질* : 소프트웨어 공학에서의 높은 품질의 소프트웨어란 다음과 같은 내용이 포함된다.

ⓐ 제품의 목적에 만족하는 정도.

ⓑ 주어진 기간에 부합하는 정도.

ⓒ 정해진 예산에 부합하는 정도.

IEEE의 소프트웨어 품질에 대한 정의에서도 다소 개념적인 수준.

2.2. 비판

지나친 프로그램의 객체화 경향은 실제 세게의 모습을 그대로 반영하지 못한다(?)

 

3. 객체 지향을  구성하는 요소.

객체 지향은 독립된 "객체"를 만들기 위한 하나의 자료 원형으로서 모델이 되는 "청사진" 역할을 한다.

객체 지향의 기본 구성요소는 다음 3가지라 할 수 있으며, 그 설명은 다음과 같다.

 

3.1. 클래스(Class)

  같은 종류(또는 문제 해결으리 위한)의 집단에 속하는 속성(attribute)과 행위(behavior)를 정의한 것으로 객체지향

  프로그램의 기본적인 사용자 정의 데이터형(User defined data type)이라고 할 수 있다.

  클래스는 다른 클래스 또는 외부 요소와 독립적으로 디자인하여야 한다.

  프로그래머는 아니지만 해결해야 할 문제가 속하는 영역에 종사하는 사람이라면 클래스를 사용할 수 있다.

 

3.2. 객체(Object)

  클래스의 인스턴스(실제로 메모리상에 할당된 것)이다. 객체는 자신 고유의 속성(attribute)을 가지며 클래스에서

  정의한 행위(behavior)를 수행할 수 있다. 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로써

  메모리를 경제적으로 사용한다.

 

3.3. 메서드(Method), 메시지(Message)

  클래스로부터 생성된 객체를 사용하는 방법을서 객체에 명령을 내리는 메시지라 할 수 있다. 메서드는 한 객체의

  서브루틴(subroutine) 형태로 객체의 속성을 조작하는 데 사용된다. 또 객체 간의 통신은 메시지를 통해 이루어진다.

3.4. 관련 키워드

  Interface

4. 특징

4.1. 자료 추상화(캡슐화)

  불필요한 정보는 숨기고 중요한 정보만을 표현함으로서 간단히 만드는 것으로 접근 제어를 통해 정보를 은닉할 수 있다.

  일반적으로 추상 자료형을 클래스, 추상 자료형의 인스턴스를 객체라하며, 추상 자료형에 정의된 연산을 메소드(함수),

  메소드의 호출을 생성자라고 한다.

  

4.2. 상속

  상속을 통해 새로운 클래스가 기존의 클래스의 자료와 연산을 이용할 수 있게 한다.

4.3. 다중 상속

  클래스가 2개 이상의 클래스로부터 상속받을 수 있게 하는 기능으로 클래스의 기능이 동시에 필요할 때 용이하나

  상속 관계에 혼란을 줄 수 있으므로 프로그래밍 언어에 따라 사용 가능 유무가 달라 주의가 필요하다.

4.4. 다형성 개념

  어떤 요소에 여러 개념을 넣어 놓은 것으로 오버라이딩(같은 이름의 메소드가 여러  클레스에서 다른 가능을 수행)이나 오버로딩(같은 이름의 메소드가 인자의 개수나 자료형에 따라서 다른 기능을 하는 것)을 의미한다. 다형 개념을 통해서 프로그램 안의 객체 간의 관계를 조직적으로 나타낼 수 있다.

4.5. 동적 바인딩

  동적 바인딩은 실행 기간 중에 일어나거나 실행 과정에서 변경될 수 있는 바인딩으로 컴파일 시간에 완료되어 변화하지 않는 정적 바인딩과 대비되는 개념이다. 동적 바인딩은 프로그램의 한 개체나 기호를 실행 과정에 여러 속성이나 연산에 바인딩함으로써 다형 개념을 실현한다.

 

5. 객체 지향 설계 원칙 (SOLID)

  로버트 마틴이 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것으로 프로그래머가 시간이 지나두 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.

 

SRP(Single reponsibility principle 단일 책임 원칙) : 한 클레스는 하나의 책임만 가져아한다.

OCP(Open/closed Principle 개방-폐쇄 원칙) : 소프트웨어 요소는 확장에 열려 있으나 수정에는 닫혀 있어야 한다.

LSP(Liskov substitution principle 리스코프 치환 원칙) : 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

ISP(Interface segregation principle 인터페이스 분리 원칙) : 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

DIP(Dependency inversion principle 의존관계 역전 원칙) : 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

 

6. 디자인 패턴

  객체 지향 프로그래밍 설계를 할 때 자주 발생하는 의사소통에 관련한 이슈를 피하기 위해 의사소통 수단의 일종으로

  서의 해결 방안으로서 이미 수 많은 사람들이 부딪힌 문제를 해결함에서 나타나는 설계에 나타나는 패턴에 대한

  방법론이라 할 수 있다.

 

  다만, 모든 상황의 해결책은 아니므로 디자인 패턴에 얽매이는 것 보다는 그 패턴이 왜 효율적인 방식인지를

  이해해야한다.

 

  그리고, 이러한 디자인 패턴 중 일부는 소프트웨어에의 설계에서만 국한되어 적용할 수 있는 내용들로 만 이루어진 것

  은 아니며, 전기/전자 다른 응용제어 분야에서도 그 개념을 적용할 수 있다. (예 : 상태 패턴에서의 유한 상태 머신은

  전자장치의 제어 또는, PLC 등 자동화분야에서도 활용이 가능하고 활용 할 수 있는 것이다.) 

6.1. 디자인 패턴의 구조

가. 콘텍스트(Context)

   문제가 발생하는 여러 상황을 기술한다. 즉, 패턴이 적용될 수 있는 상황 또는, 이미 적용 된 패턴이 유용하지 못한

   상황을 나타낸다.

 

나. 문제(Problem)

   패턴이 적용되어 해결될 필요가 있는 여러 디자인 이슈들을 여러 제약 사항과 영향력을 고려하여 기술한다.

 

다. 해결(Solution)

  문제를 해결하다록 설계를 구성하는 요소들과 그 요소들 사이의 관계, 책임, 협력 관계를 기술한다.

  해결은 반드시 구체적인 구현 방법이나 언어에 의존적이지 않으며 다양한 상황에 적용할 수 있는 일종의 템플릿이다.

6.2. 디자인 패턴의 종류

가. 생성(Creational) 패턴(추상 객체 인스턴스화)

  객체 생성에 관련된 패턴, 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유현성을 제공한다.

 

  ⓐ 추상 팩토리(Abstract Factory)

  ⓑ 팩토리(Factory Method)

  ⓒ 빌더(Builder)

  ⓓ 프로토타입

  ⓔ 싱글톤(Singleton)

  

나. 구조(Structural) 패턴(객체 결합)

  클래스나 객체를 조합해 더 큰 구조를 만드는 패턴.

  예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어

  새로운 기능을 제공하는 패턴이다.

 

  ⓐ 어댑터(Adapter), 리퍼(Wrapper), 변환기(Translator)

  ⓑ 브리지(Bridge)

  ⓒ 컴포지트(Composite)

  ⓓ 데코레이터(Decorator)

  ⓔ 파사드(Facade)

  ⓕ 플라이웨이트(Flyweight)

  ⓖ 프록시(Proxy)

 

다. 행위(Behavioral) 패턴(객체 간 커뮤니케이션)

  객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴

  한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의

  결합도를 최소화하는 것에 중점을 둔다.

 

  ⓐ 책임 체인(Chain of Responsibility)

  ⓑ 커맨드(Commend)

  ⓒ 인터프리터(Interpreter)

  ⓓ 반복자(Iterator)

  ⓔ 중재자(Mediator)

  ⓕ 메멘토(Memento)

  ⓖ 옵저버(Oberver)

  ⓗ 상태(state)

  ⓘ 전략(Strategy)

  ⓙ 템플릿 메소드(Template Method)

  ⓚ 방문자(Visitor)