Perché Java non utilizza l'incapsulamento con alcune classi?

La mia domanda è in relazione con System.ine System.outclassi (potrebbero essercene altre simili a quelle della libreria Standard). Perché? Non è una cattiva pratica in OOP? Non dovrebbe essere usato come: System.getIn()e System.getOut()? Ho sempre avuto questa domanda e spero di poter trovare una buona risposta qui.

Le definizioni per i campi ine outall'interno della Systemclasse sono:

public final static PrintStream out;
public final static InputStream in;

Queste sono costanti. Capita anche di essere oggetti, ma sono costanti. È molto simile alla classe di matematica:

public static final double E = 2.7182818284590452354;
public static final double PI = 3.14159265358979323846;

O nella classe booleana:

public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);

O nella classe Colore:

public final static Color white     = new Color(255, 255, 255);
public final static Color black     = new Color(0, 0, 0);
public final static Color red       = new Color(255, 0, 0);

Quando si accede a una costante pubblica che non cambia, non vi è alcun vantaggio significativo nell'incapsularla, concettualmente o basata sulle prestazioni. È lì. Non cambierà.

Non c'è alcuna differenza reale tra Color.whitee System.out.

La vera ragione è che si tratta di un problema precedente. Le System.in,out,errcostanti facevano parte di Java 1.0 ... e probabilmente molto più indietro. Quando era chiaro che il progetto aveva problemi, era troppo tardi per risolverlo. Il meglio che potevano fare era aggiungere i System.setIn,setOut,setErrmetodi in Java 1.1 e quindi affrontare i problemi relativi alle specifiche del linguaggio ¹ .

Questo è simile al problema del perché esiste un System.arraycopymetodo statico il cui nome viola le convenzioni di denominazione Java.

Se questo è "cattivo design" o no, penso che lo sia. Ci sono situazioni in cui l'attuale gestione non OO è un problema serio. (Pensa ... come puoi eseguire un programma Java all'interno di un altro quando i loro requisiti di flusso "IO standard" sono in conflitto. Pensa ... codice di test unitario che comporta la modifica dei flussi.)

Tuttavia, posso anche riferirmi all'argomento secondo cui l'attuale modo di fare le cose è più conveniente in molti casi.

^{1 - È interessante notare che le System.in,out,errvariabili ricevono una menzione speciale nel JLS come "semantica speciale". JLS afferma che se si modifica il valore di un finalcampo, il comportamento non è definito ... tranne nel caso di questi campi.}

Credo che l'oggetto out sia immutabile, il che lo rende in qualche modo sicuro (questo è discutibile) per essere tenuto in un campo statico finale pubblico.

Molte delle classi del JDK non rispettano i migliori principi di progettazione orientati agli oggetti. Uno dei motivi è il fatto che sono stati scritti quasi 20 anni fa, quando l'orientamento agli oggetti stava emergendo come un paradigma mainstream e molti programmatori semplicemente non li conoscevano come lo sono ora. Un ottimo esempio di cattiva progettazione dell'API è l'API Date & Time, che ha richiesto 19 anni per cambiare ...

Questa risposta è grande e vera.

Volevo aggiungere che in alcuni casi sono stati fatti dei compromessi per motivi di usabilità.

Gli oggetti di tipo String possono essere istanziati senza nuovo, evento quando String non è una primitiva:

String s = "Hello";

Essendo la stringa non primitiva, dovrebbe essere istanziata in questo modo:

String s = new String("Hello");          // this also works 

Ma il compilatore consente l'opzione OO più breve e meno, poiché String è di gran lunga la classe più utilizzata nell'API.

Inoltre, le matrici possono essere inizializzate in modo non OO:

int i[] = {1,2,3};

Abbastanza strano, un oggetto è un'istanza di una classe o un array . Le matrici di significato sono un tipo di classe completamente separato.

Le matrici hanno un lengthcampo pubblico che non è una costante. Inoltre non c'è documentazione sugli array di classi che sono un'istanza di. (da non confondere con la classe Arrays o java.reflect.Array).

int a = myArray.length;    // not length()