Quando utilizzare sensibilmente la variabile pubblica in un linguaggio OOP?

Ogni volta che fai interopzioni con C o altre lingue, troverai spesso che devi fare tutti i tipi di cose considerate sgradevoli in OOP. L'uso di classi con variabili pubbliche è spesso uno di questi.

Inoltre, anche quando si lavora interamente in una singola lingua, a volte si vogliono quelle che sono effettivamente delle strutture mutabili, e andare allo sforzo di creare campi nascosti e accessorie visibili è una seccatura apparentemente senza valore. Certo, a volte gli strumenti o le funzionalità del linguaggio rendono la seccatura piuttosto bassa ma non 0.

In genere è considerato sicuro e ragionevole utilizzare variabili pubbliche quando sono immutabili, cioè costanti. In Java è abbastanza comune vedere questo tipo di cose:

public final class Direction {

    public static final String NORTH = "north";
    public static final String SOUTH = "south";
    public static final String EAST = "east";
    public static final String WEST = "west";

}

Ma per aggiungere un po 'di spunti di riflessione, vorrei contestare che questo genere di cose sia ridondante:

public class Person {

     private int age;
     private String name;

     public void setAge(int age) { this.age = age; }
     public int getAge(){ return age; }
     public void setName(String name) { this.name = name; }
     public String getName() { return this.name; } 

}

Ovviamente aderisce ad una convenzione che è ampiamente accettata come corretta, ma sembra mancare il punto di incapsulamento per ragioni che sono documentate in modo eccellente in questo articolo , consiglio vivamente di dargli una lettura :)

I tipi di valore dovrebbero quasi sempre avere variabili pubbliche. Di 'che hai un tipo simile al seguente (C ++, ma potrebbe davvero essere qualsiasi lingua):

struct Point {
  int x;
  int y;
}

Rendere immutabile significa solo allocare tutto il tempo (dopo tutto si modificherà molto l'oggetto). Aggiungere accessors e mutator non ha alcuno scopo e sostanzialmente complica l'uso della classe. Basta avere membri pubblici!

Come case study , nella versione 1.8 di Minecraft il gioco è passato alle coordinate di passaggio intorno come una classe immutabile invece di tre doppi, e il risultato è stato problemi di prestazioni significativi a causa della balbuzie di GC.

Non riesco a pensare a una situazione sensata, al di fuori del codice dedicato alle prestazioni estreme. Potrebbe essere un requisito di qualche framework per esporre pubblicamente variabili / proprietà (come Java fa implicitamente con proprietà anotated in JPA).

Penso che non sia molto manutentabile esporre variabili / proprietà pubbliche perché lasci che le classi che usano si affidino a cose specifiche. Cosa succede se un numero intero pubblico deve essere cambiato a lungo per qualche motivo? Tutte le classi che usano devono essere cambiate. Poi c'è anche la nozione di (im) mutabilità. Una classe che usa non vuole sapere o controllare se una variabile / proprietà è 'readonly' o 'const' (immagino che questi siano ciò che è 'finale' in Java). Perché se loro (devono) sapere questo, sanno molto di più della classe usata che avrebbero quando tutto era incapsulato. Perché dovremmo usare le classi per sapere il meno possibile sugli altri? Ancora manutenibilità e S dai principi SOLID.

L'unica volta che si usa public sulla decelerazione del campo è quando si dichiarano i campi public static e final ( constants ).

Se il campo rappresenta un elemento condiviso immutabile, non vedo perché non dovremmo usare public .

Ci sono alcuni linguaggi di programmazione orientati agli oggetti che non supportano nemmeno variabili pubbliche - incluso Smalltalk, che viene spesso citato come il principale creatore del concetto di programmazione orientata agli oggetti. Se queste lingue possono andare via senza questa caratteristica senza che venga vista come un'omissione problematica (e non ho mai visto davvero che l'opinione sia comune) ci sono problemi con Smalltalk che gli hanno impedito di diventare veramente popolare, ma questo non è uno di loro), quindi penso che la risposta debba essere "mai" o almeno vicino ad essa. Tu puoi usare le variabili pubbliche come scorciatoia per evitare la necessità di fornire getter e setter, ma non c'è bisogno di farlo, e perché c'è una conseguenza negativa (aumento accoppiando al design interno della classe) Suggerirei che sacrificare il design per brevità in questo modo non è spesso una buona idea.

(Si noti che questo non si applica in lingue che forniscono proprietà pubbliche, ad esempio C #, che sono sintatticamente come variabili pubbliche ma consentono una modifica dell'implementazione senza modificare l'interfaccia pubblica della classe, quindi non avere conseguenze negative allo stesso modo)