Warum verwendet Java bei einigen Klassen keine Kapselung?

Meine Frage bezieht sich auf System.inund System.outKlassen (möglicherweise gibt es andere wie die in der Standardbibliothek). Warum das? Ist das nicht eine schlechte Praxis in OOP? Sollte es nicht so verwendet werden: System.getIn()und System.getOut()? Ich hatte immer diese Frage und hoffe, dass ich hier eine gute Antwort finden kann.

Die Definition für die Felder inund outin der SystemKlasse lautet:

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

Das sind Konstanten. Sie sind zufällig auch Objekte, aber sie sind Konstanten. Es ist sehr ähnlich wie in der Mathe-Klasse:

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

Oder in der Booleschen Klasse:

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

Oder in der Farbklasse:

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);

Wenn auf eine öffentliche Konstante zugegriffen wird, die sich nicht ändert, hat die Verkapselung keinen wesentlichen Vorteil - konzeptionell oder leistungsbasiert. Es ist da. Es wird sich nicht ändern.

Es gibt keinen wirklichen Unterschied zwischen Color.whiteund System.out.

Der wahre Grund dafür ist, dass dies ein altes Problem ist. Die System.in,out,errKonstanten waren Teil von Java 1.0 ... und wahrscheinlich viel weiter zurück. Als klar war, dass das Design Probleme hatte, war es zu spät, um es zu beheben. Das Beste, was sie tun konnten, war, die System.setIn,setOut,setErrMethoden in Java 1.1 hinzuzufügen und sich dann mit den Sprachspezifikationsproblemen ^{1 zu} befassen .

Dies ähnelt der Frage, warum es eine statische System.arraycopyMethode gibt, deren Name die Java-Namenskonventionen verletzt.

Ob dies "schlechtes Design" ist oder nicht, glaube ich. Es gibt Situationen, in denen die derzeitige Nicht-OO-Behandlung ein ernstes Problem darstellt. (Überlegen Sie, wie Sie ein Java-Programm in einem anderen ausführen können, wenn die "Standard-E / A" -Stream-Anforderungen kollidieren. Überlegen Sie, ob ... Unit-Test-Code die Streams ändert.)

Ich kann mich jedoch auch auf das Argument beziehen, dass die derzeitige Vorgehensweise in vielen Fällen praktischer ist.

^{1 - Es ist interessant zu bemerken, dass die System.in,out,errVariablen in der JLS als "spezielle Semantik" besonders erwähnt werden. Das JLS sagt, dass, wenn Sie den Wert eines finalFeldes ändern , das Verhalten undefiniert ist ... außer im Fall dieser Felder.}

Ich glaube, dass das Out-Objekt unveränderlich ist, was es irgendwie sicher macht (dies ist fraglich), in einem öffentlichen statischen Endfeld gehalten zu werden.

Viele der Klassen im JDK respektieren nicht die besten objektorientierten Gestaltungsprinzipien. Ein Grund dafür ist die Tatsache, dass sie vor fast 20 Jahren geschrieben wurden, als sich die Objektorientierung erst als Mainstream-Paradigma herauskristallisierte und viele Programmierer sie einfach nicht so kannten, wie sie jetzt sind. Ein sehr gutes Beispiel für ein schlechtes API-Design ist das Date & Time API, dessen Änderung 19 Jahre gedauert hat ...

Diese Antwort ist großartig und wahr.

Ich wollte hinzufügen, dass in einigen Fällen Kompromisse aus Gründen der Benutzerfreundlichkeit gemacht wurden.

Objekte vom Typ String können ohne neues Ereignis instanziiert werden, wenn String kein Grundelement ist:

String s = "Hello";

Ein String, der kein Primitiv ist, sollte wie folgt instanziiert werden:

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

Der Compiler lässt jedoch die kürzere, weniger OO-Option zu, da String die bei weitem am häufigsten verwendete Klasse in der API ist.

Arrays können auch auf Nicht-OO-Weise initialisiert werden:

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

Seltsamerweise ist ein Objekt entweder eine Instanz einer Klasse oder ein Array . Das heißt, Arrays sind ein völlig separater Klassentyp.

Arrays haben ein lengthöffentliches Feld, das keine Konstante ist. Außerdem gibt es keine Dokumentation zu den Klassen-Arrays, von denen eine Instanz ist. (Nicht zu verwechseln mit Arrays class oder java.reflect.Array).

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