OK .. 모든 토론 후에 내가 다루고있는 구체적인 예를 더 잘 반영하기 위해 질문을 약간 변경하고 있습니다.

나는이 개 수업을 ModelOne하고 ModelTwo이 클래스는 기능의 유사한 유형을 수행하지만 서로 관련이없는. 그러나 나는 제 3 유형이 CommonFunc모두 구현되어 일부 공공 기능을 포함 ModelOne하고 ModelTwo및 당 밖으로 고려되었습니다 DRY. 두 모델은 클래스 내에서 인스턴스화됩니다 ModelMain(자체는 상위 레벨 등에서 인스턴스화되지만이 레벨에서 중단됩니다).

사용중인 IoC 컨테이너는 Microsoft Unity 입니다. 나는 전문가 인 척하지 않지만, 컨테이너에 인터페이스와 클래스의 튜플을 등록하고 구체적인 클래스를 원할 때 특정 인터페이스와 일치하는 객체에 대해 IoC 컨테이너에 요청한다는 것입니다. 이것은 Unity에서 인스턴스화하려는 모든 객체에 대해 일치하는 인터페이스가 있어야 함을 의미합니다. 각 클래스는 서로 다른 (겹치지 않는) 기능을 수행하기 때문에 인터페이스와 클래스 ¹ 사이에 1 : 1 비율이 있음을 의미합니다 . 그러나 내가 쓰는 모든 수업에 대해 인터페이스를 노예로 쓰고 있다는 의미는 아닙니다.

따라서 코드 현명한 나는 ² :

public interface ICommonFunc
{
}

public interface IModelOne
{
   ICommonFunc Common { get; }
   ..
}

public interface IModelTwo
{
   ICommonFunc Common { get; }
   ..
}

public interface IModelMain
{
  IModelOne One { get; }
  IModelTwo Two { get; }
  ..
}

public class CommonFunc : ICommonFunc { .. }

public class ModelOne : IModelOne { .. }

public class ModelTwo : IModelTwo { .. }

public class ModelMain : IModelMain { .. }

문제는 솔루션을 구성하는 방법에 관한 것입니다. 수업과 인터페이스를 함께 유지해야합니까? 아니면 클래스와 인터페이스를 함께 유지해야합니까? EG :

옵션 1- 클래스 이름으로 구성

MySolution
  |
  |-MyProject
  |   |
      |-Models
      |   |
          |-Common
          |   |
          |   |-CommonFunc.cs
          |   |-ICommonFunc.cs
          |
          |-Main
          |   |
          |   |-IModelMain.cs
          |   |-ModelMain.cs
          |
          |-One
          |   |
          |   |-IModelOne.cs
          |   |-ModelOne.cs
          |
          |-Two
              |
              |-IModelTwo.cs
              |-ModelTwo.cs
              |

옵션 2- 기능별로 구성 (주로)

MySolution
  |
  |-MyProject
  |   |
      |-Models
      |   |
          |-Common
          |   |
          |   |-CommonFunc.cs
          |   |-ICommonFunc.cs
          |
          |-IModelMain.cs
          |-IModelOne.cs
          |-IModelTwo.cs
          |-ModelMain.cs
          |-ModelOne.cs
          |-ModelTwo.cs
          |

옵션 3- 인터페이스 및 구현 분리

MySolution
  |
  |-MyProject
      |
      |-Interfaces
      |   |
      |   |-Models
      |   |   |
      |       |-Common
      |       |   |-ICommonFunc.cs
      |       |
      |       |-IModelMain.cs
      |       |-IModelOne.cs
      |       |-IModelTwo.cs
      |
      |-Classes
          |
          |-Models
          |   |
              |-Common
              |   |-CommonFunc.cs
              |
              |-ModelMain.cs
              |-ModelOne.cs
              |-ModelTwo.cs
              |

옵션 4- 기능 예제 추가

MySolution
  |
  |-MyProject
  |   |
      |-Models
      |   |
          |-Components
          |   |
          |   |-Common
          |   |   |
          |   |   |-CommonFunc.cs
          |   |   |-ICommonFunc.cs
          |   |
          |   |-IModelOne.cs
          |   |-IModelTwo.cs
          |   |-ModelOne.cs
          |   |-ModelTwo.cs
          |
          |-IModelMain.cs
          |-ModelMain.cs
          |

경로의 클래스 이름으로 인해 옵션 1을 싫어합니다. 그러나 IoC 선택 / 사용으로 인해 1 : 1 비율로 경향 이 있습니다. 논쟁의 여지가있을 수 있습니다)이 파일 사이의 관계를 보는 장점이있다.

옵션 2는 저에게 호소력이 있지만 지금은 ModelMain 모델과 하위 모델 .

옵션 3은 인터페이스 정의를 구현에서 분리하는 데 사용되지만 이제 경로 이름에 이러한 인공 휴식이 있습니다.

옵션 4. 옵션 2를 사용하여 구성 요소를 상위 모델과 분리하기 위해 조정했습니다.

다른 것을 선호 할만한 이유가 있습니까? 아니면 내가 놓친 다른 잠재적 인 레이아웃?

^{1. Frank는 1 : 1 비율로 C ++ 일의 .h 및 .cpp 파일로 돌아가는 것을 언급했습니다. 나는 그가 어디에서 왔는지 안다. Unity에 대한 나의 이해가 나를이 코너에 넣는 것 같지만, 당신이 또한 욕설을 따르는 경우 어떻게 그것을 벗어날 수 있는지조차 확실하지 않습니다. 그러나 그것은 Program to an interface 다른 날 토론입니다.}

^{2. 각 객체 생성자의 세부 사항을 생략했습니다. 이것은 IoC 컨테이너가 필요에 따라 개체를 주입하는 곳입니다.}

답변