기존 설계로는, Wrapper::Ctor(Device, params...) 와 같은 식으로 객체를 생성했다만, 내부적으로 결국 Device의 네이티브 인터페이스인 ID3D12Device~을 GetNative로 받아와서 내부 객체를 생성해주는 방식이였다. 다만 이렇게 되면 API 설계에 대한 사견 #2, API 설계에 대한 사견 #3 에서의 2가지 아이디어를 위반한다. 변경할 설계, Device 래퍼가, 기존 ID3D12Device의 책임을 그대로 이어 받도록 할 것. 즉 Device 래퍼 클래스가 명령어 할당자, 명령 목록, 명령 큐, 리소스 등등.. 을 생성/할당하는데 직접적으로 사용되도록 한다. 예컨데, Device::CreateFence(...) 와 같이. 기존 ID3D12Device와의 차별점은 ..

래퍼 클래스는 래핑된 클래스의 'responsibility'를 이어 받아야 한다. 리팩토링은 '방법'보다는 '필요성'을 깨닳고, 필요성에 따라 시행하여야 한다. Fine-Grained Warning Management -> 프로젝트의 경고 단계를 W4로 설정 한 다음, 경고를 오류로 취급하게 할 것. 컴파일러의 경고는 잘못 경고를 발생시키는 경우도 있지만, 대다수의 경우에 작동했을 때 문제를 일이킬 수 있는 행동을 미연에 방지할 수 있다. 외부 라이브러리의 경고는 선택적으로 비활성화 하되, 자신의 프로젝트에서 만큼은 경고가 하나도 없도록 만드는 것이 좋다. 최적의 경우로는 전체 빌드시, 자신의 프로젝트에서 경고가 하나도 없어야 한다.

KISS -> Keep It Simple Software! 좋은 추상화 -> 사용자 입장에서, 외부로 노출된 데이터/정보가 없으며, 각각의 함수(메서드)들 자체가 동작을 잘 캡슐화 하여야 한다. 예를 들어, 만약 서드파티 API의 클래스 'A' 위에 추상화 단계를 쌓고자 가정하고 추상화한 클래스를 'B'라고 하자. 그렇다면 사용자는 이 클래스 'A'의 객체에 직접적으로 접근해서는 안되고, 클래스 'B'는 이 객체를 외부로 노출(유출) 시키는 행위를 지양해야 한다. 만약 단순히 클래스 'A'의 기능이 필요한 것 이라면, 굳이 클래스 'B'를 만들어서 추상화 단계를 늘릴 필요가 없다. 이러한 방식으로(외부에서 직접적으로 클래스 'A'를 사용하지 않게 함으로써) 외부에 제공할 기능의 제한과 확장 뿐 아니라, ..

래퍼 클래스가 필요할까? -> 기본적으로, D3D12는 이미 완결된 형태의 API를 제공 해준다. 하지만 여타 다른 모던 그래픽스 API들이 그러하듯이 D3D12 또한 방대하고 로우 레벨 기능들과 밀접하게 연관되어 있기에 사용하기 어렵다. (정확하게는 사용하기 어렵다기 보단, 올바르게 사용하기 어렵다) 다만, 게임이라는 어플리케이션 그리고 개인이 개발하는 엔진이라는 특수성을 생각하면 사실 D3D12의 모든 기능을 활용하고, 그 기능들을 조율하는 것은 매우 어렵다. 그러므로, 실제 활용 케이스를 잘 선별하고 최소한의 기능 셋만을 고려할 수 있게 래퍼 클래스들로 한 단계 추상화를 하여, 필요한 기능들만을 최소한의 고려만으로도 충분히 활용할 수 있도록 만드는 것이 중요하다고 생각한다. 다만 그렇다고 해서 모든..

좋은 API 란 -> 쓰기 쉽고, 유연하고, 오용하기 어려운 구조, 문서화가 잘 되어 있는 API 통일된 명명법 -> 함수명은 동사구, 변수명은 명사, 단 조건값(boolean)은 의문형 / 하나의 개념에는, 한가지 단어만 / 같은 기능을 하는 함수에는 같은 이름을 에러 핸들링 -> Exception은 일어날 수 있는 상황에 대한 처리를 / Assertion은 일어나서는 안되는 상황에 대한 처리를 메모리/객체 유효성 -> nullptr가 들어와서는 안되는 곳엔 포인터 대신 reference(&)를 읽기 쉬운 코드 -> 과도한 추상화가 적용되지 않아야 함 / 이른 최적화 보단 읽기(파악이) 쉬운 테스트가 치밀하게 된 코드 -> Unit test 보다는 적절한 Assertion이 더 높은 우선 순위를 가져야..