(blog.caelum.com.br) Tiny Types minimizar erros ou é uma forma de Refatoração?

Olá

Eu acabei visitando o blog deles e achei interessante essa abordagem

Pra quem leu o livro “thoughtworks antology”, tem uma parte que é falado de algo parecido sobre a criação de classes, o que dava a entender a respeito de um sistema “full tyne typed” (nossa que termo é esse? rs)

Não cheguei a parar pra pensar muito nisso, mas de fato o sistema fica muito elegante dessa maneira IMHO. O que talvez dificulte um pouco é quando você quiser persistir isso em uma classe que tenha muitos atributos, o que você terá que usar muitos “Embedded” (JPA/Hibernate Annotations).

Interessante, nunca tinha pensado dessa forma.
Mas digam-me uma coisa, seriam criadas várias minúsculas classes pra essas validações?
Quais critérios seria sensato seguir para determinar quando é bom e quando não é bom criar tyne types?

Abraços!

Eu reconheço que isso é útil para classes como CPF, CNPJ, coisas que tem um pouco mais de comportamento.

Agora, para Nome, Descrição, para mim isso é para contornar uma deficiência de linguagens que não tem parâmetros/argumentos nomeados.

Digamos que esse seja um factory method para criação de Projeto ? Digamos que não seja um factory method, ou digamos que seja um Iterator, como ficaria ?

:arrow: Iteratorb[/b] é um padrão de projeto que visa simplificar a iteração sobre um conjunto de objetos.

Seria muito útil naquelas horas que estamos usando o auto-complete da IDE com um método desconhecido, e tudo o que ele mostra são aquelas assinaturas malucas

metodo(String arg0, int arg1, String arg2, int arg3, int arg4, boolean arg5)

Não vejo utilidade nisso, javadoc é suficiente.

[quote=gomesrod]Seria muito útil naquelas horas que estamos usando o auto-complete da IDE com um método desconhecido, e tudo o que ele mostra são aquelas assinaturas malucas

metodo(String arg0, int arg1, String arg2, int arg3, int arg4, boolean arg5)

Poucas coisas me dão tanto ódio quanto isso.
Ai você consulta o javaDocs e… “JavaDocs not available” arrrrrrrrrghh!
Daí só resta consultar o oráculo.

Bruno Laturner:

Eu reconheço que isso é útil para classes como CPF, CNPJ, coisas que tem um pouco mais de comportamento.

Agora, para Nome, Descrição, para mim isso é para contornar uma deficiência de linguagens que não tem parâmetros/argumentos nomeados.

Concordo.
E fora que polui ainda mais o já poluido código Java.

Achei horrível. Muito verboso e parte do princípio que o desenvolvedor é uma porta que não consegue ler.

Mas temos que concordar que alguns não sabem escrever. hehehehe
Independente disso, entramos naquele paradigma de “orientação a strings”, pelo menos pra mim fez sentido a princípio.
JavaDocs é lindo, adoro quando tem a descrição toda do método chamado com explicação dos argumentos, exceptions, etc.

Abraços.

Digamos que esse seja um factory method para criação de Projeto. Ele seria usado da seguinte forma:

new FabricaDeProjeto().criaProjeto("nome", "descrição");

Não seria melhor aproveitarmos a tipagem explícita do Java para pegarmos esse problema em tempo de compilação? Ganhamos checagem em tempo de compilação. Mas apenas isso? Vamos olhar como esse método seria usado:

new FabricaDeProjeto()
     .criaProjeto(new Nome("nome"), new Descricao("descrição"));

O código ficou mais expressivo.

Wow. Serio? Eu discordo quanto ao ganho de expressividade.

Sem falar que definir novas classes é algo básico do paradigma OO, não estou certo se preciso de um novo nome pra isso. Qual será o próximo passo, um framework para criar objetos em Java?

Bem, dando minha simples opinião, acredito que o JavaDoc resolve o problema.
Mas se quizer algo mais representativo de nome e descrição, o mais correto seria:

new FabricaDeProjeto().setNome("nome").setDescricao("descricao").criaProjeto();

Uma classe para nome e uma para descrição não me parece certo.
P.S.: Ess new seguido de Fabrica também não me parece certo.

Em todo caso, é apenas uma abordagem.

[]'s
JL

É. Realmente ess eexemplo não é muito feliz porque ainda posso escrever assim :

