[quote=alex.lopes]Bom dia Pessoal,
Porém minha dúvida é em relação para quando de fato eu tenho que utilizar uma interface ou não.
Olhando os Mocks para JUnit (como por exemplo o EasyMock), ele diz para fazer mock em cima de interfaces (embora exista um projeto para mock em cima de classe concreta), mas se for para fazer mock apenas em interfaces, praticamente TODAS classes concretas do meu projeto terá que estar associada a alguma interface, e ao meu ver, isso é um desperdício de recursos e produtividade.
[/quote]
O seu conceito de interface está certo. O problema de forçar que todas suas classes derivem de uma interface para poder usar mockobjects é obviamente errado (vc está programando orientado aos mockobjects em vez de À sua aplicação). Contudo …
Vc deve programar para interfaces. Houve-se muito isto, mas o que significa ? Significa que vc deve sempre - e apenas - se preocupar com as interações dos objetos com os outros e portanto nos seus mecanismos (interface) e não com o seu estado. O estado cabe ao objeto se preocupar. Então uma prática , que eu acho muito intessante, é sempre começar por declarar uma interface. Por exemplo ,digamos , Cliente.
Ai vc vai definindo que me´todos quer nessa interface à medida que precisa deles no uso da classe. No caso poderiamos colocar apenas os getters e não os setters, Isto porque os setters só interessam à implementação real da interface pois alteram o seu estado.
Ai vc cria uma classe abstrata que implementa essa interface. Vc implementa os métodos comuns e genericos e deixa os outros.
Por exemplo se a sua classe aceita listenerns vc programa o mecanismo de add/remove/fire dos listeners.
Depois vc cria uma implementação concreta partindo da classe abstrata.
Quando vc precisar passar como argumento ou retorno vc declara sempre a interface. por exemplo geraFatura (Cliente c , Compra p )
Isto dá-lhe a flexibilidade de criar objetos mock e de criar diferentes tipos de implementações. Esta estrutura é tanto mais verdade quanto mais generica for a utilização da interface. Esta estrutura é usada para Collections Framework. Um clássico.
Em certas circunstancias, sobretudo em classes de dominio, pode ser trabalhoso e deproposital manter esta estrutura. É uma questão de escolhas (trade-off)
Para fazer mocks de forma simples existe a classe Proxy que gera uma classe que emula qq interface e vc constroi o miolo de forma generica.
Uma classe semelhante na biblioteca Javassist permite fazer o mesmo como classes (vc cria uma classe que herda de uma classe pai de forma generica, num processo semelhante ao de Proxy). Vale a pena conhecer estes mecanismos de reflection para criar implementações rápidas de interfaces. Depois com tempo vc cria uma implementação completamente funcional.
