이 글은 필자가 개발을 경험해보면서 object라는 개념에 대해 현타가 왔고 이리저리 문서들을 찾아 읽다가 의식의 흐름대로 생각을 적어봤다. 결론만 궁금하다면.. - #결론
객체지향이란 무엇인가?
구조적 프로그래밍의 한계 ---> 객체 지향적
https://en.wikipedia.org/wiki/Structured_programming
object(사물,물체) 위주의 프로그래밍을 추구하는 기법이다.
단, OOP에서 말하는 object는 실제 세계의 물리적인 것과 추상적인 것 모두 포함하며 형상화하고 개념화 할 수 있다면 어떤 것이든 object가 될 수 있다. 실제 세계를 인식하는 것과 닮았다.
객체, object의 가장 중요한 핵심은 캡슐화, 추상화.
자료 구조로 형성된 bit 데이터들을 하나의 사물,object(real-world objects or an abstract entity)의 의미가 표현될 수 있도록 추상화, 캡슐화가 이루어진다.
https://www.techtarget.com/searchapparchitecture/definition/object-oriented-programming-OOP
컴퓨터가 이해하는 이진코드의 데이터를 사람이 이해하기 쉬운 object로 개념화한다는 것은 곧 추상화하고 캡슐화 한다는 뜻이다.
-> 현실 세계의 object(혹은 가상의 개체)와 bits를 대응 시킨다.
-> 이걸 프로그래밍 단계에서 지원해야 OOP 패러다임이다! ex) class 문법!!
(Object Oriented Programming 이니깐!)
object는 상태를 기억할 수 있어야하고 자신의 상태를 바꾸거나 다른 object에 영향을 줄 수도 있다.
The objects in the program are the entities in the simulation
--> 프로그램에서 object란 가상속의 개체, 가상 세계의 물체(추상적인 개념 포함)이다.
(2.2.1.1)
여러 관점과 견해를 찾아본 결과 OOP에서 말하는 obejct는 위 조건들을 만족하는 모든 개념이라고 볼 수 있다.
OOP 패러다임을 구체화하는 클래스, 다형성, 상속, 오버라이드 등 여러가지 기법을 다양한 언어에서 지원하고있다.
OOP로 유명한 언어들이 많으나 특정 언어가 OOP를 어떻게 구현하고 어디까지 지원하는지를 집중해야지, OOP 언어 == OOP 패러다임으로 오해하면 안된다.
i.e) 클래스, 다형성 등등은 OOP 패러다임을 위한 기술이지 OOP라면 무조건 클래스를 써야하고 다형성을 써야되는 것이 아니다. 효율성과 인증, 기술의 발전 개념일 뿐이다. 마치 컴퓨터가 꼭 반도체로 이루어졌다고 착각하는 것과 일맥 상통하다.
반도체가 전기적 신호로 0과1을 구분하고 연산할 수 있는 현대 가장 효율적인 물리 자원일 뿐, 물리적인 장치가 전산학적인 표현과 계산을 할 수 있다면 뭐든 상관없다. 예로 주판도 일종의 원시 컴퓨터(알 개수로 숫자를 표현하고 계산은 사람 손가락으로 한다)이다 물론 자동으로 연산하지 않고 프로그래밍이 불가능하기 때문에 현대에서 말하는 컴퓨터는 아니다.
최초의 컴퓨터도 반도체가 아닌 진공관으로 만들었고 미래 컴퓨터로는 양자가 주목 받고 있다.
java는 class, object, instance, 상속의 개념등을 기저로하여 OOP 프로그래밍을 할 수 있는 문법을 지원하고 아래와 같은 그림들을 참고하는 경우를 많이봤다.
그림만 보면 Class로 object와 인스턴스를 만든다고 이해할 수 있다. -> oracle에도 java를 이렇게 설명한다.
하지만 이건 java가 OOP를 지원하는 방식일뿐이다.
OOP라는 패러다임은 위에서 말한 object의 개념을 갖는 객체 위주의 프로그래밍일뿐 java가 정답이 아니며 시간이 지나면서 더 다양한 object 개념이 추가 될 수 있다.
대표적으로 javascript, python등은 함수를 1급 객체로 인식하는 언어이며 python은 모든 것이 object로서 구현되어있다. (class조차도 object)
반면, java의 class는 오브젝트가 아니다. 오브젝트는 다른 오브젝트들과 상호작용 하고 instance화 될 수 있고 상태를 기억하고 각자의 object는 구분 되어야하지만 java의 class는 프로그래밍된 순간 runtime에서 변하지 않는 확정된 요소이다.
(물론 자바도 동적 클래스를 생성할 수 있는 방법들도 있긴하지만 python처럼 의도적으로 설계되었다고 보기엔 무리라고 생각한다.)
python은 class또한 object이기 때문에 runtime동안 상호작용하며 상태를 기억하고 변화할 수 있다.
--> class 자체와 class 내부 내용 조차도 동적으로 생성, 삭제등 python에서 obejct가 할 수 있는 모든 것은 class도 할 수 있다
객체지향의 오해와 진실이라는 책에서 object는 역할,책임,협력을 정의하는 것이 중요하다고 한다. (참고로 책 안읽어봤다.)
책의 미리보기에서 "커피" <> "종업원" <> "손님" 이런 객체들의 상호작용을 예시로 드는 것을 보았는데
이런 구체적인 비즈니스 로직의 대상뿐만 아니라 python과 같이 "함수" <> "클레스" <> "기본 자료형" 의 프로그래밍 기저조차도 object로서 역할,책임,협력을 추상화할 수 있다.
python은 프로그래밍의 대부분의 기저들도 object이기 때문에 새롭게 정의하고 인스턴스화할 수 있기 때문에 다양한 프로그래밍 인터페이스를 직접 개발할 수도 있다. -> e.g) 특정 클래스의 동작 방식 자체를 새롭게 개발 할 수도 있다. 대표적인 예시 pydantic
Models - pydantic
Models The primary means of defining objects in pydantic is via models (models are simply classes which inherit from BaseModel). You can think of models as similar to types in strictly typed languages, or as the requirements of a single endpoint in an API.
docs.pydantic.dev
-> 꼭 좋은건 아니다.
누군가 개발한 라이브러리를 쉽게 사용하기엔 간편하고 좋지만 추상화된 내용이 너무 많아 트랙킹을하거나 내부 동작을 이해하기 어려울 수 있다.
개인적으로 개발에 정답은 없다고 생각한다.
상황에 따라 더 효율적인 방법이 얼마든지 있을 수도 있고 효율적인 방법을 찾는 과정 자체가 비효율적이라면 이미 정립된 이론을 찾아 쓰는 것도 매우 좋은 방법이라고 생각한다.
결론
이 글은 OOP를 얘기하지만, OOP를 잘쓰는 방법에 대해서 말하고 싶었던 것이 아니다.
OOP는 왜 탄생했고 어떤 길을 추구하는건지 다양한 견해를 살펴보고 여러 기술에대한 원론적인 고찰을 하고 싶었다.
많은 글을 찾아보면서 역시나 다양한 관점이 있었고 오히려 논문이나 유명한 저서일수록 OOP에 대해 구체적인 명세를 정의하기 보다는 OOP의 목적과 추구하는 방향을 고찰하고 그것을 달성하기 위한 기술과 특징을 소개하는 경향이 있었다.
반대로 오버플로우, 일반 블로그와 같은 가벼운 글들은 OOP == java 문법, 기법을 그대로 명시하는 경우가 많았다.
OOP 패러다임은 방향성(견해, 사고, 방식)이지 도착점(결론)이 아니다.
OOP를 논할 때, 구체적인 개발 방식(명세, 문법, 디자인패턴)을 아느냐가 가장 중요한건 아니라고 생각한다. (매우 중요하다고 생각은 한다.)
개발은 어떻게 하느냐도 중요하지만 무엇을 위해서 왜 하느냐가 본질이지 않을까 의문을 던져본다..
책을 앞부분만 미리읽기로 보았을 뿐이지만 마음에 드는 구절이다.
'P.L' 카테고리의 다른 글
| C/C++ call by value, 포인터(call by reference), 메모리 접근 동작 방식 (0) | 2021.10.05 |
|---|---|
| C/C++ call by 포인터, 소멸자, 깊은 복사자가 필요한 이유, 메모리 누수에 대한 고찰 (0) | 2021.10.04 |
| c++ ofstream 파일 수정/쓰기 file(binary) modify/write (1) | 2020.06.13 |
댓글