Özel alanlar neden örneğe özel değil, türe özeldir?

C # 'da (ve diğer birçok dilde) aynı türdeki diğer örneklerin özel alanlarına erişmek son derece meşrudur. Örneğin:

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if (anotherFoo.aBool) ...
    }
}

Gibi C # şartname (bölümler 3.5.1, 3.5.2) özel alanlara erişim bir tür değil, bir örneği olduğunu belirtmektedir. Bunu bir meslektaşımla tartışıyorum ve bunun böyle çalışmasının bir nedenini bulmaya çalışıyoruz (aynı örneğe erişimi kısıtlamak yerine).

Gelebileceğimiz en iyi argüman, sınıfın başka bir örnekle eşitliği belirlemek için özel alanlara erişmek isteyebileceği eşitlik kontrolleri içindir. Başka nedenleri var mı? Yoksa bunun böyle çalışması gerektiği anlamına gelen altın bir sebep mi yoksa tamamen imkansız mı?

Bu şekilde çalışmasının bir nedeni, erişim değiştiricilerinin derleme zamanında çalışmasıdır . Bu nedenle, belirli bir nesnenin aynı zamanda geçerli nesne olup olmadığını belirlemek kolay değildir. Örneğin, şu kodu göz önünde bulundurun:

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

Derleyici otherbunun gerçekten olduğunu anlayabilir thismi? Her durumda değil. Biri, bu sadece derlemek gerektiğini iddia edebilir, ancak bu , doğru örneğin özel bir örnek üyesinin erişilebilir olmadığı bir kod yoluna sahip olduğumuz anlamına gelir , ki bu daha da kötü.

Sadece tip seviyesini ziyade sorun uysal olduğunu nesne düzeyinde görünürlük sağlar gerektiren yanı sıra bu gibi görünen bir durum yapma gerektiğini çalışmak aslında işi.

DÜZENLE : Danilel Hilgarth'ın bu akıl yürütmenin geriye dönük olduğu görüşü hak ediyor. Dil tasarımcıları istedikleri dili oluşturabilirler ve derleyici yazarları buna uymak zorundadır. Bununla birlikte, dil tasarımcılarının derleyici yazarlarının işlerini yapmalarını kolaylaştırmak için bazı teşvikleri var. (Bu durumda, özel üyelerin yalnızcathis (dolaylı veya açık olarak) üzerinden erişilebileceğini iddia etmek yeterince kolaydır ).

Ancak, konunun olması gerekenden daha kafa karıştırıcı olduğuna inanıyorum. Çoğu kullanıcı (kendim dahil) yukarıdaki kod işe yaramazsa gereksiz yere sınırlayıcı bulacaktır: sonuçta, bu benim veri erişmeye çalışıyorum! Neden geçmek zorundayım this?

Kısacası, derleyici için "zor" olduğu için durumu abartmış olabileceğimi düşünüyorum. Gerçekte karşılaşmak istediğim şey, yukarıdaki durumun tasarımcıların çalışmak istediği bir durum gibi görünmesidir.

Çünkü C # ve benzeri dillerde kullanılan kapsülleme türünün amacı * bellekteki farklı nesneler değil, farklı kod parçalarının (C # ve Java sınıfları) karşılıklı bağımlılığını azaltmaktır.

Örneğin, başka bir sınıftaki bazı alanları kullanan bir sınıfta kod yazarsanız, bu sınıflar çok sıkı bir şekilde birleştirilir. Ancak, aynı sınıftan iki nesneye sahip olduğunuz kodla uğraşıyorsanız, ekstra bir bağımlılık yoktur. Bir sınıf her zaman kendisine bağlıdır.

