Qual è il modificatore di accesso preferito per le variabili di istanza di un oggetto di trasferimento dati?

3

Sto creando un oggetto di trasferimento dati e non posso decidere se sarebbe meglio dare solo accesso pubblico alle variabili di istanza o se ci sarebbe uno scopo nell'usare getter e setter per accedere ai dati?

In base all'articolo Trasferimento dati Articolo Wikipedia:

A DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

Sembra che l'accesso pubblico sarebbe giustificato per le variabili di istanza di un DTO.

Ecco l'esempio su cui sto lavorando:

Ivars con modificatore di accesso pubblico:

class ServerContext
{
    public String host;
    public String user;
    public String password;
    public int port;

    ServerContext(String host, String user, String password, int port) {
        this.host = host;
        this.user = user;
        this.password = password;
        this.port = port;
    }
}

vs. Modificatori di accesso privati:

class ServerContext
{
    private String host;
    private String user;
    private String password;
    private int port;

    ServerContext(String host, String user, String password, int port) {
        setHost(host);
        setUser(user);
        setPassword(password);
        setPort(port);
    }

    public String getHost() {
        return host;
    }

    public void setHost(String host) {
        this.host = host;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public String getUser() {
        return user;
    }

    public void setUser(String user) {
        this.user = user;
    }

    public int getPort() {
        return port;
    }

    public void setPort(int port) {
        this.port = port;
    }
}

EDIT: potrebbero essere argomenti validi per mantenere privati i ivars:

  1. Il potenziale di refactoring di un DTO in seguito per avere più funzionalità?

  2. Volendo mantenere costante l'implementazione tra DTO e regolare     oggetti?

posta Korey Hinton 24.05.2013 - 19:01
fonte

3 risposte

1

In parole povere.

Le variabili di istanza pubbliche violano l'incapsulamento.

In tal modo, il codice cliente verrà abbinato ai nomi delle variabili di istanza .

Il codice cliente non deve essere accoppiato a qualcosa di interno.

Le cose interne potrebbero cambiare in futuro.

L'interfaccia esterna (contratto) non dovrebbe essere influenzata da interni modificati.

Se non vuoi scrivere manualmente i tuoi getter e setter, lascia che l'IDE lo faccia per te.

Inoltre, getter e setter ti consentono di utilizzare il modello di builder per costruire e "creare" un'istanza del tuo oggetto senza il costruttore di cento parametri.

La classe che non ha comportamenti non significa che puoi violare l'incapsulamento. Inoltre, non significa che non avrà mai un comportamento in futuro.

    
risposta data 24.05.2013 - 21:02
fonte
2

I'm creating a data transfer object and can't decide whether it would be better to just give public access to the instance variables or if there would be a purpose to using getters and setters to access the data?

Le proprietà possono essere solo renamed . I metodi Get / Set possono essere deprecati, le regole di convalida applicate e codificate per convertire i dati in tipi diversi. Se non hai bisogno di quelle cose allora non perdere tempo.

A DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

I metodi set / get della proprietà non sono comportamenti o logica aziendale. Sono solo metodi di accesso per controllare l'ambito e l'accesso agli stati di intervallo. Una classe sarebbe ancora un DTO con i metodi get / set.

It seems that public access would be justified for a DTO's instance variables.

Se l'accesso pubblico alle proprietà era una cosa negativa. Java non avrebbe la parola chiave public per le proprietà. Se l'oggetto funziona correttamente con codice con accesso in lettura / scrittura alle proprietà, allora perché aggiungere una tonnellata di metodi get / set con una riga di codice.

Se d'altra parte hai bisogno di sola lettura, quindi crea i metodi get.

    
risposta data 24.05.2013 - 21:33
fonte
1

Dipende un po 'da come questi oggetti saranno usati, normalmente la visibilità pubblica sarebbe sufficiente (o come sono chiamati in lingue moderne - proprietà), ma poiché è java, puoi avere framework, dove dovresti avere metodi per ottenere e impostare valori (setAttribute (), getAttribute ()). Se non si utilizza alcun framework in cui è necessario disporre di metodi speciali per accedere ai membri degli oggetti, direi utilizzare campi pubblici. Naturalmente se hai bisogno di scrivere più linee di codice, generare codice aggiuntivo per impostare / ottenere valori è meglio per te.

    
risposta data 24.05.2013 - 19:47
fonte

Leggi altre domande sui tag