Estrutura de injeção de dependência para o cacau?

O Interface Builder pode ser usado para injeção de dependência básica em um aplicativo Cocoa, mas alguém está ciente de estruturas de injeção de dependência mais completas para Objective-C / Cocoa para quando você não deseja instanciar objects em um arquivo NIB?

Editar

Para esclarecer, reconheço que o IB pode ser usado para DI básico, mas estou procurando um framework com funcionalidade mais completa, incluindo configurações separadas de produção e teste, ao longo das linhas de Groovy ou Springs.

Eu acho que você vai achar que você não precisa dele em linguagens de binding tardia como Objective C, Ruby, Lisp e assim por diante. Como a revelação de Jamis de que ele estava indo por um caminho excessivamente complexo ao tentar construir uma agulha, uma estrutura de DI para Ruby- Net :: SSH foi revisitada .

Aqui estão alguns links que lhe darão algumas amostras de código para fazer coisas parecidas no Objetivo C. Com as categorias você pode essencialmente mudar o comportamento de qualquer class em tempo de execução. Veja Mac Developer Tips – Objective-C: Categorias e os documentos da API Cocoa em categorias . Essencialmente você não precisa de um lugar central para pedir “o que faz x” que é configurável, porque você pode instanciar TheThingThatDoesX diretamente e, se alguma outra coisa precisar mudar / enganchar nesse comportamento, ele pode usar categorias.

objeção por AtomicObject. Está moldado à imagem de Guice.

Eu vou sair em um membro e falar sobre isso. A injeção de dependência, como descrita pela resposta principal, não aborda a questão central que aqueles que procuram usá-la estão tendo. Gostaríamos de um meio de desenvolvimento em que o componente A não instancia diretamente ou faça referência ao componente B. O componente A é vinculado por protocolo ao componente B e não é referenciado pelo componente A. Isso permite que o componente B seja substituído a qualquer momento sem nunca Tocando componente A. Eu down votou, mas vou pesquisar suas referências, parece que há alguns que concordam com você. Não estou tentando debater, apenas procurando aprender. Eu gostaria de entender mais sobre a abordagem “não é necessário fazer isso”.

Tufão

Quase um ano atrás, eu lancei: https://github.com/typhoon-framework/Typhoon

O site Typhoon lista os principais resources. Um resumo rápido:

  • Não invasivo Nenhuma macro ou XML é necessário. Usa uma poderosa abordagem de tempo de execução do Objective-C .

  • Torna fácil ter várias configurações da mesma class de base ou protocolo.

  • Sem seqüências de caracteres mágicas – oferece suporte à refatoração de IDE, conclusão de código e verificação de tempo de compilation.

  • Suporta injeção de controladores de visualização e integração de storyboard.

  • Suporta injeção de inicializador e de propriedade, além de gerenciamento de ciclo de vida.

  • Poderosos resources de gerenciamento de memory. Fornece objects pré-configurados, sem a sobrecarga de memory dos singletons.

  • Excelente suporte para dependencies circulares.

  • Lean. Ele tem uma pegada muito baixa, portanto, é apropriado para dispositivos com CPU e memory restrita.

  • Testado em batalha – usado em todos os tipos de aplicativos em destaque no Appstore

  • Uma equipe central internacionalmente distribuída (nós até mesmo monitoramos o StackOverflow), então o suporte para qualquer uma das suas perguntas nunca está longe 🙂

API Docs e aplicativo de amostra

Controle de qualidade:

Também mantemos um sistema robusto de controle de qualidade.

  • Todo commit desencadeia uma série de testes de regressão
  • Mantemos alta cobertura de teste.

Você não precisa instanciar o object no arquivo NIB. Se você definir o proprietário do arquivo para a class do seu object e, em seguida, vincular as coisas na exibição / janela / o que quer que seja, você pode definir seu object como proprietário em tempo de execução carregando o arquivo nib manualmente. Dessa forma, você pode ter uma instância dinâmica de um object que ainda recebe as dependencies injetadas corretamente.

