Java neden bazı sınıflarla kapsülleme kullanmıyor?

Sorum şu System.inve System.outsınıflarla ilgili (Standart kütüphanedeki gibi başkaları da olabilir). Neden? OOP'de bu kötü bir uygulama değil mi? Şunun gibi kullanılmamalı mı : System.getIn()ve System.getOut()? Her zaman bu soruyu yaşadım ve umarım burada iyi bir cevap bulabilirim.

Sınıf içindeki inve outalanlarının tanımı System:

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

Bunlar sabittir. Onlar da nesneler oluyor, ama bunlar sabittir. Math sınıfı ile aynı.

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

Veya Boolean sınıfında:

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

Veya Color sınıfında:

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

Değişmeyen bir kamu sabitine erişirken, onu kapsüllemek için önemli bir avantaj yoktur - kavramsal olarak veya performansa dayalı. Orada. Değişmeyecek.

Color.whiteVe arasında gerçek bir fark yoktur System.out.

Asıl sebep, bunun eski bir konudur. System.in,out,errSabitleri Java 1.0 parçası ... ve muhtemelen çok daha geriye idi. O zaman, tasarımın sorun yaşadığı açıktı, düzeltmek için çok geçti. Yapabilecekleri en iyi şey, System.setIn,setOut,setErrJava 1.1'deki yöntemleri eklemek ve ardından dil belirtimi sorunları ¹ ile ilgilenmekti .

Bu, neden System.arraycopyadının Java adlandırma kurallarını ihlal ettiği statik bir yöntemin olduğu sorununa benzer .

Bunun "kötü tasarım" olup olmadığına gelince, sanırım öyle. Mevcut OO dışı işlemenin ciddi bir sorun olduğu durumlar vardır. (Bir Java programını çalıştıracak nasıl ... düşün içine onların "standart IO" dere gereksinimleri çatışma. Düşün zaman başka ... birim gerektirir bir akışlarını değiştirerek bu kodu test.)

Bununla birlikte, birçok şeyi yapmanın mevcut yolunun daha uygun olduğu argümanı ile de ilişki kurabilirim .

^{1 - Bu dikkat etmek ilginç System.in,out,err Değişkenlerin JLS'de "özel anlambilim" olarak özel olarak belirtildiğini . JLS, eğer bir finalalanın değerini değiştirirseniz, bu alanların haricinde davranışın tanımsız olduğunu söyler .}

Dıştaki nesnenin değişmez olduğuna inanıyorum, bu da kamuya açık bir statik alanda tutulması için bir şekilde güvenli (bu tartışmalı).

JDK'daki sınıfların çoğu, en iyi nesne yönelimli tasarım ilkelerine saygı göstermiyor. Bunun bir nedeni, Nesne Oryantasyonunun sadece bir ana paradigma olarak ortaya çıktığı ve pek çok programcının şu an olduğu gibi onlara aşina olmadığı neredeyse 20 yıl önce yazılmış olmalarıdır. Kötü bir API tasarımına çok iyi bir örnek, 19 yılını değiştiren Tarih ve Saat API'sidir ...

Bu cevap harika ve doğru.

Bazı durumlarda kullanılabilirlik adına tavizler verildiğini eklemek istedim .

String türünün nesneleri, String ilkel olmadığında yeni, olay olmadan başlatılabilir:

String s = "Hello";

İlkel olmayan bir dize olması, şöyle başlatılmalıdır:

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

Ancak derleyici daha kısa, daha az OO seçeneğine izin verir, çünkü String API'de en yaygın kullanılan sınıftır.

Ayrıca, diziler OO olmayan bir şekilde başlatılabilir:

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

Yeterince garip, bir nesne bir sınıfın örneği veya bir dizidir. . Anlam dizileri tamamen ayrı bir sınıf türüdür.

Diziler, lengthsabit olmayan bir ortak alana sahiptir. Ayrıca sınıf dizileri ile ilgili hiçbir dokümantasyon örneği yoktur. (Arrays sınıfı veya java.reflect.Array ile karıştırılmamalıdır).

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