Ne zaman aynı nesneye iki referans istersiniz?

Java'da özel olarak, ancak diğer dillerde de olması muhtemeldir: aynı nesneye iki referans olması ne zaman yararlı olur?

Örnek:

Dog a = new Dog();
Dob b = a;

Bunun yararlı olacağı bir durum var mı? Neden atemsil edilen nesneyle etkileşim kurmak istediğinizde kullanmak için tercih edilen bir çözüm olur a?

Bir örnek, aynı nesnenin iki ayrı listede olmasını istediğiniz zamandır :

Dog myDog = new Dog();
List dogsWithRabies = new ArrayList();
List dogsThatCanPlayPiano = new ArrayList();

dogsWithRabies.add(myDog);
dogsThatCanPlayPiano.add(myDog);
// Now each List has a reference to the same dog

Başka bir kullanım, aynı nesnenin birkaç rol oynamasıdır :

Person p = new Person("Bruce Wayne");
Person batman = p;
Person ceoOfWayneIndustries = p;

Bu aslında şaşırtıcı derecede derin bir soru! Modern C ++ deneyimleri (ve Rust gibi modern C ++ dillerinden alınan diller) bunu çok sık istemediğinizi gösterir! Çoğu veri için tek veya benzersiz ("sahip olma") referansı istersiniz . Bu fikir aynı zamanda doğrusal tip sistemlerin ana nedenidir .

Bununla birlikte, o zaman bile, genellikle belleğe kısa bir süre erişmek için kullanılan ancak verilerin var olduğu sürenin önemli bir kısmını almayan kısa ömürlü "ödünç alınmış" referanslar istersiniz. Genellikle bir nesneyi farklı bir işleve bağımsız değişken olarak ilettiğinizde (Parametreler de değişkenlerdir!):

void encounter(Dog a) {
  hissAt(a);
}

void hissAt(Dog b) {
  // ...
}

Bir koşula bağlı olarak iki nesneden birini kullandığınızda, hangisini seçerseniz seçin, esas olarak aynı şeyi yaptığınızda daha az görülen bir durumdur:

Dog a, b;
Dog goodBoy = whoseAGoodBoy ? a : b;
feed(goodBoy);
walk(goodBoy);
pet(goodBoy);

Daha yaygın kullanımlara geri dönüyor, ancak yerel değişkenleri geride bırakarak alanlara dönüyoruz: Örneğin, GUI çerçevelerindeki widget'ların genellikle üst widget'ları vardır, bu nedenle on düğmeyi içeren büyük çerçevenizde en az on referans bulunur (artı biraz daha fazlası) dan onun ebeveyn ve) belki olay dinleyici vb. Her türlü nesne grafiği ve bazı nesne ağaçları (üst / kardeş referansları olanlar), her biri aynı nesneye karşılık gelen birden fazla nesneye sahiptir. Ve neredeyse her veri kümesi aslında bir grafiktir ;-)

Geçici değişkenler: aşağıdaki sözde kodu göz önünde bulundurun.

Object getMaximum(Collection objects) {
  Object max = null;
  for (Object candidate IN objects) {
    if ((max is null) OR (candidate > max)) {
      max = candidate;
    }
  }
  return max;
}

Değişkenler maxve candidateaynı nesneyi gösterebilir, ancak değişken ataması farklı kurallar kullanılarak ve farklı zamanlarda değişir.

Diğer cevapları desteklemek için, aynı yerden başlayarak bir veri yapısını farklı şekilde gezmek isteyebilirsiniz. Örneğin, a'nız varsa , aşağıdaki gibi bir şey kullanarak BinaryTree a = new BinaryTree(...); BinaryTree b = aağacın en solundaki ave en sağındaki yoldan geçebilirsiniz b:

while (!a.equals(null) && !b.equals(null)) {
    a = a.left();
    b = b.right();
}

Java'yı yazdığımdan beri bir süre geçti, bu yüzden kod doğru veya mantıklı olmayabilir. Daha çok sözde kod olarak al.

Bu yöntem, bağlamsız olarak kullanılabilen başka bir nesneye geri çağrılan birkaç nesneniz olduğunda harikadır.

Örneğin, sekmeli bir arabiriminiz varsa Tab1, Tab2 ve Tab3 olabilir. Ayrıca, kodunuzu basitleştirmek ve kullanıcı üzerinde hangi sekmenin üzerinde olduğunu anında anlamak zorunda kalmadan azaltmak için kullanıcının hangi sekmede olduğuna bakılmaksızın ortak bir değişken kullanmak isteyebilirsiniz.

