Object란 무엇일까요?
많은 책에서 Object가 무엇이냐고 설명할 때 붕어빵 틀같은.. 예제들을 많이 들고 있습니다. object는 Entity, 독립적인 하나의 구현체로서 상태(State)와 행위(Behavior)를 포함하고 있는 것이라고 설명하고 싶습니다. 상태는 변수, 데이터이며, 행위는 Operation 즉 함수들입니다.
Object의 상태(State)는 Object가 보유하고 있는 변경될 수 있는 것입니다. 변경이란 말은 상태가 변경된다라는 것이죠. 예를 들어 자동차란 Object의 상태는 차량의 색상, 디자인 등이 있겠지만 이 상태들 예시로 색상을 생각해보면 동일한 형태의 차량들도 도색을 통해 색상이 변경될 수 있겠죠. 그럼 행위(Behavior)는 뭘까요? Object의 행위이죠. 상태를 변경하거나 Object 자체의 행동을 정의할 수 있습니다. 자동차라면 앞으로 전진, 멈춤, 후진 등이 행위가 될 수 있습니다.
이러한 Object들이 서로 관계를 가지고 일을 하는 과정을 만드는 것이 Object-Oriented Programming이라고 말할 수 있지 않을까요?
Object는 각각 고유한 행위들을 가지고 있기 때문에 다른 행위를 위해서는 그 행위를 보유하고 있는 Object에 부탁을 해야합니다. 음, 예시를 하나 들어볼까요? 여러분이 커피숍에 들어가 주문을 합니다. 이 때 주문을 받는 직원과 커피를 만드는 직원을 각각의 Object라고 해보죠. 이 때 주문을 받는 직원을 커피를 만들지 못한다고 합니다. 여러분들이 주문을 하게되면 주문을 받는 직원 Object에게 요청을 하게 됩니다. 이 Object의 행위는 주문받기, 계산 등이 있겠죠. 그럼 커피를 만들기 위해서는 커피를 만드는 직원 Object에게 요청을 해야합니다. 커피를 만드는 행위는 커피 만드는 직원 Object에게 있는 행위이닌깐요. 이렇게 각 Object 끼리 상호작용하면서 커피숍이란 시스템을 구성하게 됩니다.
그럼 Class에 대해 알아봅시다.
Class는 object들의 집합을 설명할 수 있는 것(?)이라고 정의할 수 있을까요? Object들은 각기 고유한 존재입니다. 클래스는 Object들이 가지고 있는 상태와 행위가 정의되어 있는 것입니다. 실제 상태의 값은 다를 수 있지만요. 상태의 값은 없고 상태만 설명되어 있다면 이 정의는 굉장히 추상적이라고 할 수 있습니다. 자동차의 색, 모양등의 상태의 정의는 가지고 있지만 어떠한 색인지 모양인지는 Class는 모르는 것이죠 정확한 상태의 값은 각 Object들이 가지게 되는 것입니다. 아까 위에서 많은 예시로 붕어빵 틀을 설명했는데요, 붕어빵 틀이 Class이고 붕어빵들이 Object라면 좀 더 이해가 쉬울까요?
좀 더 자세히 정의해봅시다. Class의 상태는 이름만 정의된 프로퍼티(Property)입니다. 그 상태에 값을 나타내는 건 Object가 됩니다. 행위는 Object가 할 수 있는 행위, Operation을 정의해놓은 것이라고 말씀드렸었죠? Operation을 호출하는 것이 Object간의 상호작용이라고 한번 더 말씀드립니다.
Object-Oriented Programming의 Principles
OOP의 Principles를 살펴보기전에 Abstraction DATA Type(ADT, 추상자료형)에 대해 간단하게 알아보고 시작해보겠습니다.
ADT는 사용자 정의 자료형으로서 data와 operation을 하나로 나타낼 수 있는 단일 집합입니다. 프로그램의 organization, modifiability를 향상시킬 수 있습니다. 여기서 Operation, 실제 구현부는 외부로 보여지지 않고 숨겨져 있음으로서 구현이 변경되었을 때 사용자는 전혀 인식하지 못하도록 하는 것입니다.
자 그럼 이제 정말 시작해봅시다. 객체지향의 기본적인 원칙에는 Encapsulation, Inheritance, Polymorphism, Abstraction, Composition, Abstract / Interface class의 개념들이 있습니다. 하나씩 살펴보죠.
1. Abstraction(추상화)
Abstraction이란 무엇일까요? 공통된 중요한 것들은 강조하고 불필요한 것들은 지우는 것이 Abstraction입니다. 흠, 설명이 뭔가 크게 와닿지 않습니다. 현실 세계의 어떠한 것을 Abstraction한다면 어떻게 할까요? 여러분들이 실제 관심이 있는 내용만 강조하고 불필요한 것들은 지워야 합니다. 이 말은 자동차로 예로 들면 여러분들은 차의 색상이나 모델 만 관심이 있고 바퀴는 어떤 회사 모델인지등은 관심이 없다면 Object의 상태에 바퀴의 모델이 있을 필요는 없겠죠? 그럼 지워버리면 됩니다. 그리고 전진 후진 멈춤의 행위는 원하는데 창문의 열림, 닫힘은 관심이 없다면 행위로 Abstraction을 할 필요가 없겠죠? 이러한 과정을 통해 Class를 만들어 나아갑니다.
2. Encapsulation
밖에서는 보이지 않도록 내부의 내용, 정보를 숨기는 과정입니다. 외부에서 이 객체에 어떤 상태가 있는지 행위는 어떻게 하는지 알 필요가 없다는 것입니다. 우리가 커피를 주문할 때 커피가 정확히 어떻게 만들어지는지, 결제하는 객체는 계산기를 어떻게 사용하는지 알 필요가 전혀 없다는 것입니다. 조금 이해가 되시나요? 자동차를 운전할 때 자동차란 객체에게 전진, 후진등의 Operation을 페달을 통해 요청할 뿐 엔진이 어떻게 동작하는지는 전혀 알 필요가 없습니다. 즉 Object의 상태와 행위가 어떻게 되어 있는지 알 필요가 전~혀 없다는 것입니다.
엔진이 어떻게 동작하는지는 자동차 Object만 알고 있으면 된다는 것이고 운전을 하는 운전자 Object는 알 필요가 없습니다.
3. Inheritance
한국어로 상속이란 말이 더 익숙한 녀석입니다. "Is-a" 관계를 나타내는 원칙입니다. class들의 관계를 구성하기 위한 방법 중 하나인데요, 자동차라는 분류에는 버스, 트럭, 승용차 등의 분류를 가지고 있을 수 있으며 버스에는 이제 45인승, 15인승 등으로 다시 분류를 가질 수 있죠. 구조적인 표현을 나타내는 방법입니다. 좀 더 설명드리면 A가 B를 상속한다 라는 것인 A가 B의 모든 operation과 data를 가지고 있다는 것입니다 A가 B의 모든것을 가지고 있기 때문에 A is a B, A는 B이다 라고 말할 수 있습니다. 하지만 이 반대는 성립하지 않습니다. B는 A가 가진 data와 operation을 가지고 있지 않기 때문에 B is a A는 잘못된 것이죠. 그럼 이걸 어떻게 사용할 수 있을까요? 프로그램에서 B type을 요구하는 곳에 A가 들어가도 전혀!!! 이상할 것이 없습니다. 왜냐면 위에서 설명 드린 것처럼 A는 B 니까요!! 굉장히 중요한 내용이니 꼬옥 이해하고 갑시다.
4. Composition
"Has-a" 관계를 나타냅니다. Is-a 관계와는 달리 Object 간에 동적으로 어떻게 참조되는지 나타내는 원칙이라고 할 수 있습니다. 한 객체가 다른 객체를 가지고 있는 관계입니다. 아래 설명할 Polymorphism과는 매우 중요한 관계를 가진 원칙입니다.
5. Polymorphism
Polymorphism이란 다형성이란 의미입니다. 객체지향에서 빠지지 않는 녀석이죠. 동일한 인터페이스 임에도 불구하고 다른 결과를 얻을 수 있는 것도 이러한 다형성에 의한 것입니다. 아메리카노를 주문했을 때 커피를 제조하는 사람은 어떤 원두를 사용하는지 주문자는 실제로 주문을 할 수 도 있지만 보통은 그 날 입고되어 있는 원두들 중 하나를 사용할 수 있겠죠? 아메리카노 한잔 주문했겠지만 각 커피숍마다 다른 원두와 맛을 내게 됩니다. 음 예시가 조금 이상한 것 같기도 한데요, 여러분들이 프로그램을 작성할 때 if - else 등을 이용해서 경우의 수를 나열하는 그러한 코드작성을 아주 아름답게 나타낼 수 있는 성질입니다.
다형성에는 2가지 Type이 존재하는데요, Runtime polymorphism과 Compile time polymorphism이 있습니다. 동적, 정적으로 나눌 수 있는 것입니다. 이 다형성의 방법은 Method Overriding(Runtime / Dynamic polymorphism)과 Method Overloading(Compile / Static polymorphism)을 이용합니다.(Java or C++ 같은 언어에서..)
6. Interface
Interface는 매우 중요한 요소 중 하나입니다. 상태는 존재하지 않는 행위만으로 구성된 놈입니다. 문제는 행위 또한 구현이 비어져 있는 것이죠. 말 그대로 Interface입니다. 여러분들에게 어떠한 행위들을 할 수 있다라는 정보만을 제공하게 됩니다. 여러분들이 그림을 그리길 원해서 Interface를 제공할 때 그리다 라는 행위는 하나이지만 어떤걸 그릴지 원, 마름모, 세모 등등 중 어떤걸 그릴지는 바꿔가면서 하나의 Interface를 이용해 사용할 수 있다는 것입니다.
이정도 밖에 정리 할 수 없는 지식 수준에... 아쉬움이 크네요. 부족한 부분들은 공부를 하면서 틈틈히 채워나가야 겠습니다.
읽어주셔서 감사합니다.
'Software Architecture' 카테고리의 다른 글
[Unified Process] Inception Phase (0) | 2018.05.28 |
---|---|
Unified Process (0) | 2018.05.23 |
[UML] UML의 정의와 Diagram (0) | 2018.05.20 |
[OOAD] Procedural programming vs Object-Oriented programming (0) | 2018.05.20 |
[DesignPattern] Singleton Pattern (0) | 2014.07.28 |