Como classificar classes associadas de diferentes projectos

Question

Eu tenho uma situação onde eu estou refatoração de código antigo, desmontando um projeto monstro velho e dividindo-o (por várias razões) em projectos sub menores. Um projeto vai acabar contendo principalmente as interfaces enquanto suas implementações associadas estão em outro projeto, e eu não tenho certeza sobre a melhor maneira de criar a estrutura do pacote.

Devo ir para

org.company.interfaceproject.util.InterfaceClass e
org.company.implementationproject.util.ImplementationClass

ou

org.company.project.util.InterfaceClass e
org.company.project.util.ImplementationClass

, onde a primeira implementação tem a vantagem de apontar para o qual projetar os arquivos pertencem, enquanto o segundo em não se mistura no fato de que os arquivos estão em diferentes projectos em tudo.

Eu acho que não existe certo e errado aqui, mas estou curioso para saber se alguém tem alguma opinião sobre o assunto.

Answer 1

Sim, você precisa apenas chegar a uma convenção de nomenclatura. Normalmente uma combinação de ambos tem adequados nossa empresa a ambigüidade evitar. Por exemplo, digamos que você tinha uma interface:

org.company.service.UserService

Então, nós usaríamos o seguinte para a classe de implementação que estava ligado por, ou teve, dependências primavera:

org.company.service.spring.UserServiceImpl

Isso, então, tem o melhor dos dois pontos de vista:

1. Você tem as classes de forma limpa em um pacote separado
2. Usando esta convenção nome da classe, é claro que a sua uma implementação de UserService, e mesmo ainda distinguíveis quando ambos os pacotes são importados.

Answer 2

Ambos têm méritos. Em última análise, depende de você intenções para o projeto. Se sua intenção é, eventualmente, criar implementações alternativas das interfaces pode fazer mais sentido para ir com a opção 1. Se esta será a única implementação da opção de interfaces de 2 seria mais razoável.

Answer 3

A Sun tem Convenções de nomenclatura . Para pacotes:

O prefixo do nome de um pacote único é sempre escrito em todos os-minúsculas letras ASCII e deve ser um dos nomes de domínio de nível superior, atualmente com, edu, gov, mil, net, org, ou um dos Inglês two códigos -Carta identificando países como especificado na norma ISO 3166 de 1981.

componentes subsequentes do nome do pacote variam de acordo com as próprias convenções de nomenclatura interna de uma organização. Tais convenções pode especificar que certos componentes de nomes de diretório ser nomes divisão, departamento, projeto da máquina, ou login.

Então, eu preferiria a segunda opção, onde você especificar o nome do projeto. Ou eu iria fundir tanto assim:

org.company.project.interfacepackage.util.InterfaceClass and
org.company.project.implementationpackage.util.ImplementationClass

Answer 4

Se você pode, você deve colocar as clases de interface em um plugin / pacote separado. Quando você usa interfaces que na maioria das vezes vai ter mais do que uma implementação desta interface.

Eu preferiria a opção 1

Answer 5

Na maior parte concordar com Clinton.

Em última análise, cada nome de pacote é uma ilha, tanto quanto Java está em causa, mas pode ser útil para separar as coisas de acordo com o que é montado com o que em tempo de compilação, como em:

com.foo.client.*
com.foo.server.*
com.foo.common.*

Na maior parte isso mantém o seu conjuntos de arquivos simples formiga. Note que isso se aplica mesmo se o layout de arquivos de origem é muito diferente, devido à forma como as coisas são construídas ou qualquer outra coisa. A única coisa que eu diria é ter cuidado para não obter o mesmo pacote em mais de um diretório de origem! Isso pode ser feio e é fácil de fazer por acidente.

Assim a menos que esse tipo de pensamento empurra-lo para criar pacotes de alto nível separados, eu gosto do estilo de colocar o pacote de implementação dentro do pacote interface, dando a impl empacotar um nome que sugere como é especializada, e de nomear o FooImpl implementação. Você quase nunca precisa importar várias implementações, mas você ocasionalmente quer importar tanto a interface e impl, e, nesse caso, é bom se eles têm um nome similar.