Rodrigo Allemand

Antes de mais nada, este post não é – como nenhumk dos outros desta série – focado extritamente em DDD. Leia o primeiro post da séries para entender melhor…

Em qualquer sistema OO, vc trabalha com….. objetos (ohhhhhhhh)

Qualquer objeto ‘precisa’ ser….. criado antes de ser utilizado…. (ohhhhhhh)

Qual a melhor maneira de se criar objeto? (errr…. humm….. bem…….)

Muitas são as maneiras… usando um construtor, por DI (Dependency Injection), por fábricas, etc.

O mais utilizado são as fábricas, ou Factories conforme catalogado pelo GoF, ou Gang of Four.

Resumidamente, “o padrão Factory fornece uma interface para a criação de famílias de objetos correlatos ou dependentes sem a necessidade de especificar a classe concreta destes objetos”.

Diversos exemplos de fábricas existem espalhados pela internet, e eu não vou colocar mais um aqui. Procure, rs!

A motivação inicial do padrão era a criação de objetos complexos, fazendo com que a lógica estivesse toda em um unico lugar… princípio de DRY nos promórdios da Arquitetura de Software!

Porém, certos objetos alem de serem complexos, precisavam de um processo de construção demorado. Algumas tecnicas para a sulução deste problema era ‘reter’ o objeto contruido e utilizá-lo como um ponto de acesso único, otimizando assim o processo de construção.

Com isso, por muitas vezes os desenvolvedores juntavam dois padrões de projetos para sanar o problema de contrução complexa e demorada, utilizando Factory e ‘Singletons’ para colocar objetos a disposição do ‘domínio’.

Colocar fábricas a disposição dos desenvolvedores, por muitas vezes, mascarava onde realmente estes objetos deveriam ser criados. Poderiam existir inúmeras fábricas em um único projeto, como eu já presenciei num passado não muito distante. Era DaoFactory pra cá, AbstractDaoFactory pra lá, ReportFactory aqui e ServiceFactory acolá! Uma verdadeira macarronada de factories!

Então, como manter um ponto único de acesso para ‘encontrar’ os objetos?

Fowler resolveu colocar tudo em um unico padrão e o nomeou de Registry, ou Registro.

De acordo com Fowler, Registry é

Um objeto conhecido que outros objetos podem usar para encontrar objetos e serviços comuns.

A função do Registro é:

1. Criar objetos
2. Encapsular complexidades de criação
3. Reter objetos criados
4. Funcionar como ‘local dos objetos’

Com isso, se você quizer saber ou precisar de um objeto e o seu sistems tem um Registro, pergunte a ele!

Normalmente os Registros são factories e singletons mesclados, conforme o exemplo abaixo:

public MyDomainRegistry{
    private static MyDomainRegistry INSTANCE = null;

    private MyDomainRegistry(){
        loadVariables();
    }

    private static MyDomainRegistry instance(){
        //Coloque aqui a sua implementação de Singleton
        return INSTANCE;
    }

    //Posso usar SubDomains
    private ConsultarSubDomain consultarSubDomain;
    //Posso usar Services Services
    private ConversaoService conversaoService;
    //Qualquer objeto que eu queira localizar!
    private MyRepository myRepository;

    private void loadVariables(){
        //Aqui vc deve criar os seua objetos como achar melhor
        this.consultarSubDomain = new ConsultarSubDomain();
    }

    //Aqui vc coloca os métodos estáticos para retornar
    //os objetos que o registro precisa controlar
    public static ConsultarSubDomain consultarSubDomain() {
        return instance().consultarSubDomain;
    }
}

Bem simples, não?

Agora, para você utilizar um objeto, basta solicitar ao registro, assim.

public class FachadaDoDominio {

    private FachadaDoDominio() {
    }

    public static ConsultarSubDomain consultar(){
        return MyDomainRegistry.consultarSubDomain();
    }
}

Comente e Recomende!

Recentemente um desenvolvedor da minha equipe e eu estavamos conversando sobre como dar soluções bem feitas. Ele se queixava de demorar muito para achar uma solução, construindo e re-construindo por muitas vezes um determinado pedaço de código até chegar a uma solução realmente boa. Refactoring é a saida para um bom código, mas existem outos pontos de falha na sua maneira de programar.

