Miglioramenti in un'architettura "data - manager - wrapper"

1

Ho programmato usando l'architettura sottostante, dove "cliente, ordine, pezzo" sono solo classi di dati, non hanno metodi e "manager" sono i manipolatori di quei dati, "ClothingStore" è un wrapper in cui non c'è logica, chiama solo i metodi dei manager e restituisce ciò che restituisce, quindi "ClothingStore" sarebbe una libreria che integra le parti del progetto.

Nell'ultimoprogettohousatoquestaarchitettura,hochiamatoun"manager" a un altro nel costruttore, quando aveva bisogno di comunicare con l'altro, era un semplice progetto scolastico, che dovevo consegnare presto, ma in altri progetti ho creato un "sistema pub / sub" per questa comunicazione.

Mi piacerebbe sentire critiche su questa architettura e possibili miglioramenti in essa, e altri tipi di architetture che potrebbero servirmi.

Perché ho provato a iniziare una conversazione con uno dei miei insegnanti, e ha detto che era male quello che ho fatto, mi ha detto di associare il "client" con "order", mettere i metodi in "client" e "order", ha detto che questo eviterebbe di accoppiare le cose come stavo facendo, "tutto nel wrapper", ma sentivo che non sapeva nemmeno cosa fosse un wrapper e ho rinunciato alla conversazione, penso totalmente al contrario, non mi piace mescolare i dati con la manipolazione dei dati, l'architettura di cui sopra ho fatto esattamente per sganciare le cose, ma a volte sento che c'è qualcosa di sbagliato in esso, potrebbe migliorare, quindi sono qui.

Esempio 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;
    }

}

Esempio di classe ClientManager:

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() {
        // ...
    }

}

Non sono un programmatore Java, sto solo facendo un lavoro scolastico dove deve essere in Java. Ho già giocato con Python, Shell, Perl, ho iniziato il mondo della programmazione in C # molti anni fa, ho lavorato duramente con PHP, oggi preferisco non essere più coinvolto. Al momento sono al lato C / C ++ / JavaScript (e ho intenzione di specializzarmi qui o qualcosa di nuovo da emergere che mi piacesse)

Gli attributi della classe "Client" sono pubblici, è che per ora possono essere così, quando implemento la convalida dei dati, forse inserirò il loro "get / set", ma non so se la validazione sia realmente il "Cliente" e non in un'altra classe intermedia, COME un Controller MVC, AD ESEMPIO, devo ancora pensarci. Ma non mi piace creare "get / set" per tutti gli attributi automaticamente, "get / set" che non fa altro che "cambia / restituisce" l'attributo, se è così preferisco lasciarlo così com'è, pubblico. Considero il "get / set" automatico come una cattiva pratica di programmazione, che persino il mio insegnante insegna che ha ragione.

Perché la classe "Client" non eredita la classe "Contact"? perché il Cliente non è un contatto e ho pensato che se in futuro volessi che il cliente avesse più di un contatto, sarebbe interessante poterlo facilmente avere più di un contatto, essendo il contatto un componente, potrebbe creare un ArrayList e il client può avere tutti i contatti che desidera, per esempio.

    
posta PerduGames 29.11.2018 - 16:08
fonte

1 risposta

0

La parola "manager" non è molto descrittiva. La ricerca di " manager " nel dizionario di Oxford ti dà 4 definizioni diverse e due sotto-definizioni:

Senzachequestodiventiunalezionediinglese,ilpuntoprincipaleèchelaparola"manager" non è abbastanza specifica per altri programmatori da dedurre cosa fa una classe con il suo nome.

Jeff Atwood espande questo in Devo chiamarlo .. 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.

Quindi tutto si riduce a una delle cose più difficili in informatica: nominare le cose - e SomethingManager è non un nome descrittivo.

    
risposta data 30.11.2018 - 13:21
fonte

Leggi altre domande sui tag