A client class that registers clients in itself would be a cohesive class?

Question

Studying cohesion. Since a cohesive class is one that has unique responsibility, it would make sense for the class Cliente own these methods? If we think in the real world, a customer cannot register a customer, that would be the responsibility of the employee or system. That way, the class Cliente should not only store customer data?

public class Cliente {
    public String name;
    public String phone;
    public String email;

    public Cliente(String name, String phone, String email) {
        this.name = name;
        this.phone = phone;
        this.email = email;
    }
    public void addCliente(Cliente c){
        //implementação
    }
    public void removeCliente(Cliente c){
        //implementação
    }

}

Answer 1

The simple answer is no. But the logic presented for not doing so is not quite this.

The deeper answer is: it depends. Always.

The most common mistake people make is wanting to define something universally. I always say that if the answers already existed in a fixed way it wouldn’t need a lot more people making systems. The work still exists because each situation is different and without picking up all requirements can not answer this.

Anything can if the requirement is harvested correctly, makes sense and is feasible.

Within the normal one Cliente only has data on a client, nothing else. Anything beyond that is too much responsibility for him.

This is not to say that it is forbidden to violate this and give this class more responsibilities, anything can if you know what you are doing. If you don’t know it’s not a rule that will save the person.

I don’t even know what it is to register in the context of the question. Is it typing data? Is it storing in the database? Without fully understanding the problem and with precision there is no way to make correct decisions. The code does not show where to register.

If it is to enter data then the normal is to have another class responsible for it.

Certainly wouldn’t be an employee. Nor will I speak because it may be that the typing may occur by someone who is not an employee (has such requirement), can be done by the client himself physically (very common contrary to what the question thinks), which does not mean that the class should do this.

Typing is UI, it has nothing to do with the client entity itself. You may have, perhaps, a CRUD for the client, but this is not on Cliente. One of the biggest mistakes is making user interaction happen together with the entity. In the past it was done a lot. Imagine one day changing the shape of UI. Complete madness.

But it’s not official because then that class would have to have almost everything that the system allows to do, because a lot of the things in the system an employee does.

Even worse, the same thing can be done by more people, not just the employee. It’s a complete mess trying to think about it.

I didn’t even get the credit the customer should already be a mistake, equal to the official. Circumstantially someone is a client, is a relationship and not a real entity. The same entity may be a client and official, among other things at the same time. I have several answers here which shows that almost all systems are wrong when they adopt this strategy of interpreting the relationship, the paper, as if it were a real world entity. Including the largest market Erps. See more, among others.

If it is to store in a database falls into the same UI problem. Even because the way of storing can change it can not be in the entity) or in the paper that is the most correct). It makes no sense to mix these things.

And think of something else. If you have a class Jogador and you will use it to form a Time. Who should be responsible for putting a player on the team, the player or the team? Only among these options. It seems obvious to me that it is the entity that groups players that should do this, again, between these two options.

Then you can think: is not the coach that puts a player on the team? And then falls into something similar to the employee? Even could, but I doubt that it is. Systems are more complex than that, if you don’t do the right maintenance will be complicated in the future. It’s not the technician who puts someone on the team, it’s a people commission. The coach can do something to later the player join the team, but it is not he who puts it. You have to think about what the real process is like. Artificially thinking the team could have an addition action of a player within it, among other options that one can do with the team. And maybe only a few classes could call this method.

And I’m not even saying that there would be something UI or DB in this team, it’s just the entity in the application, if it needs to interact or persist somewhere there will be other classes that will do this, connected somehow with the Time.

So my understanding is that you need an entity that "collects" customers, and then of course, it has the ability to add or remove them. Or better yet, it would be a collection of people who have various relationships with the organization that owns the application, perhaps separated into physical, legal and perhaps other, as foreign.

Yes, it is complicated to do it right, even more so without concrete requirements. That’s why most do wrong to "buy time". And then he goes after the loss, spending more time, doing tricks, remodeling everything, paying the interest.

I can’t guarantee it, but you probably learned OOP as most people learn, that is, with artificial examples. These examples, of book even, some consecrated, teach the mechanism, but do not teach to model systems. On the contrary, it makes everyone understand everything wrong as if it were an object-oriented program of truth. But it is not on such a wrong path, the basis of the question was going better than many understand.

In doubt the cohesion you can put less in the classes, but of course if you put much less cohesion is lost too, and that’s just experience, there’s no recipe ready.

I love to see people trying to learn the right thing, but every time I see that the pressure for "results" makes people deliver "the first model that comes to mind", they often follow some cake recipe, and hope to be right for it.