Чому Java не використовує інкапсуляцію з деякими класами?

Моє запитання пов'язане з класами System.inта System.outкласами (можуть бути такі, як у бібліотеці Standard). Чому так? Це не погана практика в ООП? Чи не слід його використовувати так: System.getIn()і System.getOut()? У мене завжди було це запитання, і я сподіваюся, що тут знайду хорошу відповідь.

Визначення для inта outполів у Systemкласі:

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

Це константи. Вони бувають і об'єктами, але вони є константами. Це дуже те саме, що і клас Math:

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

Або в булевому класі:

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

Або в класі кольорів:

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

При зверненні до публічної константи, яка не змінюється, немає значної переваги для її інкапсуляції - концептуально чи на основі продуктивності. Її там. Це не зміниться.

Немає реальної різниці між Color.whiteта System.out.

Справжня причина полягає в тому, що це спадщина. Ці System.in,out,errконстанти були частиною Java 1.0 ... і , ймовірно, набагато далі. На той час, коли було зрозуміло, що в дизайні виникли проблеми, виправити це було вже пізно. Найкраще, що вони могли зробити, було додати System.setIn,setOut,setErrметоди в Java 1.1, а потім розібратися з питаннями мовної специфікації ¹ .

Це схоже на питання, чому існує статичний System.arraycopyметод, ім'я якого порушує умови імен Java.

Що стосується того, це "поганий дизайн" чи ні, я думаю, що це так. Бувають ситуації, коли поточне поводження, що не пов’язане з ООС, є серйозною проблемою. (Подумайте ... як можна запустити одну програму Java всередині іншої, коли їх "стандартний IO" потік вимог суперечить. Подумайте ... код тестування блоку, який тягне за собою зміну потоків.)

Однак я можу також звернутися до аргументу про те, що сучасний спосіб виконання справ є більш зручним у багатьох випадках.

^{1 - Цікаво зазначити, що System.in,out,errзмінні в JLS мають особливу згадку як такі, що мають "особливу семантику". JLS говорить, що якщо ви зміните значення finalполя, поведінка не буде визначеною ... за винятком цих полів.}

Я вважаю, що зовнішній об'єкт є незмінним, що робить його якось безпечним (це дискусійно) для зберігання в загальнодоступному статичному полі.

Багато класів в JDK не дотримуються кращих об'єктно-орієнтованих принципів дизайну. Однією з причин цього є той факт, що вони були написані майже 20 років тому, коли Орієнтація на об'єкти лише формувалася як парадигма мейнстріму, і багато програмістів просто не були знайомі з ними, як зараз. Дуже хорошим прикладом поганого дизайну API є API Date & Time, який знадобився їм 19 років, щоб змінити ...

Ця відповідь чудова і правдива.

Я хотів би додати, що в деяких випадках йдуть компроміси заради зручності використання.

Об'єкти типу String можна створити інстанціювати без нової події, коли String не є примітивом:

String s = "Hello";

Рядок, що є непомітивним, має бути створений таким чином:

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

Але компілятор допускає більш короткі, менші опції OO, оскільки String - це на сьогоднішній день найбільш широко використовуваний клас в API.

Також масиви можуть бути ініціалізовані неоновим способом:

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

Як не дивно, об'єкт є або екземпляром класу, або масивом . Значення масивів - це абсолютно окремий тип класу.

Масиви мають lengthпублічне поле, яке не є постійною. Також жодна документація на масиви класів не є примірником. (не плутати з класом Arrays або java.reflect.Array).

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