Continuando na “luta” para criar sistemas mais fáceis de se entender, me lembrei de dar uma olhada nos Tiny Types apresentados pelo Darren Hobbs.
O CV tinha passado esse link há algum tempo e eu havia olhado superficialmente. Até que nessa história de fazer Fluent Interfaces e Domain-Driven Design acabei me lembrando que isso poderia ser útil.
Os Tiny Types enriquecem o domain model e trazem alguns outros benefícios legais citados pelo Darren em seu texto. Para as próximas features vou experimentar essa estratégia para ver no que vai dar…
0 replies on “Tiny Types”
Interessante. Em Scala é razoávelmente comum usar case classes para implementar estes “Tiny Types”.
Guilherme, isso me lembrou esse texto do Fowler:
http://martinfowler.com/ieeeSoftware/whenType.pdf
O problema de tiny types é que eles não se dão bem com um monte de gente por aí (Hibernate + JPA, toneladas de frameworks mvc, etc). Mas somando isso e interfaces fluentes, dá para fazer algumas construções bem interessantes. Curioso para ver o resultado do seu trabalho.
valeuz…
Esqueci de dizer, alias, pensei nisso agora: esse pode ser um bom caso para aplicar “null objects” (http://thiagoarrais.wordpress.com/2006/09/27/uma-pequena-grande-ideia-2/) para emular os tiny types.
valeuz…
Tiny Types não seria uma forma “extrema” de aplicar o padrão Value Object[1]?
[1]: http://martinfowler.com/bliki/ValueObject.html
[],
AC
A idéia parece legal, mas adiciona uma complexidade que acho desnecessária.
Como nosso colega disse, fazer o mapeamento para um ORM não ficará tão simples – talvez como component ou criar um userType(hibernate).
As maiores vantagens sem dúvida é na hora do desenvolvimento.
Sim, acho que dá pra considerar os Tiny Types como Value Objects, mas o conceito não é exatamente o mesmo.
Sobre ORM e complexidade, é o tipo de coisa que só vai dar pra descobrir depois que fizer uma implementação pela primeira vez 🙂 Talvez exista alguma solução ridiculamente simples no Hibernate que resolva o problema, por exemplo.
Mesmo com isso o conceito é interessante e está na minha lista de “POCs TO DO” 🙂
[ ]s, Guilherme
Putz, isso é levar tipagem estática ao extremo. Criar tipos só para deixxar a intenção do método mais claro me parece um overkill tão grande quanto criar interfaces para toda e qualquer coisa porque talvez, quem sabe, mudem um dia.
Você acaba criando classes que não são classes, são apenas instâncias de uma classe com um nome mais fancy. Uma IDE decente vai te dar os nomes dos parâmetros sem gambiarras e assinatos de OO 😛
Ah, ou use Ruby, javaScript ou Common Lisp e acabe com o problema pela raiz 😛
Talvez para um domain model fique realmente muito saturado mas para uma fluent interface da vida continua me parecendo uma idéia interessante…
Shoes: “Putz, isso é levar tipagem estática ao extremo. ”
You say that like it’s a bad thing 😛
@gc
Uma FluentInterface, por definição, estupra a sintaxe e estilo da linguagem em favor de legibilidade, então achp que não se aplica o padrão apesard e termos a,ggo no estilo por questões técnicas.
@Rafael
Nem vem, não vou discutir isso novamente 😛 Além do que, todo extremo tem grande chance de ser ruim, seja do que for 😉