"ResourceManager"클래스가 잘못된 것으로 간주되면 대안은 무엇입니까?

다음과 같은 상충되는 의견이 있습니다.

• "전용 관리자 클래스는 결코 올바른 엔지니어링 툴이 아닙니다"
• "전담 관리자 수업은 (현재) 수천 개의 자원이있는 대규모 프로젝트에서 살아남는 가장 좋은 방법입니다."

다음 기능을 가진 클래식 ResourceManager 클래스를 보자.

• 에셋 (텍스처, 오디오, 3D 모델 등)로드
• 캐시를 유지하여 자산이 한 번만로드되도록 보장
• 참조는 자산을 할당 해제 할 수 있는지 판별하기 위해 자산을 계산합니다.
• 실제 자산의 출처를 숨 깁니다 (예 : 자산 당 하나의 파일이거나 하나의 패키지 파일에있는 모든 자산이거나 네트워크를 통해 자산을로드 할 수도 있음)
• 프로그램을 다시 시작하지 않고도 에셋을 다시로드 할 수 있으며, 이는 게임을하는 아티스트에게 매우 유용합니다.

이 ResourceManager 객체를 싱글 톤이 아닌 척하는 것으로 테이블에서 "싱글 톤이 나쁘다"라는 인수를 가져 와서 의존성 주입을 통해 전달해 봅시다 .

그런 다음 "공장 사용"또는 "공장 호출"인수가 있습니다. 이것에 대한 나의 문제는 그렇습니다. 공장입니다. 그러나 캐시와 리 로더이기도합니다 (더 나은 단어가 없음). 팩토리라고 부르는 것이 제대로 설명되어 있지 않으며, 적절한 팩토리로 만들면 캐싱 및 리로딩이 어디서 구현됩니까?

"관리자"클래스는 종종 잘못된 아키텍처의 증상이지만이 특별한 경우 어떻게 재구성하고 모든 기능을 유지할 수 있을까요? "관리자"클래스가 실제로 적절한 상황입니까?

문제는 이것이 나쁜 디자인이라는 것이 아니라고 생각합니다. 문제는 "관리자"라는 이름이 "업데이트"및 "프로세스"및 "액터"와 같이 설명 적이 지 않다는 것입니다. 이 시스템을 이해하려고 시도하는 사람에게는 도움이되지 않으며 자산에 대해 일부 작업을 수행하는 다른 클래스가있는 경우 혼동을 일으 킵니다.

그러나 목적을 효율적으로 전달하는 방식으로 이름을 짓는 것은 실제로 매우 어렵습니다 . 대부분의 시스템은 너무 복잡하여 이름으로 명확하게 표현할 수 없습니다. 당신이 할 수있는 최선의 방법은 특정 아이디어가 클래스를 응집력있게 만드는 것과 다른 클래스가 분명히 다른 것을 필요로하는 것을 좁히고 종류에 맞는 독특한 단어를 선택하는 것입니다.

좋은 이름의 가장 중요한 기능인 IMHO는 사람들이 볼 수있는 상황 (코드 기반) 내에서 고유하며 기억하기 쉽다는 것입니다. 테스트는 코드를 잘 알고있는 팀원들과 대화를 나눌 수 있다는 것입니다. 참조 문서를 작성해야 할 경우에도 도움이됩니다.

마지막으로, 그 응집력있는 아이디어를 설명 할 수 없다면, 그다지 응집력이 없을 수도 있습니다. 예를 들어, AssetCache에서 캐싱 및 참조 계산을 분리하고 AssetLoader에로드를 유지할 수 있습니다. 그러나 그것은 실제로 코드가 얼마나 복잡하고 얽혀 있는지에 달려 있습니다.

그러나 AssetManager가 응집력이 있고 게임에서 AssetManagery가 아닌 다른 이름이라면 완벽하게 좋은 이름 일 수 있습니다.

"한 곳에서이 작업을 수행합니까, 아니면 여러 작업을 수행합니까?"

로딩 로직은 일반적으로 애플리케이션의 주요 지점에서만 실행되는 경향이 있기 때문에 일반적으로 단일 액세스 지점으로 중앙 집중화됩니다. 이는 일반적으로 앱 시작, 게임 레벨 시작 또는 플레이어 세계 위치에서 경험을 원활하게 유지하기 위해 새로운 청크를로드해야하는 경우에 발생합니다. 이것이 일괄 처리로 수행된다는 것을 고려하면 (하나의 대규모 청크 또는 많은 작은 청크에서 실제로 중요하지 않은지 여부)이 프로세스를 시작하기 위해 호출 할 메소드 또는 메소드 세트가 하나있는 것이 좋습니다.

대부분의 플랫폼에서 로딩은 비동기식이므로 실제로 리소스 선택 기능을 자체 클래스로 추상화하는 또 다른 이유 인 로딩 및 기타 앱 로직에 대한 코드 흐름을 별도로 유지하는 것 외에는 선택의 여지가 거의 없습니다.

마지막으로 고려해야 할 몇 가지 사항 :

예를 들어 리소스로드는 자주 실행되지 않습니다. 게임 로직을 사용하려면 개별 게임 객체에 복잡성을 추가하는 것이 가치가 있습니까? 게임 오브젝트는 일반적으로 가능한 한 밝게 유지되며 시뮬레이션 중에 필요한 것만을위한 것입니다.

자신의 창작과 파괴에 책임 이 있는 대상인가? 이것은 엔터티 관리 중에 심각한 두통을 유발할 수 있습니다. 객체가 리소스 생성을 포함하여 자체 생성 프로세스를 수행 할 것으로 예상되는 경우 객체 자체를 파괴 할 책임이 있습니다. 이로 인해 댕글 링 / 널 포인터가 발생할 수 있으므로 실제로 외부에서 관리해야합니다. 해당 문제를보다 자세하게 설명하는 이 답변을 참조하십시오 .

추신 : 일반적인 "싱글 론은 끔찍한"유형의 인수 (끔찍하게 독단적 인 것)를 제외하고 ResourceManager에 대해 좋은 논쟁을 본 적이 있습니까? "전용 관리자 클래스는 결코 올바른 엔지니어링 툴이 될 수 없습니다"는 이 특정한 경우에 전혀 논쟁의 여지가 없습니다 .