Java - Usuarios Dono e Cliente - Interface e Implements

Programação Java
#1

Olá Pessoal

Tenho as seguintes classes que refletem tabelas no db:

@Entity
public class Loja {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(updatable = false, nullable = false)
    private Long id;

    @OneToOne
    @JoinColumn(nullable = false)
    private User user;

    @Column(length=100)
    private String name;

    //GETTERS AND SETTERS
}

@Entity
public class User{

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(updatable = false, nullable = false)
    private Long id;

    @OneToOne(cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
    private Loja loja;

    @Column(length=100, unique=true)
    private String email;

    @Column
    private String tipo;

//GETTERS AND SETTERS

}

Minha dúvida:

Tenho dois tipos de usuários: dono e cliente.
Dono possuirá uma Loja. Cliente, obviamente não.

Estou tentando aplicar na prática, os conceitos de interface e implements.
No caso, eu criaria uma interface Dono e uma interface Cliente?
E teria um DAO para cada?

Ou teria uma entity pra cada? Mas e se eu aumentasse a variedade de tipos de usuario?

Obrigado!!!

#2

Referente a interface:

Cliente e dono farão uma mesma ação, porém de modos diferentes, se sim, então, crie uma interface com essa ação. Exemplo:

Cliente e dono concedem desconto, porém em valores diferentes, então uma interface desconto, seria apropriada.

Espero ter ajudado!

Abraço,

Thiago670

#3

Voce precisa ter uma necessidade, como nao apresentou, teria apenas efeito burocrático. Importante é você saber, para quando for o caso aplicar.

#4

Entendi. Entao no caso, o melhor seria fazer duas classes, Dono e Cliente, extendidas da entidade User.
Uma classe UserDao, e pensar numa interface qdo houver ações em comum com “cálculo” diferente, e nao caracteristicas diferentes.

#5

Nao faça essa herança. Dono e Cliente possuem responsabilidades diferentes. Dono possui Usuario, não herda de Usuario.

#6

Você sabe a diferença entre um gênio das artes e os meros mortais? Todo mundo é capaz de aprender a combinar cores e texturas e pintar bons quadros. Mas, os grandes mestres, criaram quadros que valem milhões. Por quê essa discrepância?
Simples, os grandes artistas (os de verdade, não os funkeiros) sabem o limite do exagero.

Dada a introdução, entenda que você tem N conceitos de OO, mas, isso não significa que deva aplicar todos, a todo momento. Parcimônia é fundamental.

Digo isso para que se atente ao fato de que cada classe deve, unica e exclusivamente, ter uma só responsabilidade.
Por isso, dificilmente suas classes de domínio (as mais fundamentais da aplicação, sem as quais o sistema não funcionaria) terão a necessidade de implementar alguma interface diferente de java.io.Serializable (e, mesmo assim, só quando isso for realmente necessário).

User interfaces, sim. Mas use quando precisar expor alguma parte da tua aplicação a terceiros. Ou, quando quiser delegar a responsabilidade pela construção da implementação dos métodos a outrém, independente de possuir uma implementação padrão.
Veja o caso da interface java.util.List. É uma interface que tem como responsabilidade se comportar como uma (pasmem) lista. É a implementação que dirá se ela será uma lista simples ou uma lista encadeada (java.util.ArrayList ou java.util.LinkedList). Além das implementações padrão, você, eu, a tia do hotdog, podemos implementar a interface List como precisarmos ou quisermos.

#7

Darlan
Transformou java em poesia, rsrs
Uma coisa q eu percebi estudando por conta foi ver q, na maioria dos exemplos q vi, tudo era interfaceado, e eu nao queria fazer assim. Eu entendi a teoria de interfaces, mas tava com um pouco de dificuldade de aplicar na pratica. Mas agora as coisas estao mais claras.

Javaflex
Entendi. Vou criar uma entity Dono e inserir um parametro do tipo User. Alem disso, vou tirar o parametro Loja do User e passar para o Dono.

Valeus!!!

#8

É por ai mesmo. Se for usar banco de dados relacional, é mais prático fazer o modelo orientado a banco de dados do que orientado ao objetos.