4. 그러나 .... 병렬화를 해도 엄청난 노력이 필요하다 . 성능향상도 동기화 부분에서 많이 까먹게 된다 . 코드도 복잡해진다 ! 버그도 생겨난다 !!! 더 이상 건드리기가 싫어진다 ㅠㅠ
5.
6.
7. 너무나도 개발자들 사이에서 깊숙히 뿌리 내린 OOP. 도저히 오브젝트를 빼 놓는다는 것은 생각조차 힘들다 . OOP 를 안쓴다고 쳐도 대안은 있는가 ?
8. 너무나도 개발자들 사이에서 깊숙히 뿌리 내린 OOP. 도저히 오브젝트를 빼 놓는다는 것은 생각조차 힘들다 . OOP 를 안쓴다고 쳐도 대안은 있는가 ? DOD(Data Oriented Design) 은 이러한 어려운 문제를 해결 할 수 있는 다른 방식의 접근이다 . DOD 는 DDD(Data Driven Design) 과 다르다 . 데이터 주도형 디자인은 게임의 기능을 최대한 코드 밖으로 빼내서 데이터쪽으로 옮기는 것을 의미한다 .
11. 오브젝트를 생각하게 되면 , 여러가지 형태의 트리들이 떠오른다 . 상속트리 , 트리식 포함관계 , 메시지 전달 트리구조 , 그리고 자연스럽게 데이터는 트리형태로 정렬된다 . 그 결과 어떤 오브젝트에 대한 연산을 수행하게 되면 , 트리상에 엮인 다른 오브젝트를 액세스 하게 된다 . 한 묶음의 오브젝트를 처리하다보면 트리구조를 따라 각각의 오브젝트에 대해 서로 다른 연산을 수행하게 된다 .
12.
13. DOD 가 왜 강력한데 ? 게임에서는 하나의 오브젝트가 아닌 다수의 오브젝트가 있으며 OOP 에서는 오브젝트 위주로 처리를 하는 반면 , DOD 는 하드웨어의 특성을 살려서 데이터를 같은 타입끼리 복수개를 묶게 된다 .
14. DOD 의 장점 1. 병렬화 (Parallelization) OOP 코드의 병렬화는 어렵고 , 실수하기 쉽고 , 효율이 오르지 않을 수도 있다 . 여러개의 스레드에서 데이터에 접근할 때 생기는 Race Condition 을 막기 위해 동기화를 여기저기 붙이다 보면 스레드들은 락을 기다리느라 대기하는 시간이 길어지며 성능이 떨어진다 . DOD 는 병렬화는 간단해지며 , 입력데이터와 그것을 처리할 작은 함수들 , 출력데이터를 갖게된다 . 이런 작업은 여러개의 스레드에 쉽게 나눌 수 있으며 동기화도 별로 필요하지 않다 . 이 방식은 병렬 프로세서에서 실행시키는 것도 어렵지 안다 .
15. DOD 의 장점 2. 캐쉬 활용 ( Cache Utilization) 최신 다단계 캐쉬로 설계된 하드웨어의 성능을 최대한 끌어올리는 핵심은 캐쉬 친화적인 메모리 액세스다 . OOP 에서는 최적화를 하는데 있어 알고리즘을 바꾸거나 , C 코드를 어셈블리어로 바꾸거나 함수호출의 순서를 바꾸는 정도인데 , DOD 에서는 Cache miss 를 방지하면서 더 빠른 처리가 가능하도록 한다 .
16. DOD 의 장점 3. 모듈화 (Modularity) DOD 는 성능에도 도움이 되지만 , 개발의 편이에도 도움이 된다 . 코드를 데이터 변환이라는 관점에서 작성하게 되면 , 결국 , 서로 의존성이 많지 않은 작은 함수들로 만들게 되고 , 결국 코드들은 평평하고 (flat) 의존성이 별로 없는 함수들의 모음이 된다 . 이런 모듈화는 이해하기 쉽고 , 바꾸거나 고치기 쉬운 코드들이 된다 .
17. DOD 의 장점 4. 테스트 (Testing) 오브젝트의 상호작용에 대한 유짓 테스트를 만드는 것은 쉽지 않은 일이다 . 모의 객체를 세팅하고 간접적인 방법들을 써야한다 . 너무 고생스럽다 . 반면 데이터를 직접 다루게 되면 유닛 테스트를 짜는 것은 간단해진다 . TDD 를 하는 중이건 , 개발이 끝난 후에 테스트를 만드는 것이건 코드가 아주 테스트하기 편해진다 .
19. 문제점은 ... 지금까지 해오던 설계방법에 비해 너무 생소한다 . 적응하기까지 시간이 걸릴 수도 있다 . 프로그램 짜는 방식을 전환하기 때문에 상당한 연습이 필요하다 .
20. 그럼 OOP 는 필요 없나 ?? OOP 는 중요하다 . OOP 의 개념을 완전히 버릴 수는 없고 , 다만 우리가 노력해야 할 부분은 대용량의 데이터를 처리할때 , DOD 관점에서 생각해보고 어떻게 적용해야하나 이다 . 이것이 현재 개발자들이 고민하고 풀어야할 숙제이다 .