Tab Tab1 = new Tab();
Tab Tab2 = new Tab();
Tab Tab3 = new Tab();
Tab CurrentTab = new Tab();

Ardından, onClick üzerindeki numaralandırılmış sekmelerin her birinde, Geçerli Sekmeyi bu Sekmeye başvuruda bulunacak şekilde değiştirebilirsiniz.

CurrentTab = Tab3;

Şimdi kodunuzda gerçekte hangi Sekmede olduğunuzu bilmenize gerek kalmadan cezasız bir şekilde "CurrentTab" ı arayabilirsiniz. CurrentTab'ın özelliklerini de güncelleyebilirsiniz; bunlar otomatik olarak başvurulan Sekmeye akar.

Yararlı olması için bilinmeyen bir " " referansı b olması gereken çok sayıda senaryo vardır a. Özellikle:

• Ne bzaman derleme zamanında neyi işaret bilmiyorum .
• Derleme zamanında biliniyor olsun ya da olmasın, bir koleksiyon üzerinde yineleme yapmanız gereken her zaman
• Sınırlı kapsamınız olduğunda

Örneğin:

Parametreler

public void DoSomething(Thing &t) {
}

^{t dış kapsamdaki bir değişkene yapılan başvurudur.}

Dönüş değerleri ve diğer koşullu değerler

Thing a = Thing.Get("a");
Thing b = Thing.Get("b");
Thing biggerThing = Thing.max(a, b);
Thing z = a.IsMoreZThan(b) ? a : b;

^{biggerThingve zher biri ya aya b. Hangisini derleme zamanında bilmiyoruz.}

Lambdas ve dönüş değerleri

Thing t = someCollection.FirstOrDefault(x => x.whatever > 123);

^{xbir parametredir (yukarıdaki örnek 1) ve tbir dönüş değeridir (yukarıdaki örnek 2)}

Koleksiyonları

indexByName.add(t.name, t);
process(indexByName["some name"]);

^{index["some name"]büyük ölçüde daha sofistike bir görünümdür b. Oluşturulan ve koleksiyona doldurulmuş bir nesnenin diğer adıdır.}

döngüler

foreach (Thing t in things) {
 /* `t` is a reference to a thing in a collection */
}

^{t bir yineleyici (önceki örnek) tarafından döndürülen bir öğeye (örnek 2) yapılan bir referanstır.}

Bu çok önemli bir nokta, ama IMHO anlaşılmaya değer.

Tüm OO dilleri her zaman referansların kopyalarını oluşturur ve hiçbir zaman bir nesneyi 'görünmez' olarak kopyalamaz. OO dilleri başka bir şekilde çalıştıysa, program yazmak çok daha zor olurdu . Örneğin, işlevler ve yöntemler hiçbir zaman bir nesneyi güncelleyemez. Java ve çoğu OO dilinin, önemli bir karmaşıklık olmadan kullanımı neredeyse imkansız olacaktır.

Programdaki bir nesnenin bir anlamı olması gerekir. Örneğin, gerçek fiziksel dünyada belirli bir şeyi temsil eder. Aynı şeye birçok referans olması genellikle mantıklıdır. Örneğin, ev adresim birçok kişiye ve kuruluşa verilebilir ve bu adres her zaman aynı fiziksel yeri ifade eder. İlk nokta, nesneler genellikle spesifik, gerçek veya somut bir şeyi temsil eder; ve böylece aynı şeyle ilgili birçok referansa sahip olabilmek son derece yararlıdır. Aksi takdirde program yazmak daha zor olurdu.

Geçmek her zaman abaşka bir işlev, örneğin çağrı için bir bağımsız değişken / parametre olarak
foo(Dog aDoggy);
veya bir yöntem uygulanır a, altta yatan program kodu aynı nesneye ikinci referans üretmek üzere, referans bir kopyasını çıkarır.

Ayrıca, kopyalanmış bir referansa sahip kod farklı bir iş parçacığındaysa, her ikisi de aynı nesneye erişmek için aynı anda kullanılabilir.

Bu nedenle, çoğu yararlı programda, aynı nesneye birden fazla referans olacaktır, çünkü çoğu OO programlama dilinin semantiği budur.

Şimdi, bunu düşünürsek, referansla geçmek birçok OO dilinde mevcut tek mekanizma olduğundan (C ++ her ikisini de destekler), 'doğru' varsayılan davranış olmasını bekleyebiliriz .

