Será que o tamanho da matéria construtor se você estiver usando inversão de controle?

Question

Então eu tenho talvez 10 objetos cada um dos quais tem 1-3 dependências (que eu acho que é ok, como baixo acoplamento está em causa), mas também algumas configurações que podem ser usados ??para definir o comportamento (tempo limite, o tamanho da janela, etc).

Agora, antes de eu usar uma inversão do recipiente de controle I teria criado uma fábrica e talvez até mesmo uma simples ObjectSettings objeto para cada um dos objetos que exige mais do que uma definição para manter o tamanho do construtor para o recomendado "inferior a 4" tamanho parâmetro. Agora estou usando uma inversão do recipiente de controle e eu simplesmente não consigo ver tudo o que muito de um ponto para ele. Claro que eu poderia ter um construtor com 7 parâmetros, mas quem se importa? É tudo ser preenchido pelo COI de qualquer maneira.

Am I faltando alguma coisa aqui ou é basicamente correto?

Answer 1

A relação entre complexidade classe e o tamanho do construtor COI não tinha me ocorrido antes de ler esta pergunta, mas a minha análise a seguir sugere que ter muitos argumentos no construtor IoC é um código cheiro estar ciente de quando se usa IoC. Ter um objetivo de manter uma lista de argumentos curto construtor irá ajudá-lo a manter as próprias classes simples. Após a único princípio da responsabilidade irá guiá-lo para este objetivo.

Eu trabalho em um sistema que atualmente tem 122 classes que são instanciado usando a estrutura Spring.NET. Todos os relacionamentos entre essas classes são criados em seus construtores. É certo que o sistema tem seu quinhão de menos de código perfeito onde eu ter quebrado algumas regras. (Mas, hey, as nossas falhas são oportunidades para aprender!)

Os construtores dessas classes têm números de argumentos, que eu mostro na tabela abaixo variando.

Number of constructor arguments    Number of classes
           0                             57
           1                             19
           2                             25
           3                              9
           4                              3
           5                              1
           6                              3
           7                              2
           8                              2

As classes com zero argumentos são classes de estratégia tanto de concreto, ou classes que respondem a eventos de envio de dados para sistemas externos.

Aqueles com 5 ou 6 argumentos são todos um pouco deselegante e poderia usar alguma refatoração para simplificá-los.

As quatro classes com 7 ou 8 argumentos são excelentes exemplos de Deus objetos . Eles devem ser quebrados, e cada um já está na minha lista de regiões em crise dentro do sistema.

As classes restantes (1 a 4 argumentos) são (principalmente) simplesmente projetado, fácil de entender, e em conformidade com o único princípio da responsabilidade .

Answer 2

A necessidade de muitas dependências (talvez mais de 8) poderia ser um indicativo de uma falha de projeto, mas em geral eu acho que não há problema, desde que o projeto é coesa.

Além disso, considere usar um localizador de serviço ou gateway estático para preocupações de infra-estrutura, tais como o registo e autorização em vez de atravancar os argumentos do construtor.

EDIT: 8 provavelmente é demais, mas eu percebi que não seria o caso estranho para ele. Depois de olhar para o post de Lee Concordo, 1-4 geralmente é bom.

Answer 3

G'day George,

Em primeiro lugar, quais são as dependências entre os objetos?

Muitos dos relacionamentos "isa"? Lotes de relacionamentos "Hasa"?

Muita fã-in? Ou fan-out?

A resposta de George: "tem-um em sua maioria, foram tentando seguir a composição sobre o conselho herança ... por que isso importa embora"

Como é principalmente "Hasa" você deve estar tudo certo.

Melhor ter certeza que a sua construção (e destruição) dos componentes é feito corretamente embora para evitar vazamentos de memória.

E, se este estiver em C ++, certifique-se de usar destruidores virtuais?

Answer 4

Esta é uma pergunta difícil, e por isso sou a favor de uma abordagem híbrida, onde propriedades adequadas são propriedades mutáveis ??e só imutáveis ??e dependências necessárias sem um padrão útil fazem parte do construtor. Algumas classes são construídos com os elementos essenciais, em seguida, afinados, se necessário através de setters.

Answer 5

Tudo depende de que tipo de recipiente que você usou para fazer o COI eo que se aproxima o recipiente tem se usa anotações ou arquivo de configuração para saturar o objeto a ser instiantiated. Além disso, se os seus parâmetros do construtor são tipos de dados primitivos apenas simples, então não é realmente um grande negócio; no entanto, se você tiver tipos não-primitivos em seguida, na minha opinião, você pode usar a propriedade com base DI em vez de consutructor baseado DI.