Em que namespace você deve colocar as interfaces em relação aos seus implementadores?

Question

Especificamente, quando você cria um par de interface / implementador, e não há nenhuma preocupação organizacional substituindo (tais como a interface deve ir em um diferente conjunto ou seja, como recomendado pelo s # arquitectura) você tem uma maneira padrão de organização -los em seu namespace / esquema de nomenclatura?

Esta é obviamente uma opinião baseada pergunta mais, mas eu acho que algumas pessoas têm pensado mais sobre isso e todos nós podemos beneficiar de suas conclusões.

Answer 1

A resposta depende de suas intenções.

• Se você pretende o consumidor de seus namespaces utilizar as interfaces sobre as implementações concretas, eu recomendaria ter suas interfaces no namespace de nível superior com as implementações em uma criança namespace
• Se o consumidor é a utilização de ambos, tê-los no mesmo espaço de nomes.
• Se a interface é para predominantemente especializada uso, como a criação de novas implementações, considere tê-los em um espaço infantil, tais como design ou ComponentModel.

Estou certo de que há outras opções também, mas como acontece com a maioria dos problemas de nomes, se trata dos casos de uso do projeto, e as classes e interfaces que ele contém.

Answer 2

Eu costumo manter a interface no mesmo namespace de como os tipos de concreto.

Mas, isso é apenas a minha opinião, e layout de espaço de nomes é altamente subjetivo.

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

Você realmente não ganhar nada, movendo um ou dois tipos fora do namespace principal, mas você adicionar a exigência de um extra usando comunicado.

Answer 3

O que eu geralmente faço é criar um espaço de nomes Interfaces em um nível alto na minha hierarquia e colocar todas as interfaces de lá (eu não me incomodo para aninhar outros namespaces lá como eu, então, acabar com muitos namespaces que contêm apenas uma interface ).

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

Esta é apenas a maneira que eu tenho feito isso no passado e não tive muitos problemas com ele, embora reconheça que pode ser confuso para os outros sentar com meus projetos. Estou muito curioso para ver o que as outras pessoas fazem.

Answer 4

Eu prefiro manter meus interfaces e classes de implementação no mesmo namespace. Quando possível, eu dou as classes de implementação visibilidade interna e fornecer uma fábrica (geralmente sob a forma de um método de fábrica estático que delega para uma classe trabalhador, com um método interno que permite que um testes de unidade em um amigo de montagem para substituir um trabalhador diferente que produz topos). Claro, se a classe concreta deve ser pública - por exemplo, se é uma classe base abstrata, então isso é bom; Não vejo qualquer razão para pôr ABC em seu próprio namespace.

Em uma nota lateral, eu não gosto fortemente a convenção .NET de prefaciar nomes de interface com a letra 'I.' A coisa que os modelos de interface (I) Foo não é uma IFoo , é simplesmente um foo . Então, por que eu não posso simplesmente chamá-lo de Foo? Eu, então, nomear as classes de implementação especificamente, por exemplo, AbstractFoo, MemoryOptimizedFoo, SimpleFoo, StubFoo etc.

Answer 5

(. Net) que tendem a manter as interfaces em um "comum" separada de montagem para que eu possa usar essa interface em diversas aplicações e, mais frequentemente, nas componentes de servidor de meus aplicativos.

Em relação namespaces, eu mantê-los em BusinessCommon.Interfaces.

Eu faço isso para garantir que nem eu nem meus desenvolvedores são tentados a referenciar as implementações diretamente.

Answer 6

Eu odeio quando eu encontrar interfaces e implementações no mesmo namespace / montagem. Por favor, não faça isso, se os evolui de projeto, é uma dor na bunda para refatorar.

Quando eu referência a uma interface, eu quero implementá-lo, não para obter todas as suas implementações.

O que pode me ser admissível é colocar a interface com a sua classe de dependência ( classe que referências a interface ).

EDIT: @ Josh, eu Juste ler a última frase do meu, que é confuso! é claro, tanto a classe de dependência e aquele que implementa-lo referência a interface. A fim de fazer-me claro que eu vou dar exemplos:

aceitável:

Interface + implementação:

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();
       }
   }

classe de implementação:

namespace B;

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

Não aceitável:

namespace A;

   Interface IMyInterface
   {
       void MyMethod();
   }

namespace A;

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

E não crie um projeto / lixo para suas interfaces! exemplo: ShittyProject.Interfaces. Você perdeu o ponto!

Imagine que você criou um DLL reservado para suas interfaces (200 MB). Se você tivesse que adicionar uma única interface com duas linhas de códigos, os usuários terão que atualizar 200 MB apenas para dois signaturs mudos!

Answer 7

Separar as interfaces de alguma forma (projetos em Eclipse, etc), de modo que é fácil de implantar somente as interfaces. Isso permite que você fornecer sua API externa sem fornecer implementações. Isso permite que projetos dependentes de construir com um mínimo de fatores externos. Obviamente, isso se aplica mais aos projectos de maior dimensão, mas o conceito é bom em todos os casos.

Answer 8

Normalmente, eu separá-los em dois conjuntos separados. Uma das razões habituais para uma interface é ter uma série de objetos têm a mesma aparência para alguns subsistema do seu software. Por exemplo, eu tenho todos os meus relatórios de execução da IReport Interfaces. IReport é usado não só é usado na impressão, mas para visualizar e selecionar as opções individuais para cada relatório. Finalmente eu tenho uma coleção de IReport para uso em diálogo onde o usuário seleciona quais relatórios (e opções de configuração) que deseja imprimir.

Os relatórios residem em um assembly separado eo IReport, o motor Preview, mecanismo de impressão, seleções relatório residem no seu respectivo núcleo montagem e / ou UI montagem.

Se você usar a classe de fábrica para retornar uma lista de relatórios disponíveis no relatório conjunto, em seguida, atualizar o software com novo relatório torna-se meramente uma questão de copiar o novo relatório conjunto sobre o original. Você ainda pode usar a API Reflection para apenas digitalizar a lista de montagens para qualquer Fábricas de relatório e construir sua lista de relatórios dessa forma.

Você pode aplicar estas técnicas a arquivos também. Meu próprio software funciona uma máquina de corte de metal por isso usamos essa ideia para a forma e bibliotecas montagem que vendemos ao lado de nosso software.

Mais uma vez as classes que implementam uma interface núcleo deve residir em um assembly separado para que possa atualizar essa separadamente do resto do software.

Answer 9

Eu dou a minha própria experiência, que é contra outras respostas.

Eu tendem a colocar todos os meus interfaces no pacote que pertence. Isto concede que, se eu passar um pacote em outro projeto que eu tenho toda a coisa deve haver para executar o pacote sem quaisquer alterações.

Para mim, todas as funções auxiliares e funções de operador que fazem parte da funcionalidade de uma classe deve ir para o mesmo espaço de nomes como o da classe, porque eles fazem parte da API pública desse namespace.

Se você tem implementações comuns que partilham a mesma interface em diferentes pacotes, você provavelmente precisará refatorar seu projeto.

Às vezes eu vejo que há uma abundância de interfaces em um projeto que pode ser convertido em uma implementação abstrata vez que uma interface.

Então, pergunte-se se você está realmente a modelagem de um tipo ou de uma estrutura.