Bununla birlikte, kapsülleme ile ilgili tüm bu teori, bir kişi özellikler oluşturduğunda (veya Java'da çiftleri aldığında / ayarladığında) ve tüm alanları doğrudan ortaya koyar koymaz başarısız olur, bu da sınıfları zaten alanlara erişiyormuş gibi bağlanmış hale getirir.

_{* Kapsülleme çeşitleri hakkında açıklama için Abel'ın mükemmel cevabına bakınız.}

Oldukça bazı cevaplar zaten bu ilginç konuya eklenmiştir, ancak, bu davranışın neden olduğu için gerçek sebebi bulamadım . Bir deneyeyim:

Geri dön

80'lerde Smalltalk ve 90'ların ortasında Java arasında bir yerde nesne yönlendirme kavramı olgunlaştı. Başlangıçta sadece OO için mevcut bir kavram olarak düşünülmeyen (ilk olarak 1978'de bahsedilmiştir) bilgi gizleme, bir sınıfın tüm verileri (alanları) özel olduğu için tüm yöntemler herkese açık olduğundan Smalltalk'ta tanıtıldı. 90'larda OO'nun birçok yeni gelişimi sırasında Bertrand Meyer, OO kavramlarının çoğunu dönüm noktası Nesneye Dayalı Yazılım İnşaatı'nda (OOSC) resmileştirmeye çalıştı. , o zamandan beri OO kavramları ve dil tasarımı üzerinde (neredeyse) kesin bir referans olarak kabul edilen .

Özel görünürlük durumunda

Meyer'e göre, bir yöntem bir dizi sınıf için kullanılabilir olmalıdır (sayfa 192-193). Bu açıkça çok yüksek bir bilgi gizleme ayrıntısı verir, A ve B sınıfı ve tüm torunları için aşağıdaki özellik mevcuttur:

feature {classA, classB}
   methodName

Durumunda privatekendisinden şu diyor ki: açıkça kendi sınıfına görünür olarak bir tür bildirmek olmadan, Erişemediğiniz nitelikli çağrısında özellik (yöntem / alanındaki) olduğunu. Yani xbir değişkense x.doSomething()izin verilmez. Tabii ki, sınıf içinde kalifiye olmayan erişime izin verilir.

Başka bir deyişle: aynı sınıfın bir örneğiyle erişime izin vermek için, söz konusu sınıfın yöntem erişimine açıkça izin vermeniz gerekir. Buna bazen özel-sınıf-sınıf-özel denir.

Programlama dillerinde örnek özel

Sınıf-özel bilgi gizleme yerine örnek-özel bilgi gizleme kullanan şu anda kullanılan en az iki dil biliyorum. Birincisi, Meyer tarafından tasarlanan ve OO'yu en uç noktalara taşıyan Eiffel. Diğeri Ruby, günümüzde çok daha yaygın bir dil. Ruby'de, "bu örneğe özel"private anlamına gelir .

Dil tasarımı için seçenekler

Derleyici için özel örneğe izin verilmesinin zor olduğu ileri sürülmüştür. Ben öyle düşünmüyorum, çünkü yöntemlere nitelikli çağrılara izin vermek veya vermemek nispeten basit. Özel bir yöntem doSomething()için izin verilirse vex.doSomething() , bir dil tasarımcısı özel yöntemler ve alanlar için yalnızca örnek örneği erişilebilirliğini etkili bir şekilde tanımlamıştır.

Teknik açıdan bakıldığında, şu ya da bu şekilde bir seçim yapmak için hiçbir neden yoktur (özellikle Eiffel.NET'in bunu IL ile yapabileceğini düşündüğünüzde, çoklu miras olsa bile, bu özelliği sağlamamanın doğal bir nedeni yoktur).

Tabii ki, bu bir zevk meselesi ve diğerlerinin de belirttiği gibi, özel yöntemlerin ve alanların sınıf düzeyinde görünürlüğü özelliği olmadan bazı yöntemlerin yazılması daha zor olabilir.

C # neden yalnızca sınıf kapsüllemeye izin verir, örnek kapsüllemeye izin vermez

İnternet kapsamalarına örnek kapsülleme (bazen bir dilin sınıf düzeyinde aksine erişim düzenleyicileri tanımladığı gerçeğine atıfta bulunmak için kullanılan bir terim) bakarsanız, kavram genellikle kaşlarını çatar. Bununla birlikte, bazı modern dillerin, en azından özel erişim değiştirici için örnek kapsülleme kullandığını düşünerek, bunun modern programlama dünyasında olabileceğini ve kullanılabileceğini düşünmenizi sağlar.

Ancak, C #, kuşkusuz dil tasarımı için C ++ ve Java'ya en sıkı baktı. Eiffel ve Modula-3 de resimde yer alırken, Eiffel'in birçok özelliği göz önüne alındığında (çoklu kalıtım) özel erişim değiştiricisine geldiğinde Java ve C ++ ile aynı yolu seçtiklerine inanıyorum.

Neden Eric Lippert, Krzysztof Cwalina, Anders Hejlsberg veya C # standardında çalışan herhangi bir kişiyi ele geçirmeye çalışmanız gerektiğini gerçekten bilmek istiyorsanız . Ne yazık ki, açıklamalı C # Programlama Dili'nde kesin bir not bulamadım .

Bu sadece benim düşüncem, ama pragmatik olarak, bir programcı bir sınıfın kaynağına erişebiliyorsa, sınıf örneğinin özel üyelerine erişirken onlara makul bir şekilde güvenebileceğinizi düşünüyorum. Neden bir programcıyı sollarında onları krallığa anahtarlar verdiğinizde sağ eline bağlarsınız?

Bunun nedeni eşitlik kontrolü, karşılaştırma, klonlama, operatör aşırı yüklemesi ... Örneğin karmaşık sayılara operatör + uygulamak çok zor olurdu.

Her şeyden önce, özel statik üyelere ne olurdu? Bunlara yalnızca statik yöntemlerle erişilebilir mi? Kesinlikle bunu istemezsiniz, çünkü o zaman kendinize erişemezsiniz const.

Açık sorunuzla ilgili StringBuilderolarak, kendi örneklerinin bağlantılı bir listesi olarak uygulanan a örneğini düşünün :

public class StringBuilder
{
    private string chunk;
    private StringBuilder nextChunk;
}

Kendi sınıfınızın diğer örneklerinin özel üyelerine erişemiyorsanız, aşağıdaki ToStringgibi uygulama yapmanız gerekir :

public override string ToString()
{
    return chunk + nextChunk.ToString();
}

Bu işe yarayacak, ama O (n ^ 2) - çok verimli değil. Aslında, bu muhtemelen StringBuilderilk etapta bir sınıf sahibi olma amacını yener . Eğer varsa olabilir kendi sınıfın diğer örneklerinin özel üyelerine erişmesi, Uygulayabileceğiniz ToStringuygun uzunlukta bir dize oluşturarak ve ardından dizede onun uygun yere her parçanın güvenli olmayan kopyasını yaparak:

public override string ToString()
{
    string ret = string.FastAllocateString(Length);
    StringBuilder next = this;

    unsafe
    {
        fixed (char *dest = ret)
            while (next != null)
            {
                fixed (char *src = next.chunk)
                    string.wstrcpy(dest, src, next.chunk.Length);
                next = next.nextChunk;
            }
    }
    return ret;
}

Bu uygulama O (n) 'dir ve bu onu çok hızlı yapar ve yalnızca sınıfınızın diğer örneklerinin özel üyelerine erişiminiz varsa mümkündür .

Bu birçok dilde mükemmel bir şekilde meşrudur (biri için C ++). Erişim değiştiriciler OOP'taki kapsülleme prensibinden gelir. Fikir dışarıya erişimi kısıtlamak , bu durumda dışarıdaki diğer sınıflardır. Örneğin, C # içindeki herhangi bir yuvalanmış sınıf, ebeveynlerinin özel üyelerine de erişebilir.

Bu bir dil tasarımcısı için bir tasarım seçimidir. Bu erişimin kısıtlanması, varlıkların izolasyonuna fazla katkıda bulunmadan çok yaygın bazı senaryoları son derece karmaşık hale getirebilir.

Burada benzer bir tartışma var

Verilerin her örneğe özel olduğu başka bir gizlilik düzeyi ekleyemememizin bir nedeni olduğunu düşünmüyorum. Aslında bu, dile güzel bir bütünlük hissi bile verebilir.

Ama gerçek uygulamada, gerçekten bu kadar yararlı olacağından şüpheliyim. Belirttiğiniz gibi, her zamanki özelliğimiz, eşitlik kontrolleri ve bir Türün birden çok örneğini içeren diğer birçok işlem için yararlıdır. Yine de, veri soyutlamasını koruma konusundaki görüşünüzü seviyorum, çünkü bu OOP'ta önemli bir nokta.

Her yerde, erişimi bu şekilde kısıtlama yeteneği sağlamak, OOP'ye eklemek için güzel bir özellik olabilir diye düşünüyorum. Gerçekten bu kadar faydalı mı? Hayır derim, çünkü bir sınıf kendi koduna güvenebilmelidir. Bu sınıf özel üyelere erişebilen tek şey olduğundan, başka bir sınıfın örneğiyle uğraşırken veri soyutlamasına ihtiyaç duymak için gerçek bir neden yoktur.

Elbette, kodunuzu her zaman özel örneklere uygulanmış gibi yazabilirsiniz . get/setVerilere erişmek / verileri değiştirmek için normal yöntemleri kullanın . Sınıf dahili değişikliklere tabi tutulabilirse, bu muhtemelen kodu daha yönetilebilir hale getirir.

Yukarıda verilen harika cevaplar. Bu sorunun bir kısmının, kendi içinde bir sınıfın somutlaştırılmasına ilk etapta bile izin verildiği gerçeğini ekleyeceğim. O zamandan beri özyinelemeli bir mantık için "for" döngüsünde, örneğin, özyinelemeyi sonlandırmak için mantığınız olduğu sürece bu tür bir hile kullanmak gerekir. Ancak, böyle bir döngüler oluşturmadan aynı sınıfı kendi içinde başlatmak veya geçirmek, yaygın olarak kabul edilen bir programlama paradigması olmasına rağmen, mantıksal olarak kendi tehlikelerini yaratır. Örneğin, bir C # Sınıfı varsayılan yapıcısında kendisinin bir kopyasını başlatabilir, ancak bu herhangi bir kuralı ihlal etmez veya nedensel döngüler oluşturmaz. Neden?

BTW .... aynı sorun "korunan" üyeler için de geçerlidir. :(

Programlama paradigmasını tam olarak kabul etmedim, çünkü çoğu programcının bu sorun yükselene ve insanları karıştırıncaya ve özel üyelere sahip olmanın tüm nedenine meydan okuyana kadar tam olarak kavramadığı bir dizi sorun ve riskle birlikte geliyor.

C # "garip ve tuhaf" yönü henüz iyi programlama deneyim ve beceri ile ilgisi yoktur, ama sadece hileler ve tuzakları bilmek ..... bir araba üzerinde çalışmak gibi bir nedenidir. Kuralların kırılması gerektiği iddiası bu, herhangi bir bilgisayar dili için çok kötü bir model.

Bana öyle geliyor ki, veriler aynı türden diğer örneklere özel olsaydı, artık aynı tür olmayacaktır. Diğer örneklerle aynı şekilde davranmıyor veya aynı davranmıyor gibi görünüyor. Davranış, bu özel dahili verilere dayanarak kolayca değiştirilebilir. Bence bu sadece karışıklık yaratacaktı.

Kısacası, kişisel olarak, bir temel sınıftan türetilen yazma sınıflarının, 'örnek başına özel verilere sahip olmak' ile tanımladığınız benzer işlevleri sunduğunu düşünüyorum. Bunun yerine, 'benzersiz' tip başına yeni bir sınıf tanımınız vardır.