구현자를 기준으로 인터페이스를 어떤 네임 스페이스에 넣어야합니까?

StackOverflow https://stackoverflow.com/questions/146777

  •  02-07-2019
  •  | 
  •  

문제

구체적으로, 인터페이스/구현 기 쌍을 만들면 조직의 우연한 문제가 없을 때 (예 : 인터페이스와 같은 S# 아키텍처에서 권장하는대로 인터페이스가 다른 어셈블리로 가야 함)에서이를 구성하는 기본 방법이 있습니까? 네임 스페이스/명명 체계?

이것은 분명히 더 많은 의견 기반 질문이지만 일부 사람들은 이것에 대해 더 많이 생각했으며 우리 모두는 결론을 통해 이익을 얻을 수 있다고 생각합니다.

도움이 되었습니까?

해결책

답은 당신의 의도에 달려 있습니다.

  • 네임 스페이스 소비자가 콘크리트 구현을 통해 인터페이스를 사용하도록 의도 한 경우, 하위 네임 스페이스의 구현과 함께 최상위 네임 스페이스에 인터페이스를 사용하는 것이 좋습니다.
  • 소비자가 두 가지를 모두 사용하려면 동일한 네임 스페이스에 두십시오.
  • 인터페이스가 새로운 구현을 작성하는 것과 같이 주로 특수한 사용을위한 경우, 디자인 또는 구성 요소 모드와 같은 자식 네임 스페이스에 넣는 것을 고려하십시오.

다른 옵션도 있다고 확신하지만 대부분의 네임 스페이스 문제와 마찬가지로 프로젝트의 사용 사례 및 포함 된 클래스 및 인터페이스에 달려 있습니다.

다른 팁

나는 보통 인터페이스를 콘크리트 유형과 동일한 네임 스페이스로 유지합니다.

그러나 그것은 단지 내 의견 일 뿐이며 네임 스페이스 레이아웃은 매우 주관적입니다.

Animals
|
| - IAnimal
| - Dog
| - Cat
Plants
|
| - IPlant
| - Cactus

메인 네임 스페이스에서 하나 또는 두 가지 유형을 옮기면 아무것도 얻지 못하지만 하나의 추가 명령문에 대한 요구 사항을 추가합니다.

내가 일반적으로하는 일은 계층 구조에서 높은 수준의 인터페이스 네임 스페이스를 만들고 모든 인터페이스를 거기에 넣는 것입니다 (나는 하나의 인터페이스 만 포함하는 많은 네임 스페이스로 끝나기 때문에 다른 네임 스페이스를 둥지로써 귀찮게하지 않습니다). 

Interfaces
|--IAnimal
|--IVegetable
|--IMineral
MineralImplementor
Organisms
|--AnimalImplementor
|--VegetableImplementor

이것은 내가 과거에 그것을 한 방식 일 뿐이며 많은 문제가 없었지만, 내 프로젝트와 함께 앉아있는 다른 사람들에게 혼란 스러울 수도 있습니다. 나는 다른 사람들이 무엇을하는지 매우 궁금합니다.

인터페이스와 구현 클래스를 동일한 네임 스페이스로 유지하는 것이 좋습니다. 가능하면 구현 클래스에 내부 가시성을 제공하고 공장을 제공합니다 (일반적으로 공장 (일반적으로 직원 수업에 위임하는 정적 공장 방법의 형태로, 친구 조립품의 단위 테스트가 다른 근로자를 대체 할 수있는 내부 방법을 제공합니다. 스터브를 생성합니다). 물론, 콘크리트 클래스가 공개되어야한다면, 예를 들어, 추상적 인 기본 클래스라면 괜찮습니다. ABC를 자체 네임 스페이스에 넣을 이유가 없습니다.

참고로, 나는 문자 'I'과 함께 인터페이스 이름을 조리하는 .NET 규칙을 강력히 싫어합니다. (i) foo 인터페이스 모델은 Ifoo, 그것은 단순히 a입니다 foo. 그래서 왜 그냥 foo라고 부를 수 없습니까? 그런 다음 구현 클래스의 이름, 예를 들어 AbstractFoo, MemoryOptimizedFoo, Simplefoo, Stubfoo 등을 구체적으로 지정합니다.

(.NET) 인터페이스를 별도의 "공통"어셈블리로 유지하는 경향이 있으므로 여러 응용 프로그램과 더 자주 내 앱의 서버 구성 요소에서 해당 인터페이스를 사용할 수 있습니다.

네임 스페이스와 관련하여, 나는 그것들을 BusinessCommon.interfaces에 보관합니다.

나는 나와 내 개발자가 구현을 직접 참조하려는 유혹을받지 않도록하기 위해이 작업을 수행합니다.

동일한 네임 스페이스/어셈블리에서 인터페이스와 구현을 찾을 때 싫어합니다. 그렇게하지 마십시오. 프로젝트가 진화한다면, 그것은 리팩터에 대한 엉덩이의 고통입니다.

인터페이스를 참조하면 모든 구현을 얻지 않기 위해 인터페이스를 구현하고 싶습니다.

내가 인정할 수있는 것은 종속성 클래스와 인터페이스를 두는 것입니다 (인터페이스를 참조하는 클래스).

편집 : @josh, 나는 저의 마지막 문장을 읽었습니다. 혼란 스럽습니다! 물론 종속성 클래스와이를 구현하는 클래스는 인터페이스를 참조합니다. 나 자신을 분명히하기 위해 예를들을 것입니다.

허용 :

인터페이스 + 구현 :

namespace A;

   Interface IMyInterface
   {
       void MyMethod();
   }

namespace A;

   Interface MyDependentClass
   {
       private IMyInterface inject;

       public MyDependentClass(IMyInterface inject)
       {
           this.inject = inject;
       }

       public void DoJob()
       {
           //Bla bla
           inject.MyMethod();
       }
   }

클래스 구현 :

namespace B;

   Interface MyImplementing : IMyInterface
   {
       public void MyMethod()
       {
           Console.WriteLine("hello world");
       }
   }

허용하지 않는다:

namespace A;

   Interface IMyInterface
   {
       void MyMethod();
   }

namespace A;

   Interface MyImplementing : IMyInterface
   {
       public void MyMethod()
       {
           Console.WriteLine("hello world");
       }
   }

그리고 인터페이스를위한 프로젝트/쓰레기를 만들지 마십시오! 예 : ShittyProject.interfaces. 당신은 요점을 놓쳤다!

인터페이스 (200MB)에 대한 DLL 예약을 만들었다고 상상해보십시오. 두 줄의 코드로 단일 인터페이스를 추가 해야하는 경우 사용자는 두 개의 멍청한 서명을 위해 200MB를 업데이트해야합니다!

인터페이스를 쉽게 배포 할 수 있도록 인터페이스를 어떤 방식으로 (일식 등으로 프로젝트) 분리하십시오. 이를 통해 구현을 제공하지 않고 외부 API를 제공 할 수 있습니다. 이를 통해 종속 프로젝트는 최소한의 외부를 사용하여 구축 할 수 있습니다. 분명히 이것은 더 큰 프로젝트에 더 많이 적용되지만 개념은 모든 경우에 좋습니다.

나는 보통 그것들을 두 개의 별도 어셈블리로 분리합니다. 인터페이스의 일반적인 이유 중 하나는 일련의 객체가 소프트웨어의 일부 하위 시스템과 동일하게 보이는 것입니다. 예를 들어 IREPORT 인터페이스를 구현하는 모든 보고서가 있습니다. IREPORT는 인쇄에 사용될뿐만 아니라 각 보고서의 개별 옵션을 미리보고 선택하는 데 사용됩니다. 마지막으로 사용자가 인쇄하려는 보고서 (및 구성 옵션 구성)를 선택하는 대화 상자에 사용할 ireport 모음이 있습니다.

이 보고서는 별도의 어셈블리와 IREPORT, 미리보기 엔진, 인쇄 엔진, 보고서 선택이 해당 코어 어셈블리 및/또는 UI 어셈블리에 있습니다.

공장 클래스를 사용하여 보고서 어셈블리에서 사용 가능한 보고서 목록을 반환하는 경우 새 보고서로 소프트웨어를 업데이트하면 원본을 통해 새 보고서 어셈블리를 복사하는 문제가됩니다. Reflection API를 사용하여 보고서 공장에 대한 어셈블리 목록을 스캔하고 보고서 목록을 작성할 수도 있습니다.

이 기술을 파일에도 적용 할 수 있습니다. 내 자신의 소프트웨어는 금속 절단 기계를 실행 하므로이 아이디어를 소프트웨어와 함께 판매하는 모양 및 피팅 라이브러리에 사용됩니다.

다시 코어 인터페이스를 구현하는 클래스는 별도의 어셈블리에 있어야하므로 나머지 소프트웨어와 별도로 업데이트 할 수 있습니다.

나는 다른 답변에 반대하는 내 자신의 경험을 제공합니다.

나는 모든 인터페이스를 그들이 속한 패키지에 넣는 경향이 있습니다. 이것은 다른 프로젝트에서 패키지를 이동하면 변경없이 패키지를 실행해야합니다.

저에게있어 클래스 기능의 일부인 헬퍼 기능 및 운영자 기능은 해당 네임 스페이스의 공개 API의 일부를 형성하기 때문에 클래스의 기능과 동일한 네임 스페이스로 들어가야합니다.

다른 패키지에서 동일한 인터페이스를 공유하는 공통 구현이있는 경우 프로젝트를 리팩터링해야 할 것입니다.

때로는 프로젝트에 인터페이스가 아닌 추상적 구현에서 변환 될 수있는 많은 인터페이스가 있음을 알 수 있습니다.

따라서 실제로 유형이나 구조를 모델링하고 있는지 스스로에게 물어보십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top