new FabricaDeProjeto()
     .criaProjeto(new Nome("descrição"), new Descricao("nome"));

Isto é um problema conhecido porque não ha inteligencia sobre o conteudo de strings. Isso é responsabilidade do programador. Mas sendo assim, tb era no exemplo sem tiny type.

Para objetos como CEP , Telefone e Periodo faz sentido tiny type, mas para String é meio estranho

public void callHome(long phoneNumber)

// chamada 

et.callHome(-1); // hummm... telefones negativos .. só para o ET

Tiny Types costumam ser acompanhados de métodos de fábrica que validam os dados primitivos. Por exemplo

public void callHome(PhoneNumber phoneNumber)

// chamada 

et.callHome(PhoneNumber.valueOf(-1); // IllegalArgumentException vindo de valueOf

Tiny Types são Value Objects mais fortemente tipados e como tal seguem as mesmas regras. Lembrar que todos os wrappers de pimitivos, BigDecimal e BigInteger são Value Objects e dai o idioma comum valueOf usado nesses tipos.
Value Object.

sergiotaborda:

Tiny Types são Value Objects mais fortemente tipados e como tal seguem as mesmas regras. Lembrar que todos os wrappers de pimitivos, BigDecimal e BigInteger são Value Objects e dai o idioma comum valueOf usado nesses tipos.
Value Object.

Infelizmente Value Object já é um termo utilizado pelo povo do DDD. Tiny Types até poderia ser este Value Object que não é aplicado ao domínio mas o nome da impressão de um tipo especial de objeto, que é pequeno e limitado. Ou seja, péssimo pra passar a idéia.

mochuara:

Infelizmente Value Object já é um termo utilizado pelo povo do DDD. Tiny Types até poderia ser este Value Object que[color=red] não é aplicado ao domínio [/color]mas o nome da impressão de um tipo especial de objeto, que é pequeno e limitado. Ou seja, péssimo pra passar a idéia.

:arrow: “Em diferentes dominios existem diferentes objetos de valor”. Em geral, um objeto de valor pode ter um numero ilimitado de atributos. O que interessa é dois objetos da mesma classe são iguais se os estados deles são iguais.

:idea: fonte Sérgio Taborda

Não sei se eu criaria um Tiny Type para Nome e para Descricao… se fosse fazer isso com todos os atributos eu ficaria louco, imagina o trabalho criar um “converter” para cada tiny type?

faca eles implementarem SingleStringTinyType e ai voce cria um unico conversor generico, que fica atento para isso (ou para uma anotacao neles).

é, da muito trabalho ter tiny types para uma unica String, mas as vezes compensa dependendo da importancia desse valor. (e alguns deles costumam crescer)

:!: “Esses pequenos objetos imutáveis podem facilitar muito o desenvolvimento, prevenindo problemas e evitando que por preguiça separemos de forma errada as responsabilidades dos objetos”

:arrow: http://blog.caelum.com.br/

Acho que isso que significa tornar o código mais expressivo! Acredito que ninguem faria um new Descricao(“nome”);

Tá, TinyTypes deixam o código com uma leitura mais simples, mas qual outro motivo de precisar criar eles? Evitar erros bobos de programação? Tentar ser precavido à programadores sem-vergonhas?

Eu não vejo grande utilidade neles… Só aumentam a quantidade de código JAVA necessário
Talvez em linguagens em que eles façam parte da linguagem, até tenha algum valor, mas em Java eu acho o valor deles pequeno se comparado ao trabalhar de criar e manter…

Ola,
acho que sempre que alguem escrever um artigo ou coisa parecida sobre algum padrão deveria colocar em letras garrafais:

O Ministerio da Saude adverte, usar padrões onde não existe necessidade é prejudicial a saude!!!

ou:

Aprecie com moderação!!!

Como tudo, Tiny Types tem seu uso, mas quando fizer sentido. O problema que as pessoas leem o artigo, não entendem direito o proposito e saem usando em tudo que é lugar, como ja vimos com diversos padrões por ae.

[]´s

desde do java 1.5 que venho pensando em tiny types, pela seguinte motivação: enums. Desde o começo um dos objetivos do enums era evitar o incauto de usar constantes, pois permitiam qualquer valor como parametro, justamente por causa do tipo generico demais. como segue:

imagine que o desenvolvedor poderia por um valor que não era esperado:

carro.setCor(13); //estava declarado um tipo integer

justamente onde era esperado algo do tipo:

carro.setCor(Carro.COR_BRANCO); //constante

através do enum isso não seria um problema, pois me obriga a especificar um tipo especializado:

carro.setCor(Cores.BRANCO); //aqui o tipo evita os problemas com entradas invalidas e fica mais expresso o que se expera nesse parametro.

acredito que os tiny types seguem a mesma filosofia: protegem e deixam mais claro o que deve “entrar” no objeto.

Usar objetos para inferir valores dava para ser usado bem antes do Java 5. Também acho pavoroso usar constantes int no lugar de objetos sem ter um ótimo motivo.

Uma coisa que o Paulo disse e é pura verdade, é que os objetos crescem.

Consigo prever isso no próprio Nome. Daqui a pouco vão querer código para extrair o nome e o sobrenome da pessoa, e isso seria muito mais fácil com um objeto Nome que com uma String. Aqui Nome ganhou uma responsabilidade, um motivo para viver.

Bruno Laturner:

Usar objetos para inferir valores dava para ser usado bem antes do Java 5. Também acho pavoroso usar constantes int no lugar de objetos sem ter um ótimo motivo.

Uma coisa que o Paulo disse e é pura verdade, é que os objetos crescem.

Consigo prever isso no próprio Nome. Daqui a pouco vão querer código para extrair o nome e o sobrenome da pessoa, e isso seria muito mais fácil com um objeto Nome que com uma String. Aqui Nome ganhou uma responsabilidade, um motivo para viver.

O problema é o que se considera responsabilidade e o que isso reflete para o proposito de usar Tiny Types, como aqui já se provou que o parametro pode ocasionar equivos , acho que existe o que é o objeto e o requisito referente ao uso para o objeto especifico.

Bruno Laturner:

Usar objetos para inferir valores dava para ser usado bem antes do Java 5. Também acho pavoroso usar constantes int no lugar de objetos sem ter um ótimo motivo.

Uma coisa que o Paulo disse e é pura verdade, é que os objetos crescem.

Consigo prever isso no próprio Nome. Daqui a pouco vão querer código para extrair o nome e o sobrenome da pessoa, e isso seria muito mais fácil com um objeto Nome que com uma String. Aqui Nome ganhou uma responsabilidade, um motivo para viver.

Juk:

A flexibilidade deve ser adicionada ao código quando for necessário, e isso não deve ser antecipado. Ou seja, o nome poderia ser uma String e caso fizesse sentido no futuro extraído para uma classe por meio de refactoring e testes unitários.

Concordo também.

Concordo também.

Concordo também. Verbosidade desnecessária não agrega muito.

Mero_Aprendiz:

Bem, dando minha simples opinião, acredito que o JavaDoc resolve o problema.
Mas se quizer algo mais representativo de nome e descrição, o mais correto seria:

new FabricaDeProjeto().setNome("nome").setDescricao("descricao").criaProjeto();

Uma classe para nome e uma para descrição não me parece certo.
P.S.: Ess new seguido de Fabrica também não me parece certo.

Em todo caso, é apenas uma abordagem.

Projeto p = FabricaDeProjeto.criarNovoProjeto() .comNome("nome") .comDescricao("descrição");
Lembrando que, como o sergiotaborda falou, nada me impediria de executar o código de outra forma:

Projeto p = FabricaDeProjeto.criarNovoProjeto() .comNome("descrição") .comDescricao("nome");

Ouvi falar disso faz uns dois anos num blog, eu acho que em alguns casos é viável e em outros casos acharia melhor passar um objeto só como parâmetro.

Primeiro que tudo seguir o principio de separação de responsabilidade e encapsulamento não faz mal à saude. Digam o que disserem um sistema que utiliza padrões corretamente é um sistema mais simples de manter e expandir. Dizer o contrário é má fé ou desconhecimento.

A vantagem dos tiny types, para quem ainda não entendeu, é a tipagem forte. Um tipo Date é mais forte que long ou String quando trabalhamos com datas. Um tipo CEP ou PhoneNumber é mais forte quando trabalhamos com esses objetos em um dominio. Um método que recebe CEP não pode receber String ou qq outra coisa. Um método que retorna CEP deixa claro o que será o retorno.

Depois, outra vantagem é não haver preocupação com a formatação. É um problema comum ficar preocupado com a formatação do CEP ou do CNPJ. Isso é simplesmente má programação. Usando um tiny type destes a formatação é relegada para objetos de formatação (Format). O mesmo para a validação que é delegada para objetos Validator. Excatamente como se faz com Date. O objeto em si mantém um estado. A real implementação desse estado é encapsulada. Pode ser um string, mas pode ser um array de char ou de int. não ha como saber. O objeto implementa equals, hashcode e to String corretamente e disponibiliza métodos de consulta do estado. Por exemplo o CNPJ pode ter um método getDigitoValidação() e o CEP poder ter método mais complexos como getCodigoDeArea, getCódigoDeEstado conforme a especificação CEP.

Finalmente, Tiny Types são sim Value Objects, no sentido atual que este nome tem ( ha mais de 5 anos). O mesmo usado em DDD.
A única diferença é que os Tiny Types tendem a ser fortemente tipados para um dominio. Por exemplo, Money é um VO comum e genérico. CEP é mais restrito pois só faz sentido no dominio que trabalhe com endereços.

sergiotaborda:

A vantagem dos tiny types, para quem ainda não entendeu, é a tipagem forte.

A desvantagem pra quem quer entender é o nome, que não deixa isso claro. (tiny = pequeno)

O que eu ainda não entendi é de que forma o tiny type oferece essa tipagem mais forte do que se fosse outro objeto qualquer definido pela aplicacao (e não estou falando de DDD, que nada tem a ver com este tópico). Me parece que quem sofre de tipagem fraca em Java precisa aprender OO e não usar YAD (yet another DTO).

Sua visão de que todo o sistema é formado por diferentes domínios eu concordo. Mas vc parece estar confuso em relação a DDD. Tiny Types não tem nada a ver com DDD. Assim como Value Objects que vc descreve como sendo a mesma coisa que Tiny Types também não tem nada a ver com DDD.

Value Objects em DDD não são genéricos, pelo contrário, assim como outros objetos de domínio eles são definidos para fazerem sentido apenas num contexto específico.

mochuara:

sergiotaborda:

A vantagem dos tiny types, para quem ainda não entendeu, é a tipagem forte.

A desvantagem pra quem quer entender é o nome, que não deixa isso claro. (tiny = pequeno)

O que eu ainda não entendi é de que forma o tiny type oferece essa tipagem mais forte do que se fosse outro objeto qualquer definido pela aplicacao (e não estou falando de DDD, que nada tem a ver com este tópico). Me parece que quem sofre de tipagem fraca em Java precisa aprender OO e não usar YAD (yet another DTO).

Quando você cria a classe X para representar o conceito X mas X é na realidade um valor ( um texto, um numero, um codigo. algo mono-campo) então a classe X que vc criou é - por definição - um Tiny Type.

Tiny Type é o nome dessa prática.
O ponto é que o mortal comum não segue essa prática OO e prefere gambiarrar usando um wraper primitivo ou string.
Se vc segue, já está usando Tiny Type sem saber

Agora, o Padrão de Projeto que vc está usando aqui é o Value Object (Objecto de Valor). Que é o padrão do BigDecimal, Integer, Date, e afins.

Value Object - o design pattern - não tem nada a haver com DDD. É definido à parte (o Fowler foi o primeiro a nomear esse padrão, mas infelizmente ele usou um nome utilizado na época para outro padrão. por isso eu falei no significado atual. Que é o que o Fowler deu).

Nem todos os tiny type são VO, mas a grande maioria é.

Sua visão de que todo o sistema é formado por diferentes domínios eu concordo. Mas vc parece estar confuso em relação a DDD. Tiny Types não tem nada a ver com DDD. Assim como Value Objects que vc descreve como sendo a mesma coisa que Tiny Types também não tem nada a ver com DDD.

Value Objects em DDD não são genéricos, pelo contrário, assim como outros objetos de domínio eles são definidos para fazerem sentido apenas num contexto específico.

na realidade importa-me um pepino o que o DDD tem a dizer … mas, VO é um padrão OO independente de DDD. Várias classes do java padrão o seguem ( BigDecimal, BigInteger, Date e os wrapper de primitivos , pelo menos). Tiny Type é um prática de OO tb independente do DDD que ganhou um nome especial. Na realidade o nome é irrelevante se vc já segue a prática - é uma questão de chamar nomes aos bois.

Eu sempre me referi a VO e TT no ambiente OO e não no DDD, mas , em DDD VO continua sendo o mesmo padrão.
Se vc modela o VO por dominio , por negocio ou por aplicação é escolha sua e não tem nada a haver com o padrão em si.

Por exemplo Money vc pode implementar genérico , mas pode implementar particular para a sua aplicação tb.
O ponto aqui é mais de manutenabilidade. Quando mais genérico for o VO menos vezes vc terá que o implementat do zero e ele será tão natural no seu codigo como Integer ou Date.

Paulo Silveira:

faca eles implementarem SingleStringTinyType e ai voce cria um unico conversor generico, que fica atento para isso (ou para uma anotacao neles).

é, da muito trabalho ter tiny types para uma unica String, mas as vezes compensa dependendo da importancia desse valor. (e alguns deles costumam crescer)

Aaaaah… legal, legal, da uma boa diminuida do trabalho

Agora entendi. Eu acho que não uso essa prática pelo motivo que quando estou modelando meus objetos minha tendência é acreditar que o melhor é programar para interfaces. E nessa perspectiva saber se o objeto possui internamente tiny, ou mono ou meio campo não ajuda em nada. Neste momento tudo que deveria interessar são papéis a serem exercidos e responsabilidades a serem atribuidas entre os mensageiros.

Ou seja, se Tiny Type é realmente uma prática OO ha controvérsias.

mochuara:

Ou seja, se Tiny Type é realmente uma prática OO ha controvérsias.

Segundo a Orientação Objetos “Tudo é Objeto”, na concepção sobre Responsabilidade e papeis "O Design esta Morto", por Martin Folwer.

mochuara:

sergiotaborda:

Quando você cria a classe X para representar o conceito X mas X é na realidade um valor ( um texto, um numero, um codigo. algo mono-campo) então a classe X que vc criou é - por definição - um Tiny Type.

Tiny Type é o nome dessa prática.
O ponto é que o mortal comum não segue essa prática OO e prefere gambiarrar usando um wraper primitivo ou string.
Se vc segue, já está usando Tiny Type sem saber

Agora entendi. Eu acho que não uso essa prática pelo motivo que quando estou modelando meus objetos minha tendência é acreditar que o melhor é programar para interfaces.

Isso não tem sentido nenhum. Desde quando entidades são modeladas com interfaces ? E mesmo que sejam, that’s the point!
O que estamos falando aqui nada mais é do que simplesmente seguir uma boa prática : Use o tipo certo para o trabalho .
O ponto é: mas o que fazer quando esse tipo não existe ? Crie-o.
Mas e se ele for demasiado pequeno (tiny) ? Crie-o mesmo assim.

A prática de tiny type nada mais é que seguir OO até ao nivel mais baixo do modelo que são os dados em si. Não as entidades. Os dados.
É claro que em algum software Money ou CEP ou CNJP podem ser entidades , mas o ponto aqui é : use um tipo especifico para os representar, independentemente do resto.

Se vc modela para interfaces vc sabe que nem sempre isso é possivel/desejável. O caso comum é quando vc está realmente modelando um VO.

Mas é exactamente isso que está em causa. A responsabilidade.
String não tem responsabiliade de Date. Nem long tem a responsabilidade de Periodo.
O ponto é que muita gente , chegado neste ponto, adota usar primitivos ou tipos préxistentes.

Por exemplo, medir o tempo que demora um método. Normalmente faz-se assim:

long mark = System.currentMilis();

//executa método

long demora = System.currentMilis() - mark;

Sytem.out.println("Método demorou " + demora + " ms");

em OO seria assim :

StopWatch mark = StopWatch .start();

//executa método

Period demora = mark.stop();

Sytem.out.println("Método demorou " + demora.miliseconds() + " ms");

Ou seja, se Tiny Type é realmente uma prática OO ha controvérsias.

Por favor ilustre-as, porque não estou vendo onde Tine Type não seja OO.

Você deve estar brincando, programar para interface é A maneira de se programar OO em Java. Desculpe, mas não entendi o que significa “modelar um VO” neste caso.

Se o espaço que Periodo ocupa no seu modelo cabe dentro de um long não vejo porque criar um Tiny Type pra aparecer no javadoc que o argumento é tipado.

Não tenho porque acreditar que a segunda seja “mais OO” que a primeira. Na veradde, eu prefiro a primeira porque esta mais simples. A segunda exige que eu conheca duas outras classes, Period e StopWatch. Esse tipo de design OO baseado em criar classes pra todo dado é pura perda de tempo IMO.

Olá!

O que o Sérgio falou pra mim faz sentido. Em Java não existe CPF. No caso utilizamos o tipo String para representá-la, mas concordamos que String é String e CPF é CPF. Se pensarmos em responsabilidades, uma String não tem a responsabilidade de representar um CPF. O CPF sabe se manter em consistência, até porque essa é sua responsabilidade, já a String não sabe manter a consistência de um CPF, portanto em algum outro lugar deverá ter código pra isso. Não que na classe CPF não tenha, mas pelo menos ele fica onde deveria estar, encapsulado no objeto que tem realmente essa responsabilidade. No final das contas Orientação a Objetos é sobre objetos e suas responsabilidades, certo? String é um objeto cuja responsabilidade não é de ser um CPF.

Lógico que eu sou um graaaaaaaaande adepto do padrão KISS (Keep It Simple, Stupid), portanto nem sempre uso esse tipo de coisa apenas pra falar “olha, eu uso OO! \o/”, sendo que da pra fazer mais simples sem grandes impactos.

Edit:

Aqui você se contradisse (ta certo isso?) um pouco. Você diz que não tem porque acreditar que a segunda seja mais OO porque na verdade a primeira está mais simples. Mas não tem nada a ver nível de complexidade com OO. A segunda sim, está mais OO e a primeira sim, está mais simples. Mas claro, como eu disse anteriormente, não é porque está mais OO que eu vou usar, mas vou usar a que me agrada mais por outros N fatores: legibilidade, manutenabilidade* (ta certo, denovo?), simplicidade, menos esforço, etc.

• sei la, não acredito que só por ser OO que em todos os casos seja mais fácil de dar manutenção

Abraços

O problema com o KISS é que nem todos têm a mesma definição de “simples” e “estupido”.
O que significa “simples” ? ter menos classes no seu workspace ? tem mais funcionalidade encapsulada ? usar tipos primitivos ? nunca usar reflection ?
Só usa API de terceiros ?

O problema não é vc dizer “fiz isto porque é mais OO” e sim justificar porquê diz “não fiz OO para isto”.
Se vc faz OO algumas vezes e outras não, isso tem que ter uma razão. E essa razão tem que ser suportda por fatos.

O Tiny Type é exactamente o conceito de : “Não se engana achando que usar primitivas é simples” , sendo que simples significa :

• melhor expressividade (qq um entende o codigo, mesmo quem não participa do projeto) que resulta em
• melhor manutenção , que resulta em :
• menor custo

Isso para mim é simples e manter o custo elevado é que é realmente estupido.

Link_pg:

Aqui você se contradisse (ta certo isso?) um pouco. Você diz que não tem porque acreditar que a segunda seja mais OO porque na verdade a primeira está mais simples. Mas não tem nada a ver nível de complexidade com OO. A segunda sim, está mais OO e a primeira sim, está mais simples. Mas claro, como eu disse anteriormente, não é porque está mais OO que eu vou usar, mas vou usar a que me agrada mais por outros N fatores: legibilidade, manutenabilidade* (ta certo, denovo?), simplicidade, menos esforço, etc.

• sei la, não acredito que só por ser OO que em todos os casos seja mais fácil de dar manutenção

Abraços

Por favor, nao venha desvirtuar o topico que é sobre tiny types. Repare que coloquei “mais OO”, assim entre aspas. Tiny Types não deixa o seu código mais OO. Leia de novo o segundo código e me diga qual a responsabilidade do objeto Period. A questao aqui não é a necessidade ou não do objeto StopWatch.

A minha definição de KISS é essa:

StopWatch w = StopWatch .start();

//executa método

Sytem.out.println("Método demorou " + w.mark() + " ms");

Ou seja, parece melhor sem tiny types.

A responsabilidade Period é ser um perido de tempo.
Depois daqueles codigo ter sido escrito houve um requisito assim:

“A precisão precisa ser em nanosegundos”

Como primeiro codigo vc muda de System.currentMilis para System.currentNano (estou citando de cabeça os nomes dos métodos)
E isto em todas as classes que utilizam este mecanismo de contagem de tempo ( que podem ser muitas)

No segundo nada muda nas classes. Apenas em StopWatch vc muda para usar System.currentNano.
De quem é a responsabilidade de contar o tempo ? do cronometro. então é lá que muda o codigo. Só lá.
E Periodo não muda nada. em vez de 23 milisegundos vai aparecer 23,789092 ms
Se Periodo já tinha um método nano() nada muda tb. Se não tem, sempre pode adicionar e ganhar essa funcionalidade extra.

Não acho que um código que substitui “long demora” por “Period demora” fica mais expressivo ou mais fácil de dar manutenção. Nem menos custoso.
De qualquer jeito essa demora vai ser um número. Se ocorrer algum erro, terei de ir à classe Period para verificar o que ocorre lá (sendo que o erro pode nem estar nessa classe, me fazendo perder tempo), fora que escrever “long” é bem mais rápido que clicar com o botão direito -> new -> Class.

Substituir long por uma classe Period vai te trazer o que de benefício? Por favor esclareça, porque até agora não consigo entender.

Ainda bem que o processo é iterativo. Aproveite a oportunidade pra acabar com Tiny Types.

<blockquote><div class="quote-author">sergiotaborda:</div>

Como primeiro codigo vc muda de System.currentMilis para System.currentNano (estou citando de cabeça os nomes dos métodos)

E isto em todas as classes que utilizam este mecanismo de contagem de tempo ( que podem ser muitas)

No segundo nada muda nas classes. Apenas em StopWatch vc muda para usar System.currentNano.

De quem é a responsabilidade de contar o tempo ? do cronometro. então é lá que muda o codigo. Só lá.

E Periodo não muda nada. em vez de 23 milisegundos vai aparecer 23,789092 ms

Se Periodo já tinha um método nano() nada muda tb. Se não tem, sempre pode adicionar e ganhar essa funcionalidade extra.</blockquote>

Ou seja, vc acha melhor adicionar um metodo no Period e alterar o StopWatch, do que apenas adicionar um novo metodo ao StopWatch?

Esse é o erro. Periodo não é um numero. É uma quantidade (tem unidades!)
Por isso que na Date and Time API do Java 7 vc vai ter uma classe Period e uma classe Duration ( sim, periodo e duração são coisas diferentes tb).

Tudo isto porque vc está exercendo uma das mecanicas de OO : abstração. Abstraçã osingifica : ter um objeto/classe que representa um conceito no mundo real.

Se vc mantem o long vc não tem abstração

Essa é uma visão muito limitada do que é Programação Orientada a Objectos.
Uma desição de modelagem não se toma baseado no que a ferramenta pode fazer por si.

Quem pensa como você nunca vai tenter a vantagem de Period sobre long , e portanto nunca vai entender tiny type.
Primeiro vc aprender OO. Depois vc discute as vantagens de OO vs não-OO.
Discutir tiny type sem entender OO não é apenas complicado. É inutil.

Desculpe-me pelo desvirtuamento do tópico, não foi minha intenção. Considere então só a primeira parte do post que fala sobre TinyTypes. Ah e desculpa por discordar de você… prometo que vou melhorar…

Ps.: huaehuhau eu devia ter continuado minha carreira de jogador de futebol ao invés de inventar de fazer informática… :lol:

Bom, então continua com seus tiny types que eu continuo com meus primitivos. Pra que existem MVCs se eu posso ficar me matando lá embaixo com a unidade de tempo do meu período?

Claro, não sei OO, afinal pra se aprender JSP/Servlet, JSF, Spring, Hibernate, GWT ninguém precisa de OO né? Como se você fosse muita coisa pra me dizer isso. Esse é o problema da internet, não se dá pra discutir com alguém que vem julgar sua capacidade para impor o que acha certo.

Pelo contrário, essa visão é prática, não limitada. Se vc esta preocupado em modelar o mundo real provavelmente vc nunca entregou um projeto na vida.

Desculpe-me pelo desvirtuamento do tópico, não foi minha intenção. Considere então só a primeira parte do post que fala sobre TinyTypes. Ah e desculpa por discordar de você… prometo que vou melhorar…

Ps.: huaehuhau eu devia ter continuado minha carreira de jogador de futebol ao invés de inventar de fazer informática… :lol:

O problema que vc descreveu na primeira parte é resolvido com uma interface para validar CPF, nao com tiny types.

Desculpe-me pelo desvirtuamento do tópico, não foi minha intenção. Considere então só a primeira parte do post que fala sobre TinyTypes. Ah e desculpa por discordar de você… prometo que vou melhorar…

Ps.: huaehuhau eu devia ter continuado minha carreira de jogador de futebol ao invés de inventar de fazer informática… :lol:

O problema que vc descreveu na primeira parte é resolvido com uma interface para validar CPF, nao com tiny types.
Opa!
E como ficaria essa interface?
Mas quem implementa-la não poderia vir a ser um Tiny Type?

Abraços.

Não uma interface java, uma UI.

Tchello:

Opa!
E como ficaria essa interface?
Mas quem implementa-la não poderia vir a ser um Tiny Type?

Abraços.

A principio qualquer classe pode implementar uma interface.

mochuara:

Tchello:

Opa!
E como ficaria essa interface?
Mas quem implementa-la não poderia vir a ser um Tiny Type?

Abraços.

A principio qualquer classe pode implementar uma interface.

Sim, mas o que eu quis dizer é que se houver uma classe unicamente afim de implentar a interface, por exemplo, “CPFValidado” (nota: pensar num nome melhor) essa viria a se tornar um tiny type, correto?

bKn:

Bom, então continua com seus tiny types que eu continuo com meus primitivos. Pra que existem MVCs se eu posso ficar me matando lá embaixo com a unidade de tempo do meu período?

Claro, não sei OO, afinal pra se aprender JSP/Servlet, JSF, Spring, Hibernate, GWT ninguém precisa de OO né?

A sua analogia é tão falha quanto dizer “afinal para aprender a usar Martelo, Furadeira , Compressor ninguem precisa saber Física, né?”

Pois. Realmente para usar esses frameworks vc não precisa saber OO.
Agora, para construi-las , você precisa.

Quantos frameworks vc já fez ?

Tchello:

mochuara:

Tchello:

Opa!
E como ficaria essa interface?
Mas quem implementa-la não poderia vir a ser um Tiny Type?

Abraços.

A principio qualquer classe pode implementar uma interface.

Sim, mas o que eu quis dizer é que se houver uma classe unicamente afim de implentar a interface, por exemplo, “CPFValidado” (nota: pensar num nome melhor) essa viria a se tornar um tiny type, correto?

Não. A responsabilidade do tinytype é conter o valor e estiuplar o tipo (type).
Valiação , formatação, etc… é tudo coisa para outras classes. E essas não se caracterizam como Tiny Type.

Concerteza. E com uma setCPF(String CPF) também. Da pra fazer isso de n jeitos. Uns mais OO, outros menos, outros mais bonitos, outros mais feios…

Não leve a mal meu sarcasmo, eu sei que seu comentário não foi por mal. Só que ultimamente muitas respostas do pessoal aqui meio que beiram a arrogância, algo que eu já devia ter me acostumado com o pessoal de TI. Todo mundo aqui erra, todo mundo tem deficiências e acredito que procuram melhorar com elas. O problema é a auto-estima e o ego elevados, acaba desmerecendo o pessoal que ta sempre ralando e estudando.

Abraços

sergiotaborda:

A sua analogia é tão falha quanto dizer “afinal para aprender a usar Martelo, Furadeira , Compressor ninguem precisa saber Física, né?”

Ah claro, com certeza! Qualquer programador VB6 aprende Spring em uma semana. Diz isso pro Rod Johnson, pois eu paro por aqui.

sergiotaborda:

Quantos frameworks vc já fez ?

Em tempo: Eu disse consistencia, não validação. O objeto tem por essencia gerenciar sua consistencia. Já validação, como ouvi por ai do Sergio, deixe pros validadores.

Muito legal os depoimentos que foram levantados neste tópico, só vejo um problema com os tiny types, quando me deparo com tecnologias fora do JAVA, por exemplo integrando com Flex, vejo problema pois na integração ja existe objetos que estabelecem uma mapeamento entre o objeto actionscript e o objeto java como Date, String, etc. Isso fica complicado de trabalhar com tiny types, e não sei se há alguma forma de criar objetos no Flex, para funcionar com esta integração, e se existir uma forma, creio que não é tão trivial assim.

Abraços