Java'nın ortak alanları bu noktada sadece trajik bir tarihsel tasarım hatası mıdır? [kapalı]

Bu noktada Java ortodoksisi, nesne durumu için hiçbir zaman genel alanları kullanmamalıdır. (Mutlaka hemfikir değilim, ama bu benim sorumla ilgili değil.) Buna göre, bugün bulunduğumuz yerden Java'nın ortak alanlarının dil tasarımında bir hata / kusur olduğunu söylemek doğru olur mu? Yoksa bugün bile dilin yararlı ve önemli bir parçası olduklarının rasyonel bir argümanı var mı?

Teşekkürler!

Güncelleme: C #, Python, Groovy vb. Gibi daha zarif yaklaşımları biliyorum. Doğrudan bu örnekleri aramıyorum. Gerçekten sadece bir sığınakta derin bir insan olup olmadığını merak ediyorum, kamu alanlarının gerçekten ne kadar harika olduğunu ve kitlelerin nasıl sadece koyun vb.

Güncelleme 2: Açıkça statik nihai ortak alanlar, genel sabitler oluşturmanın standart yoludur. Daha çok nesne durumu (hatta değişmez durum) için kamusal alanları kullanmaya atıfta bulunuyordum. Ben sabitler için kamu alanları kullanmak gerekir, ancak devlet için değil bir tasarım kusuru gibi görünüyor düşünüyorum… bir dil kuralları kurallar tarafından değil, sözdizimi ile doğal olarak uygulanmalıdır.

Alan son olduğu ve yalnızca uygulamada dahili olarak kullanıldığı sürece, diğer uygulamalar için bir API'de gösterilmediği sürece onları seviyorum . Bu, kodunuzu daha kısa ve daha okunabilir tutar.

Ortak alanları açığa çıkararak, uygulamayı da açığa çıkardığınız için API'daki ortak alanları göstermemelisiniz. getXXX()Bunun yerine bir yöntem olarak ortaya çıkarırsanız , API arabirimini değiştirmeden uygulamayı değiştirebilirsiniz. Örneğin, değeri uzak bir hizmetten değiştirebilir ve alabilirsiniz, ancak API'yi kullanan uygulamaların bunu bilmesi gerekmez.

Bu, değişmez sınıflardaki public finalalanlar için uygun bir tasarımdır .

Gönderen Etkili Java :

Madde 14: Ortak sınıflarda, ortak alanları değil erişimci yöntemlerini kullanın

... bir sınıf pakete özelse veya özel bir iç içe sınıfsa, veri alanlarını açığa çıkarmanın doğasında yanlış olan hiçbir şey yoktur. Bu yaklaşım, erişimci yöntemi yaklaşımından daha az karmaşa oluşturur.

Bir kamu sınıfının alanları doğrudan ortaya çıkarması asla iyi bir fikir olmasa da, alanların değişmez olması daha az zararlıdır.

Ayrıca bkz. Neden JavaBeans yerine değişmez POJO kullanmamalıyım?

Get / set yöntemi çiftlerinin kullanılması trajik tarihsel tasarım hatasıdır. Özellikleri ayrıntılı ve verimsiz bir şekilde uygulayan başka bir dil düşünemiyorum.

Bence ortak alanlar, karmaşık bir sayı veya nokta gibi bir değer türü olan bir sınıf için uygundur, burada sınıf, C tarzı bir yapı gibi grup ilkel türlerinden biraz daha fazlasını yapar ve belki de birkaç işleç tanımlar.

Genel sabitleri tanımlamak hala yararlıdır. Örneğin

genel statik son int DAYS_IN_WEEK = 7;

Ancak yine de mümkünse enum'ları tercih edin . Örneğin

public enum Day {
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY, 
    THURSDAY, FRIDAY, SATURDAY 
}

To basit yapı sınıfları simüle o da yararlıdır. Her şekilde, her yerde herkese açıkken, bir alan ve ayarlayıcı oluşturmak için bir neden yok.

class Point
{
    public int x, y;
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

IDE'ler yaygınlaşmadan önce, tüm alanlarınızı herkese açık hale getirmek, kavramların prototiplerini / kanıtlarını hızlı bir şekilde oluşturmak için güçlü bir araçtır.

Günümüzde, fare tıklamasıyla bir alıcı / ayarlayıcı çifti oluşturabildiğinizde, bunları kullanmak için çok az mazeret vardır.

Bu sübjektiftir, ancak benim düşüncem, tüm kamu / özel kavramının modası geçmiş ve geriye dönük olmasıdır.

Python'da genel / özel yoktur; temelde her şey herkese açıktır. Çok fazla soruna yol açmadı.

Java'da, "genel" olarak işaretleme günahını önlemek için her alan için anlamsız alıcılar / ayarlayıcılar oluşturma eğilimindesiniz. (IMHO eğer bunu yaparken kendinizi herkese açık olarak işaretlemeniz gerekir).