Improvements in a "data - manager - wrapper" architecture

Question

I have programmed using the architecture below, where "client, order, piece" are just data classes, have no methods, and "managers" are the manipulators of that data, the "ClothingStore" is a wrapper where there is no logic, only calls the methods of the managers and return what they return, so the "ClothingStore" would be a library integrating the parts of the project.

In the last project I used this architecture, I called a "manager" to another in the constructor, when he needed to communicate with the other, it was a simple school project, which I needed to deliver soon, but in other projects I created a "pub/sub system" for this communication.

I would like to hear critiques of this architecture and possible improvements in it, and other types of architectures that could serve me.

Because I tried to start a conversation with one of my teachers, and he said it was bad what I did, he told me to associate "client" with "order", put methods in "client" and "order", said that this would avoid coupling things as I was doing, "everything in the wrapper", but I felt he did not even know what a wrapper was and I gave up the conversation, I totally think otherwise, I do not like to mix data with manipulating data, the above architecture I did exactly to uncouple things, but sometimes I feel something is wrong in it, it could improve, so I'm here.

Example Client.java:

public class Client {

    public String cpf;
    public String name;
    public Contact contact;

    public Client(String cpf, String name, Contact contact) {
        this.cpf = cpf;
        this.name = name;
        this.contact = contact;
    }

}

Example ClientManager Class:

package Managers;

import java.util.ArrayList;

import Data.Client;
import Data.Contact;

public class ClientManager {

    ArrayList<Client> clients = new ArrayList<Client>();

    public ClientManager() {}

    public int getClientsSize() {
        return clients.size();
    }

    public void add(String cpf, String name, String nameContact, 
                          String address, String telephone, String email) {         
        Contact newContact = new Contact(nameContact, address, telephone, email);
        Client newClient = new Client(cpf, name, newContact);
        clients.add(newClient);
    }

    public void add(ArrayList<String> client) {         
        // ...
    }

    public void remove(int cpf) {
        // ...
    }

    public String list() {
        // ...
    }

}

I'm not a Java programmer, I'm just doing a school job where it needs to be in Java. I've already played with Python, Shell, Perl, started the programming world in C# many years ago, I've worked hard with PHP, today I prefer not to get involved anymore. I'm over to the C/C++/JavaScript side currently(And I intend to specialize here or something new to emerge that appealed to me).

The attributes of the "Client" class are public, it is that for now they can be so, when I implement data validation I will perhaps put their "get/set", but I do not know if the validation really in the "Client "and not in another intermediary class, LIKE an MVC Controller BY EXAMPLE, I still have to think about it. But I do not like to create "get/set" for all attributes automatically, "get/set" that do nothing but "change/return" the attribute, if it is so I prefer to leave it as is, public. I consider automatic "get/set" to be a bad programming practice, which even my teacher teaches it to be right.

Why does not the "Client" class inherit the "Contact" class? because Client is not a contact, and I thought, if in the future I wanted the client to have more than one contact, it would be interesting to be able to easily make him have more than one contact, the contact being a component, I could create a ArrayList and the client can have as many contacts as he wants, for example.

Answer 1

The word "manager" is not very descriptive. Looking up "manager" in the Oxford dictionary gives you 4 different definitions, and two sub-definitions:

Without this becoming an English lesson, the main point is the word "manager" just isn't specific enough for other programmers to infer what a class does by its name.

Jeff Atwood expands on this in I Shall Call It.. SomethingManager:

This imprecision makes Manager a bad word to use in naming classes. For instance, take a class named UrlManager – you cannot tell whether it pool URLs, manipulates URLs or audits the use of them. All the name tells you is that this class does something with URLs. On the other hand, the name UrlBuilder provides a much clearer picture of what the class does.

So it all comes down to one of the hardest things in computer science: naming things — and SomethingManager is not a descriptive name.