IMHO, referansları kullanmak için birkaç nedenden dolayı doğru varsayılan değerdir:

1. İki farklı yerde kullanılan bir nesnenin değerinin aynı olduğunu garanti eder. Bir nesneyi iki farklı veri yapısına (diziler, listeler vb.) Yerleştirdiğinizi ve onu değiştiren bir nesne üzerinde bazı işlemler yaptığınızı düşünün. Hata ayıklamak için bir kabus olabilir. Daha da önemlisi, bu ise , her iki veri yapıları aynı nesne veya program bir hata vardır.
2. Kodu birkaç işleve mutlu bir şekilde yeniden düzenleyebilir veya kodu birkaç işlevden biriyle birleştirebilirsiniz ve anlambilim değişmez. Dil referans anlambilimi sağlamıyorsa, kodu değiştirmek daha da karmaşık olacaktır.

Ayrıca bir verimlilik argümanı vardır; tüm nesnelerin kopyalarını oluşturmak bir referans kopyalamaktan daha az verimlidir. Ancak, bu noktayı kaçırdığını düşünüyorum. Aynı nesneye yapılan birden fazla referans daha mantıklıdır ve kullanımı daha kolaydır, çünkü gerçek fiziksel dünyanın anlambilimiyle eşleşirler.

Yani, IMHO, genellikle aynı nesneye birden fazla referans olması mantıklıdır. Bunun bir algoritma bağlamında mantıklı olmadığı olağandışı durumlarda, çoğu dil bir 'klon' veya derin kopya yapma yeteneği sağlar. Ancak bu varsayılan değildir.

Bunun varsayılan olmaması gerektiğini iddia eden insanlar , otomatik çöp toplama sağlamayan bir dil kullanıyorlar. Örneğin, eski moda C ++. Sorun şu ki, hala gerekli olabilecek nesneleri geri istememek için 'ölü' nesneleri toplamak için bir yol bulmaları gerekiyor; aynı nesneye birden fazla referans olması bunu zorlaştırır.

Bence, C ++ yeterince düşük maliyetli çöp toplama sahip olsaydı, tüm başvurulan nesneler çöp toplanır, o zaman itirazın çoğu gider. Referans semantiğin gerekli olmadığı bazı durumlar hala olacaktır . Ancak, tecrübelerime göre, bu durumları tanımlayabilen insanlar, genellikle uygun semantiği yine de seçebilirler.

Bir C ++ programında kod büyük miktarda çöp toplama veya hafifletmek için orada olduğuna dair bazı kanıtlar olduğuna inanıyorum. Ancak, bu tür bir 'altyapı' kodunun yazılması ve sürdürülmesi maliyet ekler; dili daha kolay veya daha sağlam hale getirmek için vardır. Bu nedenle, örneğin Go dili, C ++ 'nın bazı zayıflıklarını düzeltmeye odaklanarak tasarlanmıştır ve çöp toplama dışında bir seçeneği yoktur.

Bu elbette Java bağlamında önemsizdir. Kullanımı kolay olacak şekilde tasarlandı ve çöp toplama da yapıldı. Bu nedenle, birden çok referansa sahip olmak varsayılan semantiktir ve bunlara bir referans varken nesnelerin geri kazanılmaması açısından nispeten güvenlidir. Tabii ki bir veri yapısı tarafından tutulabilirler, çünkü program bir nesne ile gerçekten bittiğinde düzgün bir şekilde toplanmaz.

Öyleyse, sorunuza geri dönerek (biraz genelleme ile), ne zaman aynı nesneye birden fazla referans istersiniz? Aklıma gelen her durumda hemen hemen. Çoğu dil parametre geçiş mekanizmasının varsayılan semantikleridir. Bunun nedeni, gerçek dünyada var olan nesnelerin işlenmesinin varsayılan semantiğinin referans olarak olması gerektiğidir (çünkü gerçek nesneler oradadır).

Diğer herhangi bir anlambilimin ele alınması daha zor olurdu.

Dog a = new Dog("rover");  // initialise with name 
DogList dl = new DogList()
dl.add(a)
...
a.setOwner("Mr Been")

Ben "rover" dltarafından etkilenen setOwnerveya programlar yazmak, anlamak, hata ayıklama veya değiştirmek zor olsun gerektiğini öneririz . Bence çoğu programcı şaşkın veya dehşete düşer.

daha sonra köpek satılır:

soldDog = dl.lookupOwner("rover", "Mr Been")
soldDog.setOwner("Mr Mcgoo")

