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.

enter image description here

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.

  • 2
    "I do not like to mix data with manipulating data". This is at odds with what the teacher was trying to show you. It seems he was trying to help you build cohesive classes that grouped related data and functionality. There are many good approaches. Combining data with data-manipulating methods can be done well. Separating the two can also be done well. Take time to understand both. – bitsoflogic Nov 29 at 15:57
  • @bitsoflogic yes, I know them both, so I said "I do not like", it's a preference of mine, of course you can do it in another way. It 's that I worked a lot of time with "Entity - Component - System" and this ended up influencing me in the way of thinking when designing things. And the teacher, unfortunately what I feel he was trying to pass me was not reflected, so I gave up the conversation, people sad me very quickly, when I see that the person is not even trying to use his head, I'm already out, more disrupts us than it helps, – PerduGames Nov 29 at 17:43
  • If you can ignore what the title seems to imply, check out How to explain object-oriented programming concepts to a 6-year-old. It gives a great introduction to the 4 basic features of OOP: encapsulation, abstraction, inheritance and polymorphism. – Greg Burghardt Nov 30 at 12:09
  • And maybe your teacher had read this: I Shall Call It.. SomethingManager. – Greg Burghardt Nov 30 at 12:10
  • @GregBurghardt I know about both, but I read the two articles anyway, as for the second, I agree that "manager" is not a good name, and I thought for a long time trying to find one, but I did not find it, I'll update the question with a class code " client "and" clientManager ", it would be nice if you also update your answer to solve those class names, I'll try here as well. – PerduGames Nov 30 at 12:30

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

Screenshot of the definition of the word manager in the Oxford dictionary

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.

  • Updated question. Let's fix it! – PerduGames Nov 30 at 13:10
  • I thought here, I really think this "ClientManager" class is just a client manager, the name suits then. It does nothing but manage(add, remove, list) "Clients" which is a group of "Client". Maybe "Clientele". – PerduGames Nov 30 at 14:02
  • But I think "clientele" would be just a better name for the ArrayList, it does not say what the class does as "ClientManager" says. – PerduGames Nov 30 at 14:07
  • @PerduGames, sounds like a ClientList/ClientCollection to me. – rediVider Dec 5 at 21:57

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.