2016-07-05 2 views
1

제어 반전에 대해 3 가지 질문이 있습니다.제어 및 내부 클래스 반전

나는 C#을 사용 체스 프로그램을 짓고 있어요 나는 클래스 라이브러리의 숫자들로 코드를 부러. 아이디어는 보드 위치와 조각에 대한 모든 로직을 캡슐화하여 한 곳에서 움직이고 모든 로직을 & 개의 게임 데이터를 다른 곳으로 가져 오는 것에 대한 논리와 모든 체스 보드를 표시하는 데 대한 데이터 & 세 번째에있는 조각 (UI).

게임, 플레이어, 보드, 보드의 사각형 및 조각을 나타내는 인터페이스 & 클래스를 포함하는 응용 프로그램의 "비즈니스 계층"인 하나의 라이브러리가 있습니다. 이러한 각 개체에 대한 공용 인터페이스가 있습니다. 그러나 이러한 인터페이스를 구현하는 클래스는 내부 클래스입니다. 이 방법을 사용하면 라이브러리 외부의 코드가 인스턴스화되거나 내부 구조를 알 수 없으며 올바른 방법입니다. 클라이언트는 인터페이스의 속성 인 &을 사용해야합니다.

첫 번째 질문 :이 접근 방법이 괜찮습니까 아니면 어떻게 DI 교장을 위반합니까?

내가 인터페이스를 IoC 또는 IGame이 아닌 다른 인터페이스에 등록해야하는지 여부에 대해 고심하고 있습니다. 이는 클라이언트가 IGame을 구현하는 객체 만 만들 수 있고 다른 인터페이스를 구현하는 객체는 모두 함께 제공되기를 원하기 때문입니다. (내 말은, 당신은 준비가 만든 모든 64 개 사각형과에 32 개 조각 보드를 얻을, 새로운 게임을 만들 수 있습니다. 또는 당신은 저장된 게임 &에게 조각에에 배치 & 사각형이 &을 만들어 보드를 검색 할 자신의 이전 위치. 클라이언트가 해당 작업을 수행 할 필요 없음).

두 번째 질문 : 괜찮습니까? 아니면 종속성 주입 원리를 위반합니까?

IPiece 인터페이스는이 작품의 종류에 관계없이, 한 조각에 필요한 모든 기능을 정의합니다. UI가 조각을 표시하는 데 사용할 이미지의 리소스 ID를 작성하는 데 사용할 수있는 속성도 있으므로 클라이언트가 조각의 클래스를 알 필요가 없습니다.

문제는 (Bishop, Knight, King, Queen, RookPawn)에서 내려 Piece 6 자식 클래스라는 IPiece 인터페이스를 구현 한 추상 기본 클래스가 있다는 것입니다. IPiece 인터페이스에 대해이 모든 클래스를 등록하는 방법을 모르거나해야하는 경우에도.

나는 클라이언트가 그들이 작업하고있는 어떤 종류의 작품에 대해 걱정할 필요가 없도록하고 싶지 않다. 새로운 게임이 시작되면 IGame 인터페이스의 방법으로 보드에 자동으로 배치 된 조각이 &으로 생성됩니다. 저장된 게임을로드하면, 클라이언트가 데이터를 검색하고 메소드에 전달하는 것 외에는 다른 작업을 수행 할 필요없이 동일한 인터페이스의 다른 메소드를 사용하여 저장된 위치의 보드에 조각을 만들고 이동시킬 수 있습니다. 이는 체스 엔진 라이브러리 내부에서 IoC를 사용하지 않고 내부 클래스가 인스턴스화된다는 것을 의미합니다.

아이디어는 클라이언트가 객체의 클래스를 알 필요가없이 정확히 모든 부분을 화면상의 보드에 그려 넣는 것입니다. 클라이언트가 필요로하는 모든 정보는 IPiece 인터페이스에 의해 정의 된 특성으로 제공됩니다.

세 번째 질문 : IBishop 등을 정의해야합니까? &은 IoC 매핑이 클래스 라이브러리 외부에서 절대로 사용되지 않더라도 인터페이스 IoC에 클래스를 등록합니까?

+1

나는 당신이 공장을 들여다 볼 필요가 있다고 생각하고, 그들이 속해있는 개별 피스 참조를 유지할 수 있다고 생각한다. 내가 당신에게 줄 수있는 공장을 사용하여 구현하는 방법에 대한 몇 가지 샘플과 함께 [대답은 여기에 (http://stackoverflow.com/questions/38193830/dependency-injection-and-project-references/38195003#38195003) 게시 생각. 이 질문은 주제에 관한 다른 관련 정보와도 연결됩니다. – Tone

답변

1
  1. 이론적으로 당신은 괜찮을 것입니다. 그러나 IoC/DI의 가장 큰 이점은 테스트를 훨씬 쉽게 할 수 있다는 점을 고려하면 테스트 할 때 구현에 대한 참조가 필요할 것입니다. 즉, 당신은 InternalsVisibleToAttribute에 의지 할 수 있습니다. 또는 유닛 테스트를하지 않을 경우에는 필요하지 않을 수도 있습니다 (강력히 권하고 싶지만).
  2. 여기에도 좋은 추리가 들립니다. 당신은 최소한의 방식으로 이것을 할 수 있습니다 : 아무것도 등록하지 않고, 코드를 실행하고, 타입이 필요할 때 함께 등록하는 것부터 시작해야합니다.
  3. 이전과 마찬가지로, 알아야 할 필요가 있습니다. 또는 귀하의 경우에 적합한 경우 @ Tone의 제안을 따라 가십시오 - 모든 생성 논리를 유지하기 위해 구현 된 IPieceFactory가 있어야합니다.
+0

그건 의미가 있습니다. 각 클래스의 메서드 각각에 대해 단위 테스트를 작성해야합니다. 나는 내부 테스트가 테스트에 미치는 영향에 대해서는 생각하지 않았습니다. 나는 이것을 약간 생각할 것이다. –