Bu anahtar kelimelerin neden olduğu bir derleyici hatasının beni bir hatadan kurtaracağı bir durumda bulunmadım.
Uygulama yazarlarını hatalardan kurtarmak, kütüphane yazarlarının uygulamalarının hangi bölümlerini sürdürmeye karar verdiklerine izin verecek kadar fazla değildir.
Kütüphanem varsa
class C {
public void foo() { ... }
private void fooHelper() { /* lots of complex code */ }
}
fooUygulamasının yerini alabilir ve muhtemelen fooHelperradikal yollarla değişebilirim . fooHelperBelgelerimdeki tüm uyarılara rağmen bir grup insan kullanmaya karar verdiyse bunu yapamayabilirim.
privateKütüphane yazarlarının privateyıllardır bu iç detayları korumaya zorlanacakları korkusu olmadan kütüphaneleri yönetilebilir büyüklükteki yöntemlere (ve yardımcı sınıflara) ayırmalarına izin verir .
Derleyicinin bilgi gizlemesini zorunlu kılmasının önemi nedir?
Yan notta, Java'da privatederleyici tarafından değil, Java bayt kodu doğrulayıcısı tarafından zorlanır .
Yansıma bu mekanizmayı geçersiz kılabilir mi? Derleyicinin bilgi gizlemesini zorunlu kılmasının önemi nedir?
Java'da sadece yansıma bu mekanizmayı geçersiz kılamaz. privateJava'da iki tür vardır . Bunun türü, privatebir dış sınıfın başka bir dış sınıfın privatebayt kodu doğrulayıcısı tarafından denetlenen üyelerine erişmesini engellemez , aynı zamanda privatebir iç sınıf tarafından paket özel sentetik erişimci yöntemi ile kullanılan s
public class C {
private int i = 42;
public class B {
public void incr() { ++i; }
}
}
Sınıf B(gerçekten adlandırılmış C$B) kullandığından i, derleyici bayt kodu doğrulayıcıyı geçecek şekilde Berişime izin veren sentetik bir erişimci yöntemi oluşturur C.i. Ne yazık ki, ClassLoadera'dan bir sınıf oluşturmanıza izin byte[]verdiği için, 'kavanozunda mühürlenmemişse mümkün olan' paketinde Cyeni bir sınıf oluşturarak iç sınıflara maruz kalan ayrıcalıklara ulaşmak oldukça basittir .CC
Doğru privateuygulama, sınıf yükleyicileri, bayt kodu doğrulayıcısı ve ayrıcalıklara yansıtıcı erişimi engelleyebilecek güvenlik politikası arasında koordinasyon gerektirir.
Bir sınıfın gizli durumunun saldırıya uğramasını önlemek için kullanılabilir mi?
Evet. Her biri modüllerinin güvenlik özelliklerini korurken programcılar birlikte çalışabildiklerinde "güvenli ayrışma" mümkündür - Modülümün güvenlik özelliklerini ihlal etmemesi için başka bir kod modülünün yazarına güvenmek zorunda değilim.
Joe-E gibi Nesne Yetenekleri dilleri , güvenli ayrışmayı mümkün kılmak için bilgi gizleme ve diğer yöntemleri kullanır:
Joe-E, nesne yetenekleri disiplinine göre güvenli programlamayı desteklemek için tasarlanmış Java programlama dilinin bir alt kümesidir. Joe-E, güvenli sistemlerin inşasını kolaylaştırmanın yanı sıra Joe-E'de yerleşik sistemlerin güvenlik incelemelerini kolaylaştırmayı amaçlamaktadır.
Bu sayfadan bağlanan makale, privateuygulamanın güvenli ayrışmayı nasıl mümkün kıldığına dair bir örnek vermektedir .
Güvenli kapsülleme sağlanması.
Şekil 1. Yalnızca ek bir günlük kaydı özelliği.
public final class Log {
private final StringBuilder content;
public Log() {
content = new StringBuilder();
}
public void write(String s) {
content.append(s);
}
}
Bir kişinin salt eklenmiş bir günlük tesisini nasıl inşa edebileceğini gösteren Şekil 1'i düşünün. Programın geri kalanının Joe-E'de yazılması koşuluyla, bir kod inceleyici yalnızca günlük girişlerinin eklenebileceğini ve değiştirilemeyeceğini veya kaldırılamayacağını düşünebilir. Bu inceleme pratiktir, çünkü sadece Log
sınıfın denetlenmesini gerektirir ve başka bir kodun gözden geçirilmesini gerektirmez. Sonuç olarak, bu özelliğin doğrulanması, günlük kodu hakkında yalnızca yerel gerekçe gerektirir.