Object Oriented Vs Data Oriented
Object Oriented vs Data Oriented?
Object Oriented(이하 OO)는 객체 지향으로 데이터와 행위를 합치는 것에 집중을 하고,
Data Oriented(이하 DO)는 데이터 지향으로 데이터와 행위를 분리하는 것에 집중을 한다.
이로인해 OO는 유지보수성, 협업면에서 굉장히 큰 메리트를 가져오고, DO는 컴퓨팅 리소스, 성능면에서 굉장히 큰 메리트를 가져온다.
참고
정확히는 DO는 "데이터와 행위의 분리"가 아니라, CPU 캐시 히트율을 높이는 것이 목표이다.
주로 메모리 지역성, 초기화, 컴퓨팅 리소스를 어떻게 하면 효율적이게 사용할 수 있을까?를 생각한다.
반면, OO는 어떻게 코드를 작성하면, 유지보수를 할 수 있지?를 생각하며, 추상화 레벨을 높인다.
for (...)
a = ...
if (...) else if (...)
while (...)
위와 같은 코드를 아래의 코드로 추상화 레벨을 높였다고 표현한다.
update(...)
save(...)
두 로직을 읽어보면 저장 한다는 것을 알 수 있다. 옆자리 개발자가 빠르게 이해하는 코드는 무엇일까?
일단, 나는 2번째와 같은 코드를 읽고 싶다. 큰 범위로 기능을 살펴보고, 필요할 때 구현을 찾아보는 편으로, 갑자기 바로 복잡한 구현을 보게되면 노트북을 덮고 싶어진다.
이렇게 개발자의 인지 부하에 대한 복잡성에 집중하는 것이 OO이다.
그러면, "DO를 하는 서비스는 추상화를 안하냐??" 이건 아니다. 하지만 내부적으로 method call(virtual call)의 depth가 생기기 때문에, DO에서 지양하는 설계이다.
어떤 설계가 더 좋을까?
이건 짜장면이냐 짬뽕이냐가 아니다. 언제 칼을 쓰고 가위를 쓰는가의 문제로, 병목 지점을 파악 후 정확하게 도구를 사용하는 것이 올바르다.
만약, 본인이 만드는 서비스가 CPU 사이클 자체가 돈이고 서비스의 품질인 경우에는 DO에 집중하는 것이 올바르다. 하지만, "코드가 복잡해서 유지보수하는데 시간을 90% 사용" 이런 서비스에서는 OO가 더 효과적일 것이다.
다수의 비즈니스 웹 애플리케이션에서의 병목은 유지보수. 개발자의 인지 부하이기 때문에 OO가 효과적인 경우가 많다.
보통의 OOD(Object-Oriented Design) 애플리케이션은 DOD(Data-Oriented Design)를 갑작스럽게 도입하기는 어렵다. 도입하는 순간, OOD의 기본적인 원칙조차 성능에 의해 깨지게 될 것이다.
비즈니스 애플리케이션에서는 OO, DO를 잘 섞어서 사용해야한다. 요리를 할 때 칼을 쓰면 좋은 곳, 가위를 쓰면 좋은 곳이 다른 것과 비슷하다.
하나만 고집해도 요리는 완성되지만, 불편한 곳이 꽤 있을 것이다.
다음엔 ECS(Entity-Component System)를..