Olá pessoal,
Encontrei uma arquitetura de referência onde para todas as classes de domínio (POJO), tem uma interface, uma classe abstrata e uma classe concreta. Por exemplo:
package br.com.domain
public class Usuário{
String nome;
// apenas atributos
...}
package br.com....
public interface IUsuario{
public abstract operation1();
public abstract operation2();
...
}
public abstract class UsuarioKb implements IUsuario
{ }
public class UsuarioKbImpl extends UsuarioKb
{
@Override
public abstract operation1(){...}
@Override
public abstract operation2(){...}
}
Vocês sabem se isto é algum padrão de design? Ou, qual seria a justificativa de fazer isso?
[quote=brccosta]Olá pessoal,
Encontrei uma arquitetura de referência onde para todas as classes de domínio (POJO), tem uma interface, uma classe abstrata e uma classe concreta. Por exemplo:
package br.com.domain
public class Usuário{
String nome;
// apenas atributos
...}
package br.com....
public interface IUsuario{
public abstract operation1();
public abstract operation2();
...
}
public abstract class UsuarioKb implements IUsuario
{ }
public class UsuarioKbImpl extends UsuarioKb
{
@Override
public abstract operation1(){...}
@Override
public abstract operation2(){...}
}
Vocês sabem se isto é algum padrão de design? Ou, qual seria a justificativa de fazer isso?[/quote]
Justificativa ? Nenhuma, a não ser paranóia de desenhador de caixinha.
Olá rmendes08, tudo bem?
Eu também achei isso na primeira vez que via a arquitetura. Porém, pus a thread no Stack Overflow e parece que existe justificativa sim. Inclusive assemelha-se muito com o pattern Decorator.
[quote=brccosta]Olá rmendes08, tudo bem?
Eu também achei isso na primeira vez que via a arquitetura. Porém, pus a thread no Stack Overflow e parece que existe justificativa sim. Inclusive assemelha-se muito com o pattern Decorator.[/quote]
Veja bem, o que define um padrão de projeto não é o uso de interfaces/classes abstratas, mas sim o “como a OO é usada para resolver um determinado problema”. De fato, ao buscar desacoplamento é bastante comum usar interfaces. Também é correto que, ao definir uma interface, boa parte da implementação seja recorrente, o que você pode reaproveitar com classes abstratas.
No entanto, o que eu questiono é criar interfaces/classes abstratas para toda e qualquer entidade do sistema.
Sim, sem dúvida rmendes08. Você chegou no ponto que questionamos aqui no projeto. Também não acho necessária a criação de uma interface + uma classe abstrata para cada classe de domínio (entidade) do sistema.
Aqui no projeto tomaremos a seguinte posição: utilizaremos a Interface para o contrato de operações. SE, e somente SE houverem métodos recorrentes nas classes que implementam a interface, com o objetivo de promover reúso, criaremos uma classe abstrata com os métodos recorrentes que será estendida em tais classes concretas.
O que acha desta opção?
[quote=brccosta]Sim, sem dúvida rmendes08. Você chegou no ponto que questionamos aqui no projeto. Também não acho necessária a criação de uma interface + uma classe abstrata para cada classe de domínio (entidade) do sistema.
Aqui no projeto tomaremos a seguinte posição: utilizaremos a Interface para o contrato de operações. SE, e somente SE houverem métodos recorrentes nas classes que implementam a interface, com o objetivo de promover reúso, criaremos uma classe abstrata com os métodos recorrentes que será estendida em tais classes concretas.
O que acha desta opção?[/quote]
Eu acho mais sensata. É claro que existem casos que é preciso um pouco de up-front design, mas estes casos são a exceção, não a regra. Além disso, uma suite de testes automatizados oferecem mais segurança na hora de refatorar o código.