E sobre a implementação de injeção de dependência no Objective-IOC?

E quanto ao ObjectivePim? ObjetivoPim

Eu escrevi um contêiner DI muito simples, o código está no GitHub . Só pode fazer o básico, ou seja. descubra as dependencies de um object e satisfaça-as usando outros objects dados. Eu descobri que para ser utilizável em aplicações do mundo real, o código é muito simples e divertido de se usar.

Alguém olhou para o recurso Referências Associativas do Mac OS X 10.6?

Acredito que com isso seria possível construir ou já ter algo parecido com o DI. Tanto quanto eu vi no entanto qualquer referência que é necessária em um object tem que ser buscada manualmente usando objc_getAssociatedObject ().

Manfred

O Interface Builder não faz nenhuma injeção de dependência. Não precisa. O Construtor de Interface serializa objects. Quando uma ponta é “acordada” (aka aberta), não há “dependencies” para resolver – há apenas propriedades para definir. Muito simples. Abrir uma ponta depende unicamente do protocolo NSCoding e da codificação do valor-chave.

dependency injection, praticamente um projeto de make-work na melhor das hipóteses, ou na melhor das hipóteses uma camada de cola generalizada entre componentes projetados de forma independente, não tem utilidade no código Objective-C bem escrito. Você está pedindo uma ferramenta que você não precisa.

No Objective-C, o software que requer um serviço anônimo declara um protocolo. Os serviços então adotam esse protocolo. Clientes carregam serviços como plug-ins dynamics. Por outro lado, se o servidor foi escrito antes do cliente, é simplesmente uma questão de escrever um novo plug-in que adapta a interface existente ao protocolo. Isso é menos trabalhoso e mais direto do que tentar definir um sistema intermediário baseado em dados para “descobrir” (por favor) uma interface em tempo de execução.

Não é óbvio para todos que o grande segredo da DI é apenas uma maneira de escrever código em XML em vez de na linguagem nativa? Eu realmente gostaria de ouvir um bom argumento sobre como o XML é, de alguma forma, uma linguagem de programação melhor do que uma linguagem de programação real. Não faz nenhum sentido.

Eu trabalho com a spring durante todo o dia e verifiquei o Groovy. Eu não sou de modo algum um expert em XCode / Cocoa, mas o IB faz apenas algumas injeções de dependência, o que o Groovy nem mesmo alega estar fazendo.

Eu acho que você não está procurando por DI, mas sim por um conjunto bem compilado de bibliotecas integradas que evita que você digite muito código que outras pessoas também digitaram. Eu acho que não há frameworks como Spring para o Cocoa porque, por alguma razão, as pessoas tendem a ver o “Open Source” como “não depende da plataforma” e, portanto, Cocoa é um pouco deixado de fora no frio.

Dependendo das suas necessidades, existem algumas boas bibliotecas de código aberto disponíveis para o Cocoa, todas listadas no CocoaDev em uma boa lista .

Eu sei que não é primavera, mas espero que ajude.

DI é uma propriedade de um ambiente de execução em tempo de execução que requer vinculação dinâmica. Eu sou muito novo em Obj-C e Cocoa, então eu posso falar fora de vez. A menos que eu esteja perdendo alguma coisa, não vejo como alguém poderia implementar o DI exceto interpretando Obj C ao invés de compilá-lo, ou modificando o ambiente de tempo de execução.

Eu suspeito que o DI como o comportamento do IB é porque há um ambiente de tempo de execução específico do domínio associado a aplicativos que são construídos com ele.

Estou feliz de ser corrigido embora.

As categorias parecem ser uma implementação do mixin, permitindo o envio dynamic de methods para um delegado. Bastante bacana e semelhante ao conceito de interface do Java, achei que os detalhes diferem e, a partir do seguinte, não consigo ver se as constantes podem ser definidas em uma categoria, embora os campos do membro não possam.

categorias objective-c