O conhecimento hoje é uma jóia que está a apenas alguns cliques de todos nós. Hoje em dia se aprende desde a fazer arroz a até uma bomba nuclear. Mas como adquirir conhecimento na nossa área? Como programar melhor? Como otimizar o seu tempo de desenvolvimento? Muitas dessas respostas estão a disposição de todos os programadores desde o inicio do ano 2000, numa das melhores -senão a melhor – compilações de boas práticas para a área de desenvolvimento de software.

Trata-se do livro The Pragmatic Programmer, From Journeyman to Master, de Andrew Hunt e David Thomas. Eu já li o livro pelo menos umas duas vezes (falando nisso, preciso entregar o livro ao dono!) e recomendo a quem não leu ainda, seja ele junior ou sênior.

O livro traz uma série de dicas sobre como se tornar um bom programador. Segue um pequeno resumo.

1. Preocupe-se em fazer um código bom
2. Pense!! Critique o seu trabalho
3. Dê opções, não dê desculpas.
4. Conserte falhas ao encontrar a falha
5. Seja um catalizador de mudanças
6. Lembre-se o ‘porquê’ do projeto
7. Faça da qualidade um requerimento
8. Invista regularmente no seu portifólio de conhecimento
9. Analise e critique o que você ouve e vê
10. É o que você fala e COMO você fala
11. DRY – Don’t Repeat Yourself
12. Faça facil para ser reutilizavel
13. Elimine efeitos entre coisas não relacionadas
14. Não existem decisões finais
15. Use traçantes para achar o alvo
16. Prototipar para aprender
17. Programe para o problema do domínio usando a linguagem do domínio
18. Estime para evitar supresas
19. Itere o cronograma com o código
20. Deixe o conhecimento em arquivos textos
21. Use o poder das linhas de comando
22. Use BEM apenas um editor
23. Sempre use um controlador de versão
24. Resolva o problema, não a culpa
25. Não entre em pânico ao debugar
26. O problema normalmente não é no ’select’
27. Não assuma algo, prove!
28. Aprenda uma linguagem de manipulação de texto
29. Excreva código que escreva código
30. Não, você não pode escrever softwares perfeitos. Proteja o seu código.
31. Desenhe soluções baseadas em contratos
32. Pegue os problemas precocemente. Teste desde o inicio.
33. Use asserções para prevenir o impossivel
34. Use exceções apenas para o excepcional
35. Termine o que começou
36. Minimize acoplamentos entre módulos
37. Configure! Não integre!
38. Coloque abstração no código e detalhe no metadata
39. Analise o workflow para melhorar a concorrências
40. Desenhe usando serviços
41. Sempre desenhe pensando em concorrência
42. Separe a visão do modelo
43. Desenhe e conheça o fluxo da informação
44. Não programe por concidência
45. Estime a complexidade dos seus códigos
46. Teste as suas estimações em unidades reais
47. Refatore frequentemente, agora e sempre!
48. Desenvolva para os testes
49. Teste o seu software, ou os usuários testarão
50. Não use geradores de código que você não entenda o que foi gerado
51. Não apenas leia os requisitos. Mergulhe neles. Escave eles!
52. Trabalhe com um usuário para pensar como um usuário
53. Abstrações sobrevivem mais do que os detalhes
54. Crie um glossário de projeto
55. Ache, pense e pese as ‘necessidades’
56. Comece quando estiver pronto!
57. Algumas coisas são melhores prontas do que descritas
58. Não seja escravo da formalidade
59. Ferramentas caras não produzem as melhores arquiteturas
60. Organize o time por funcionalidades, e não por funções.
61. Automatize o que puder ser automatizado.
62. Teste frequentemente e automaticamente
63. Só está pronto quando o teste roda com sucesso
64. Use sabotadores para testar o seu teste
65. Não teste apenas o código. Teste as situações do domínio
66. Ache erros apenas uma vez
67. Escreva documentos com os mesmos princípios que vc escreve código
68. Não separe tanto a documentação do código
69. Exceda a espectativa do seu cliente
70. Assine o seu trabalho

PS: Qualquer duvida, só comentar que eu detalho os itens.

Comente e Recomende!!