Variables and methods in the abstract class, where to put?

Question

Cliente and Fornecedor has name, phone and email in common what is the best way for me to treat this, should I create these variables in common in the abstract class? or is there a better way for me to do that?

Pessoa (Abstract):

public abstract class Pessoa {

    public abstract String getNome();
    public abstract String getEmail();
    public abstract String getTelefone();  
}

Customers:

public class Cliente extends Pessoa{

    public String nome;
    public String email;
    public String telefone;
    public String cpf;
    public String rg;

Cliente(String nome, String email, String telefone,String cpf, String rg){
    this.nome=nome;
    this.email=email;
    this.telefone=telefone;
    this.cpf=cpf;
    this.rg=rg;
}

public String getNome(){ return this.nome;}
public String getEmail(){return email;}
public String getTelefone(){return this.telefone;}
public String getCpf(){return this.cpf;}
public String getRg(){return this.rg;}   
}

Supplier:

public class Fornecedor extends Pessoa{

    public String nome;
    public String email;
    public String telefone;
    public String cnpj;
    public Long inscricaoestadual;

    Fornecedor(String nome, String email, String telefone,String cnpj, Long 
    inscricaoestadual){
        this.nome=nome;
        this.email=email;
        this.telefone=telefone;
        this.cnpj=cnpj;
        this.inscricaoestadual=inscricaoestadual;
    }

    public String getNome(){ return this.nome;}
    public String getEmail(){return email;}
    public String getTelefone(){return this.telefone;}
    public String getCnpj(){return this.cnpj;}
    public Long getIncricaoestadual(){return this.inscricaoestadual;}

}

Answer 1

It should create all that is common in the abstract class, both fields and methods, which is possible because it is the same in all classes. Even if the behavior of the methods are potentially different you can put and overwrite them if it is different in the inherited class, but the contract is already in the upper class.

Other problems

Even the methods don’t make much sense getters be abstract because they are likely to have standard and equal implementation for all classes. It might make sense that they’re not final, although you might question that.

Actually, you can question the use of getters and setters. It’s kind of become a pattern that everybody does this without even understanding why, people do it because they’ve seen it somewhere they’re supposed to. But there are also those who say you should not use them. I have already said this in several questions, one of which can serve as a reference to start studying the subject is Getters and Setters Methods. It’s best to use methods that tell you what you’re doing, you trade a mechanism for domain behavior. If it is to use mechanism then why not use the field directly? It has less problem than people imagine when you choose the mechanism because it is already abstraction leak.

There is another conceptual problem because doing this inheritance may have more than one object in the system for the same entity (the person). It seems quite wrong and violates the DRY data (the same time person is seen as a customer and time is seen with a supplier). I have talked about this in several questions:

• It can be considered a bad modeling practice to store all people (customers, employees, suppliers) in the same table?
• Modeling launches using customers and suppliers
• What to do if client can be both PF and PJ?
• Heritage and Polymorphism
• How to model a role in object orientation?

And there are others to research right here. Unfortunately it adopted a wrong pattern decades ago and then as almost everyone just follows ready models continue to do wrong. And then they blame the "old" programming paradigm, the procedural, for the wrong "decisions" of their own, and they think that talking about object-oriented programming is all right. Cohesiveness is the name of the game, independent of the paradigm. This form is not cohesive.

If you go deep, you also violate the SRP by keeping in the same object data that belongs to an entity (person) and a role (customer or supplier). It also violates the LSP because it engages many different things. Prefer composition to inheritance. In a way violates the IAPA of SOLID, because he confuses himself a little with the SRP. Examples of OO often teach wrong because they create artificial hierarchies that make it look like this kind of inheritance is good. There’s a good and bad side to SOLID.

In some cases it may make sense to create a single entity that has all the roles, mainly as database optimization avoiding a ratio 1:1. The problem is that it doesn’t look very good in memory (you can use it), then you have the call impedance Ismatch model and why people use Orms adding complexity to the software. That’s why I prefer to model in memory like the database, it’s so much simpler...

long for state enrollment? This doesn’t make sense, I don’t know why you hit the others and missed this one, maybe because you’re doing random things and hitting by coincidence. CPF or CNPJ field type in VARCHAR or INT database?.