OO, eu?

Mesmo uma linguagem orientada a objetos, como Java ou C#, pode ser utilizada, de forma consciente ou não, para criação de programas com base no paradigma estruturado. Nesse paradigma é grande a quantidade de estruturas de controle (como IF, IF-ELSE e SWITCH) e repetição (FOR, DO/WHILE). A pergunta que fica é: programas escritos utilizando orientação a objetos não precisam de tais estruturas? Como ficariam essas situações no código? Vejamos...

POO é sobre design. É o design da aplicação que determina se ela está aderente à metodologia estruturada ou à metodologia de objetos.

É claro que mesmo nas aplicações OO sempre haverá a necessidade de seleções e decisões. A diferença está na forma e na quantidade que tais elementos aparecem. Utilizando polimorfismo, um método que receba um parâmetro do super-tipo, por exemplo, não precisará de teste condicional, pois a implementação concreta será decidida somente no momento da passagem do objeto.

Observe (em C#):

    //uma Classe qualquer
    public void CalcularSalarioFuncionario(Funcionario funcionario)
    {
        //Gerente ou Vendedor? Só na hora será decidido.
        decimal valor = funcionario.CalcularSalario();

        //continuacao do método
    }

Um bom design OO diminui a necessidade de estruturas condicionais e de controle, porém não a elimina por completo. O fato é que isso (a eliminação) não é necessário para se obter um bom design, que seja robusto, de fácil manutenção e flexível.

Ex: Repositorio (em Java)

    //Classe RepositorioDePedidos
    public List buscarPedidosPorClienteID(int clienteID) {

     List pedidosDoCliente = new ArrayList();

     if (pedidos !=null) {

           for (Pedido pedido : pedidos) {   
                
                 Cliente cliente = pedido.getCliente();            
     
                 //aqui seria melhor usar o método equals() sobrescrito
                 if (cliente.getClienteID == clienteID) {
                      pedidosDoCliente.add(pedido);
                 }
           }
      }

      return pedidosDoCliente;
    }     


Repare que o método buscarPedidosPorClienteID tem elementos de decisão, seleção e controle. Tal situação ocorre a todo momento dentro dos repositórios.


E como poderia ser um cliente desse repositório?


    //uma Classe de controle qualquer
    public void gerarListaDePedidos(int clienteID)
    {
        RepositorioDePedidos repositorio = new RepositorioDePedidos();

        List pedidos = repositorio.buscarPedidosPorClienteID(clienteID);

        //renderizo uma tela, gero um relatorio, etc
    }  


O consumidor da classe RepositorioDePedidos  dispõe de uma API útil para buscar pedidos de um determinado cliente, dado o seu ID. Ele não sabe como o método funciona (encapsulamento), sabe apenas que funciona. A classe é reutilizável (várias instâncias podem ser criadas), fortemente tipada (somente o tipo Pedido) e tem detalhes de implementação desconhecidos (classe concreta ArrayList).

Com essas características não temos dúvida que o código de exemplo é OO, mesmo com a presença de elementos fundamentais de programação.

Um bom design OO diminui a necessidade de estruturas condicionais e de controle. Patterns, polimorfismo e outras técnicas podem ser utilizadas para tornar o código melhor escrito.

Mais informações sobre sobre estruturas de controle em programas aqui.

Arquitetura para o DDD

Continuando a série sobre o Domain Driven Design iniciada aqui, vamos agora comentar sobre como arquitetar as camadas da aplicação de modo a utilizar um Domain Model rico como a "base" do desenvolvimento.

Antes de mais nada, convém salientar que essa não deve ser vista como a única arquitetura que existe e que irá atender a todos os sistemas e situações do mercado. Trata-se apenas da arquitetura mais adequada a um projeto que trabalhe sob as premissas do DDD.

As camadas são representadas como abaixo:

Explicação sobre as camadas:

É importante dizer que não considero a camada Application como mandatória; ela é criada apenas se realmente adicionar valor à aplicação. Como a camada Domain é bastante rica em funcionalidades, muitas vezes não é necessário implementar mais essa divisão.

A criação de um Domain Model  traz uma série de vantagens para aplicações de larga escala e/ou complexas. Como bem disse Martin Fowler em PoEAA: "se você utilizar DDD para um projeto, você provavelmente irá cogitar utilizar a mesma técnica para outros (mesmo para os pequenos)."

Um design focado na criação de um Domain Model tem melhor manutenção no longo prazo devido à clareza da relação entre o negócio e a implementação. Além disso, é uma importante ferramenta para evitar a duplicação de código. Também aumenta a testabilidade do sistema.

Pesquisa Agile.

Laurie Williams, uma professora da North Carolina State University, vem conduzindo uma pesquisa para descobrir quais as práticas e os princípios que são mais utilizados pelas equipes ágeis.

A pesquisadora também convida os participantes a repensarem os princípios e práticas, propondo sugestões de melhoria (quando aplicável). 

Vejam os cinco princípios considerados mais importantes até o momento:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Working software is the primary measure of progress.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

E as cinco práticas mais importantes:

1. Short iterations (30 days or less)
2. Continuous integration
3. “Done” criteria
4. Automated tests are run with each build
5. Automated unit testing

Você pode conferir as atualizações da pesquisa aqui.

Caso queira participar da pesquisa é só vir aqui.

Toque do Gênio

Na última segunda-feira, estive no seminário da PUC - Design de Software para o século XXI. A palestra principal era de Martin Fowler, um nome que dispensa apresentações. Basta dizer que a maioria dos livros de desenvolvimento de software dos últimos dez anos cita, em alguma medida, seu nome e referencia seu vasto trabalho em áreas como enterprise patterns, agile, TDD, Refactoring, UML e, mais recentemente, Domain Specific Languages (DSLs).

A primeira parte da palestra foi focada em discutir as DSLs, que é o tema de seu último livro (provavelmente sairá em outubro, segundo ele mesmo). Ele mostrou com podemos criar linguagens específicas a um determinado domínio, desmistificando o tema ao provar que estamos diariamente expostos a coisas semelhantes, tais como SQL, Linq, Struts e Hibernate. Esses são alguns exemplos, não de DSLs, mas de algumas ferramentas e linguagens dedicadas a resolver um único propósito. Por outro lado, Java e C# são o que ele chama de general programming languages, usadas para resolver qualquer tipo de problema e em qualquer domínio. O assunto foi quente e deixou a platéia com gostinho de "quero mais". É claro que irei encomendar o livro. -:)

A segunda parte foi mais árida e dedicada a falar sobre REST. Foi uma palestra MUITO técnica (algumas pessoas não faziam a menor ideia do que se tratava) e um pouco cansativa. Ele explicou os quatro níveis de arquitetura REST (0, 1, 2 e 3) e comentou os fundamentos de cada parte. Confesso que pelo que foi explicado, o que implementei até hoje pode ser classificado no máximo como nível 1. Estou precisando "comer um pouco mais de feijão" nesse assunto hehe.

A terceira parte da apresentação foi bem interessante e divertida. Martin mostrou os benefícios da integração contínua e da automação de builds e testes. Nessa parte ele já estava bem à vontade com a platéia e presenteou a todos com seu humor fino e colocações pertinentes. É muito inspirador vermos que podemos chegar a um nível tal de automação que nos permita entregar software para produção em intervalos cada vez mais curtos, podendo até ser diários. Ele comentou brevemente sobre o Cruise, que é uma ferramenta de CI da ThoughtWorks (com versão free, vale à pena verificar).

Por último, Martin abriu para perguntas e respondeu prontamente a todos que tinham questões.

E então, como última pergunta, um iluminado da platéia perguntou ao Martin se ele voaria em um avião que tivesse sido construído utilizando métodos ágeis. Ele calmamente respondeu que temos que, gradativamente, encontrar quais são as fronteiras do desenvolvimento ágil, simplesmente testando os seus limites (obviamente sem colocar a vida de ninguém em risco). Métodos ágeis ganham mais espaço em todo o tipo de projeto e assim tem sido diariamente ao redor do globo. Completou dizendo que não sabia o suficiente sobre aviação para uma resposta mais acurada e terminou contando a seguinte piada:

"Um grupo de alunos havia construído um sistema para determinado avião. 

Perguntaram ao professor desses alunos: - mestre, o senhor viajaria nesse avião?

O professor disse: - viajaria com toda certeza e estaria 100% seguro.

- Mas como o senhor pode ter tanta certeza que o avião não iria cair?

O professor então respondeu: - ora meu caro, se meus alunos fizeram esse sistema, é óbvio que o avião nem irá sair do chão!"

hahahaha

Ele terminou com essa piada e o pessoal foi ao delírio.

Toque do gênio!

Alguns livros que considero importantes...

link para o livro

link para o livro

link para o livro

link para o livro

link para o livro

Ubiquitous Language

Sempre que encontro com meus amigos guitarristas é uma festa... O assunto principal, como não poderia deixar de ser, é sempre sobre guitarras e tudo que essas preciosidades podem fazer. Falamos sobre as pickups que nossos ídolos utilizam, se vamos colocar jumbo frets em nossos necks para obter maior sustain, comentamos sobre os tipos de bridge que mais gostamos, entre outros assuntos.

Não está entendendo nada desse assunto? Não esquenta, somente nós guitarristas (malucos) entendemos. Essa é a nossa linguagem, a que usamos normalmente para comunicar nossas ideias e nossa paixão pela música.

Imagine uma situação hipotética, na qual esse grupo de amigos tivesse encomendado a uma equipe de programadores um sistema de controle de guitarras, um software no qual pudéssemos encontrar e colocar todo o tipo de informação pertinente da nossa área de atuação. De que modo você pensaria em modelar esse sistema? Qual seria um design apropriado para esse problema?

Um programador com linguagem puramente técnica tentaria explicar como desenvolveria o sistema usando DAOs, controladores, queries, Design Patterns e outras coisas que nada tem a ver com a área (apenas me deixando preocupado se ele realmente teria entendido) o negócio que gostaríamos de ver solucionado.

De outra forma, um programador poderia aproveitar o nosso vocabulário para modelar uma solução que usasse a nossa linguagem como apoio para o design. Nesse modelo, ele me mostraria como criaria guitarras, pickups, tremolos e repositórios diretamente na solução. Deixaria bem claro como esses elementos estão associados usando a mesma linguagem que nós utilizamos normalmente. A essa linguagem damos o nome de ubiquitous language.


Repare onde a ubiquitous language naturalmente se encontra, um meio-termo que une especialistas em domínio com especialistas em tecnologia:

A ubiquitous language é fundamental para o Domain Driven Design, metodologia que foca na construção de sistemas a partir do desenvolvimento (e isolamento) de um rico domain model, capaz de resolver problemas com eficiência e apoiado na linguagem que os usuários utilizam no dia a dia.

Eric Evans nos dá a direção:

"Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communications within the team and in the code. Use the same language in diagrams, writing, and especially speech. Recognize that a change in the ubiquitous language is a change to the model."

Nós devemos ser capazes de desenvolver sistemas que comuniquem bem seu design para os usuários que realmente o utilizarão. Mantenha apenas o modelo, código e testes como artefatos permanentes do desenvolvimento. Use a linguagem no dia a dia e a incorpore em todo o lugar, dos diagramas de classe aos códigos Java e C#. Isole o domain model e deixe o aparato técnico para ser discutido apenas por especialistas em tecnologia.

Próximos posts veremos como a arquitetura DDD é feita de forma a permitir o isolamento desse domain model.

Curso agile pronto

Fala pessoal!
Tudo bem?

O curso agile ficou pronto e já saiu do forno... Montei um compacto das melhores práticas de engenharia do XP com as práticas de gestão de projetos do Scrum.

Modéstia à parte, ficou bem bacana. hehehe

Quem quiser conferir clique aqui.

Abração e qualquer dúvida é só postar que eu respondo. :)