OO 디자인 - 오브젝트가 간접적으로 보유하고있는 클래스에 질문합니다.

Question

간접적으로 그것을 보유하고있는 다른 오브젝트에 질문하는 오브젝트가 "나쁜"디자인인지 궁금합니다. 예를 들어 ...

요구 사항 : 문자 (개체)가 눈금으로 이동합니다. 다른 지점으로 이동하려 할 때 지점을 이미 차단했는지, 그리드 부분에 완전히 접근 할 수 없는지 여부를 알아야합니다. (캐릭터 자체가 알아야 할 점에 유의하십시오.)

응용 프로그램에서 상태는 tilemanager와 charactermanager를 보유합니다. tilemanager는 어떤 타일이 접근 가능하고 어떤 타일이 접근 가능한지를 안다. 캐릭터 매니저는 캐릭터의 타일 위치를 알고 있습니다.

캐릭터가 해당 상태에서 함수를 호출하는 것이 합리적일까요? AuthorizeMovement. TileManager와 CharacterManager를 통해 이동이 가능한지 여부를 결정하고 true이면 true를 반환하고 그렇지 않으면 false를 반환합니다.

이것은 중요한 원칙을 위반하여 길을 가로막고 있습니까?

분명히이 문제는 일반화되어 문제를 이해하는 데 필요한 것으로 제거됩니다.

Answer 1

문제가 없습니다. 좋은 OO 디자인은 많은 원칙을 가지고 있습니다. 그러나 핵심에는 캡슐화, 상속, 다형성 및 추상화가 있습니다. 또한 높은 결합력과 낮은 결합력이 필요합니다. 개체/클래스가 어디서나 적합 할 수 있으며 특정 구현이나 클래스에 묶여 있지 않다는 것을 의미합니다.

위와 같이 캡슐화 된 움직임과 문자를 별도의 클래스로 추상화 한 것처럼 들리는 것 같습니다. 그래서 Character 클래스가 보드를 직접 수정하지 않는다면, 그것은 나쁠 것입니다.

문제를보다 깊이있게 이해하면 언제든지 다른 원리를 활용하도록 디자인을 개선 할 수있는 코드를 리팩토링 할 수 있습니다.

Answer 2

나는 그것이 나쁜 디자인 일 가능성이 있음을 제안합니다. 말하자면 "붉은 깃발"은 순환 참조입니다. 당신은 말했다 :

이 ... 객체가 간접적으로도에서, 객체가 "열린"개체에 대한 참조가 "유지", 그래서 그것을

을 보유하고 다른 개체에 대한 질문 "질문하기"위해 "보류 된"객체는 "보류"객체에 대한 참조를 필요로합니다.

이것은 원형 객체 종속성 그래프를 작성하며 종종 코드 냄새입니다.

다른 클래스는 문자와 TileManager 및/또는 CharacterManager에 대해 아는 책임이 있어야합니다.

Answer 3

OOP 원칙에 위배되는 것은 아닙니다. 호출의 세부 사항은 완전히 추상화되어 있으며 어쨌든 State 객체에 의존합니다. 어떻게 다른 곳에서이 기능을 구현할 수 있습니까?

추상화 및 원리는 유용한 도구입니다. 그러나 당신은 당신의 코드를 선의 것으로 자격을 부여하기 위해 의존해서는 안됩니다. 모든 추상화 또는 모든 원칙이 모든 시나리오 또는 모든 가능한 구현에 적합하지는 않습니다. 그것들은 규칙이 아니라 지침입니다. 대체 구현을 빨리 볼 수 없다면이 구현을 사용하고 다시 구현하십시오.