Manager 클래스 작성을 피하려면 어떻게해야합니까?

XxxManager게임 엔진 프로그래밍에서 스타일 클래스 를 사용하는 것은 좋지 않은 생각 이지만, 사용을 피하려고 할 때도 항상 모든 배우 / 엔터티 / 게임 세계 위치를 보유하고 행동하는 무언가로 끝납니다. Manager다른 이름 으로 if가됩니다.

실제로 따라하기 어려운 패턴입니까? 그렇다면 대안은 무엇입니까?

"관리자"클래스 는 여러 가지 이유로 문제가 될 수 있습니다. 두 가지 주요 이유는 다음과 같습니다.

• 이름이 불분명합니다 ( 실제로 "관리"에는 무엇이 포함 되며 관리되는 모든 유형의 항목에 대해 항상 동일합니까?)
• 그들은 단일 책임 원칙 을 위반하는 기능의 버킷으로 경향이 있습니다 (즉, 유형이 한 가지 일을해야 함)

종종 이러한 이유 중 하나가 다른 이유를 야기하거나 암시합니다.

이러한 문제는 명심해야 할 것이지만 실제로 게임 을 할 수있는 능력을 마비 시키지는 마십시오 . 결국 아무도 당신의 수업이 무엇인지 또는 무엇을하는지 신경 쓰지 않을 것입니다. 그들은 당신의 게임에 관심을 가질 것입니다.

대부분의 "관리자"를 두 부분으로 분리하는 것은 일반적으로 매우 쉽습니다.

• 실제 객체를 저장하고 해당 객체에 대한 액세스를 제공하는 부분 ( "스토어", "리포지토리", "데이터베이스", "캐시"또는 기타 다양한 것들이라고 부를 수 있음) 객체의 수명 동안, 즉 객체가이 유형의 인스턴스에서 제거되거나 더 이상 포함되지 않으면 객체가 존재하지 않습니다.

• 실제 객체 를 처리 하고 일부 작업을 수행 하는 부분 . 해당 객체를 업데이트하거나 ( "업데이트"또는 "시뮬레이션") 그리거나 객체를 그릴 수 있습니다 ( "서랍"또는 "렌더러"). 아니면 그들과 다른 일을 할 수도 있습니다. 중요한 것은 기본 목적에 따라 이름을 지정하는 것입니다. 일반적으로이 유형의 인스턴스에는 첫 번째 유형 (객체의 수명 만 처리하는 인스턴스)의 인스턴스 또는 참조를 제공합니다.

첫 번째 유형의 이름에 관리자가 포함될 수 있다는 합리적인 주장이 있을 수 있습니다 (일부 개체의 수명을 관리하기 때문에). "당신이 관리자를 부르지 말아라"라는 형태의 무릎을 꿇는 반응을 참 아야 할 수도 있지만, 그렇게하면 당신의 타입의 이름을 지정해도 세상은 끝나지 않을 것입니다.

댓글에서 링크 된 블로그 게시물을 읽으면 "다른 이름으로 관리자 인 경우"가 원하는 것임을 알 수 있습니다. 소프트웨어 개발에서 전역 변수가 사악하다는 것이 일반적인 합의이며, 유일한 대안은 다른 데이터가 데이터를 보유한다는 것입니다.

이름 FoobarManager이 지정된 클래스의 문제점 은 "관리자"라는 단어가 클래스의 실제 기능을 알려주지 않는다는 것입니다. 예를 들면 다음과 같습니다.

• foobars의 게임 메커니즘을 제어 할 때 이름을 지정할 수 있습니다 FoobarController.
• foobars를 인스턴스화하지만 컨트롤을 다른 것에 위임하면 a FoobarFactory또는 FoobarBuilder입니다.
• foobars를 화면에 그리면 a FoobarRenderer입니다.
• foobars가 생성 한 이벤트를 수신하면 a FoobarEventHandler입니다.
• foobars에서 무언가가 발생할 때까지 기다릴 때는 FoobarObserver입니다.
• 논리가없는 foobars 컬렉션에 대한 바보 같은 데이터 홀더 인 경우 이름을 지정하십시오 Foobars.

이 클래스의 이름을 "Manager"로 지정할 수 있습니다. 그러나 이러한 기능을 수행 할 수 있습니다. 그리고 나중에 위의 기능 중 또 다른 기능이 필요하다는 것을 알게되면 FoobarManager에도 통합 할 수 있습니다. 따라서 당신은 우려 의 분리 원칙 을 깨뜨리는 신의 대상으로 끝날 것입니다 (모든 수업은 정확히 한 가지 일을해야합니다).