Bu tür bir işlem yaygın ve normaldir. Bu nedenle referans anlambilimi varsayılan değerdir, çünkü genellikle en mantıklıdır.

Özet: Aynı nesneye birden fazla referans olması her zaman mantıklıdır.

Tabii ki, bir başka senaryo daha ortaya çıkabilir:

Dog a = new Dog();
Dog b = a;

kodun bakımını yaptığınızda ve bfarklı bir köpek ya da farklı bir sınıf olarak kullandığınız zaman, ancak şimdi hizmet veriyor a.

Genel olarak, orta vadede, adoğrudan başvurmak için tüm kodu yeniden çalışmalısınız , ancak bu hemen gerçekleşmeyebilir.

Programınızın bir varlığı birden fazla noktada belleğe alma şansı olduğunda, muhtemelen farklı bileşenler kullandığından bunu yapmak istersiniz.

Kimlik Haritaları , iki veya daha fazla ayrı temsilden kaçınabilmemiz için kesin bir yerel varlık deposu sağladı. Aynı nesneyi iki kez temsil ettiğimizde, istemcimiz, nesnenin bir referansı diğer örnek olmadan önce durum değişikliklerine devam ederse bir eşzamanlılık sorununa neden olma riskiyle karşı karşıya kalır. Buradaki fikir, müşterimizin daima varlığımıza / nesnemize kesin referans verdiğinden emin olmak istiyoruz.

Bunu bir Sudoku çözücü yazarken kullandım. Satırları işlerken hücrenin sayısını bildiğimde, içeren sütunun sütunları işlerken hücrenin numarasını da bilmesini istiyorum. Dolayısıyla hem sütunlar hem de satırlar, çakışan Hücre nesnelerinin dizileridir. Tam olarak kabul edilen cevabın gösterdiği gibi.

Web uygulamalarında, Nesne İlişkisel Eşleştiricileri, aynı veritabanı nesnesine (en azından aynı iş parçacığı içinde) yapılan tüm başvuruların aynı şeyi göstermesi için tembel yüklemeyi kullanabilir.

Örneğin, iki tablonuz varsa:

Köpekler:

• id | owner_id | isim
• 1 | 1 | Bark Kent

sahipleri:

• id | isim
• 1 | ben mi
• 2 | sen

Aşağıdaki çağrılar yapılırsa ORM'nizin yapabileceği birkaç yaklaşım vardır:

dog = Dog.find(1)  // fetch1
owner = Owner.find(1) // fetch2
superdog = owner.dogs.first() // fetch3
superdog.name = "Superdog"
superdog.save! // write1
owner = dog.owner // fetch4
owner.name = "Mark"
owner.save! // write2
dog.owner = Owner.find(2)
dog.save! // write3

Naif stratejide, modellere ve ilgili referanslara yapılan tüm çağrılar ayrı nesneler alır. Dog.find(), Owner.find(), owner.dogsVe dog.ownerbir veritabanında sonuç onlar belleğe kaydedilir sonra ilk kez etrafında, çarptı. Ve bu yüzden:

• veritabanı en az 4 kez getirilir
• dog.owner, superdog.owner ile aynı değildir (ayrıca getirilir)
• dog.name, superdog.name ile aynı değildir
• köpek ve süper köpek her ikisi de aynı satıra yazmaya çalışır ve birbirlerinin sonuçlarının üzerine yazar: write3 write1'deki ad değişikliğini geri alır.

Referans olmadan, daha fazla getirme, daha fazla bellek kullanma ve önceki güncellemelerin üzerine yazma olasılığını tanıtma.

ORM'nizin köpekler tablosunun 1. satırına yapılan tüm referansların aynı şeye işaret etmesi gerektiğini bildiğini varsayalım. Sonra:

• Bellekte Owner.find (1) 'e karşılık gelen bir nesne olduğu için fetch4 ortadan kaldırılabilir. fetch3, sahibi tarafından sahip olunan başka köpekler olabileceğinden, ancak en azından bir dizin taramasına neden olur, ancak satır alımını tetiklemez.
• köpek ve süper köpek aynı nesneyi gösterir.
• dog.name ve superdog.name aynı nesneyi gösterir.
• dog.owner ve superdog.owner aynı nesneyi gösterir.
• write3, write1'deki değişikliğin üzerine yazmaz.

Başka bir deyişle, referansların kullanılması, veritabanındaki satır olan tek bir doğruluk noktasının (en azından bu iş parçacığının içinde) ilkesinin kodlanmasına yardımcı olur.