Bir veri nesnesi türünün değişmeyecek şekilde tasarlanıp tasarlanmayacağına nasıl karar verilir?

Değişmez "kalıbı" güçlü olduğu için seviyorum ve geçmişte değişmez veri türlerine sahip sistemleri tasarlamayı yararlı buldum (bazıları, hatta hepsi). Sık sık yaptığım zaman kendimi daha az hata yazarken buluyorum ve hata ayıklama çok daha kolay.

Ancak, genel olarak akranlarım değişmez olmaktan uzak duruyor. Hiç deneyimsiz değiller (ondan uzak), ancak veri nesnelerini klasik yoldan yazıyorlar - özel üyeler bir alıcı ve her üye için belirleyici. O zaman genellikle kurucuları hiçbir argüman almazlar ya da sadece kolaylık sağlamak için bazı argümanlar alırlar. Sıklıkla, bir nesne oluşturmak şöyle görünür:

Foo a = new Foo();
a.setProperty1("asdf");
a.setProperty2("bcde");

Belki bunu her yerde yaparlar. Belki ne kadar önemli olursa olsun, bu iki ipi alan bir kurucu bile tanımlamazlar. Belki de daha sonra bu tellerin değerini değiştirmezler ve asla gerek duymazlar. Açıkçası, eğer bu şeyler doğruysa, nesne değişmez olarak tasarlanmalı, değil mi? (yapıcı iki özelliği alır, ayarlayıcı yok).

Bir nesne türünün değişmez olarak tasarlanıp tasarlanmayacağına nasıl karar veriyorsunuz? Yargılamak için iyi bir kriter seti var mı?

Şu anda kendi projemdeki birkaç veri türünün değişmez hale getirilip değiştirilmeyeceğini tartışıyorum, ancak bunu akranlarıma doğrulamak zorunda kalacağım ve türlerdeki veriler (ÇOK nadiren) değişebilir - tabii ki istediğiniz zaman değiştirebilirsiniz değişmez yolu (değiştirmek istediğinizler hariç eski nesneden özellikleri kopyalayarak, yeni bir tane oluşturun). Fakat bunun sadece ortaya çıkan değişmezlere olan aşkım olup olmadığından veya onlardan yararlanma / fayda için gerçek bir ihtiyaç olup olmadığından emin değilim.

Geriye yaklaşıyor gibisin. Biri varsayılan olarak değişmez olmalıdır. Bir nesneyi yalnızca, kesinlikle değişmez bir nesne olarak çalışmasını sağlayamazsanız / yapamazsanız değiştirilebilir hale getirin.

Değişmez nesnelerin birincil yararı iplik güvenliğini garanti etmektir. Birden fazla çekirdek ve ipliğin norm olduğu bir dünyada, bu fayda çok önemli hale geldi.

Ancak değişken nesneler kullanmak çok uygundur. İyi performans sergiliyorlar ve onları ayrı dişlilerden değiştiremediğiniz sürece ve ne yaptığınızı iyi anlıyorsanız, oldukça güvenilirler.

Bir nesnenin değişmez olup olmadığına karar vermenin iki ana yolu vardır.

a) Nesnenin niteliğine göre

Bu durumları yakalamak kolaydır çünkü bu nesnelerin yapıldıktan sonra değişmeyeceğini biliyoruz. Örneğin, eğer bir RequestHistoryvarlığınız varsa ve doğaya göre varlıklar bir kez kurulduktan sonra değişmezler. Bu nesneler değişmez sınıflar olarak tasarlanan düz ileri olabilir. İstek Nesnesi'nin durumunu değiştirebildiği ve zaman içinde kime atandığı gibi saklanabilir olduğunu, ancak istek geçmişinin değişmediğini unutmayın. Örneğin, geçen hafta teslim edildikten sonra atanmış duruma geçtiğinde oluşturulan bir tarih unsuru vardı VE bu tarih hakkı asla değişemez. Yani bu klasik değişmez bir durum.

b) Tasarım seçimine dayanarak, dış faktörler

Bu java.lang.String örneğine benzer. Dizeler aslında zaman içinde değişebilir ancak tasarım gereği, önbellekleme / dize havuzu / eşzamanlılık faktörleri nedeniyle onu değişmez hale getirdiler. Benzer şekilde, önbellekleme / eşzamanlılık vb. Uygulamada önbellekleme / eşzamanlılık ve buna bağlı performans hayati önem taşıyorsa, nesnenin değişmez hale getirilmesinde iyi bir rol oynayabilir. Ancak bu karar, tüm etkileri açıkladıktan sonra çok dikkatli bir şekilde alınmalıdır.

Değiştirilemeyen cisimlerin temel avantajı, yabani ot yabani ot desenine maruz kalmamasıdır. Nesne, yaşam süresi boyunca herhangi bir değişiklik yapmaz ve kodlama ve bakımı çok daha kolay hale getirir.

Şu anda kendi projemdeki birkaç veri türünün değişmez hale getirilip değiştirilmeyeceğini tartışıyorum, ancak bunu akranlarıma doğrulamak zorunda kalacağım ve türlerdeki veriler (ÇOK nadiren) değişebilir - tabii ki istediğiniz zaman değiştirebilirsiniz değişmez yolu (değiştirmek istediğinizler hariç eski nesneden özellikleri kopyalayarak, yeni bir tane oluşturun).

Bir programın durumunu en aza indirgemek oldukça faydalıdır.

Onlara, bir istemci sınıfından geçici depolama için sınıflarınızdan birinde değişken bir değer türü kullanmak isteyip istemediklerini sorun.

Evet derlerse nedenini sor? Değişken devlet böyle bir senaryoda yer almaz. Onları gerçekte ait oldukları durumu oluşturmaya zorlamak ve veri türlerinizin durum bilgisini olabildiğince açık hale getirmek mükemmel sebeplerdir.

Cevap biraz dile bağlı. Kodunuz Java gibi görünüyor, bu sorunun mümkün olduğu kadar zor olduğu bir yer. Java'da nesneler yalnızca referans olarak iletilebilir ve klon tamamen bozulur.

Basit bir cevap yok, ancak kesin olarak küçük ish değer nesnelerini değiştirilemez hale getirmek istiyorsunuz. Java, Dizeleri değiştirilemez hale getirdi, ancak yanlış Tarih ve Takvim değiştirilebildi.

Bu yüzden kesinlikle küçük değerli nesneleri değiştirilemez yapın ve bir kopya kurucu uygulayın. Cloneable'i tamamen unutun, o kadar kötü tasarlandı ki işe yaramaz.

Daha büyük değerli nesneler için, bunları değiştirilemez hale getirmek uygun değilse, kopyalanmaları kolaylaşır.

Belki de daha sonra bu tellerin değerini değiştirmezler ve asla gerek duymazlar. Açıkçası, eğer bu şeyler doğruysa, nesne değişmez olarak tasarlanmalı, değil mi?

Biraz sezgisel olarak, daha sonra hiçbir zaman dizeleri değiştirmeye ihtiyaç duymamak, nesnelerin değişmez olup olmadığının önemli olmadığı konusunda oldukça iyi bir argümandır. Programcı zaten derleyicinin onu uygulayıp uygulamadığı konusunda onları etkin bir şekilde değişmez olarak görüyor.

Taklit edilebilirlik genellikle zarar vermez, ancak her zaman da yardımcı olmuyor. Nesnenizin değişmezlikten yararlanıp fayda sağlayamayacağını anlamanın kolay yolu, değiştirmeden önce nesnenin bir kopyasını almanız veya bir muteks edinmeniz gerekip gerekmediğidir . Asla değişmezse, değişmezlik size gerçekten bir şey almaz ve bazen işleri daha karmaşık hale getirir.

Sen yapmak geçersiz bir durumda bir nesne inşa riski hakkında iyi bir nokta var, ama bu gerçekten değişmezlik ayrı bir mesele. Bir nesne değişken her ikisi de olabilir ve her zaman inşaat sonrası geçerli bir durumda.

Bu kuralın istisnası, Java'nın ne adlandırılmış parametreleri ne de varsayılan parametreleri desteklememesi nedeniyle, bazen yalnızca aşırı yüklenmiş yapıcıları kullanarak geçerli bir nesneyi garanti eden bir sınıf tasarlamanın yanlış gelmesidir. İki özellikli davada çok fazla bir şey yok, ancak o zaman kodun diğer bölümlerinde benzer fakat daha büyük sınıflara sık sık rastlanırsa tutarlılık için söylenecek bir şey var.

Bunun aşırı derecede düşük bir görüşüne sahip olabilirim ve muhtemelen her şeyi değişmez kılmak için bu kadar basit olmayan C ve C ++ kullanıyorum, ancak daha fazla yazmak için değişmez veri türlerini bir optimizasyon detayı olarak görüyorum. yan etkilerden yoksun verimli işlevler ve geri alma sistemleri ve tahribatsız düzenleme gibi özellikleri kolayca sağlayabilirsiniz.

Örneğin, bu son derece pahalı olabilir:

/// @return A new mesh whose vertices have been transformed
/// by the specified transformation matrix.
Mesh transform(Mesh mesh, Matrix4f matrix);

... eğer Meshkalıcı bir veri yapısı olarak tasarlanmamışsa ve bunun yerine tam olarak kopyalanması gereken (bazı senaryolarda gigabaytlara yayılabilen) tam olarak kopyalanması gereken bir veri türü idi. bunun bir kısmı (yalnızca senaryo konumlarını değiştirdiğimiz yukarıdaki senaryoda olduğu gibi).

Bu yüzden değişmezliğe ulaşıp, değiştirilmemiş kısımlarının sığ kopyalanmasına ve referans sayımına izin verecek şekilde veri yapısını tasarladığımda, yukarıdaki fonksiyonun hala tüm ağları derinlemesine kopyalamak zorunda kalmadan makul bir şekilde etkin olmasına izin vermek için yazdırabilirim. iş parçacığı güvenliği, istisnai güvenlik, işlemi geri alma kabiliyeti, tahribatsız uygulama vb.

Benim durumumda her şeyi değişmez kılmak çok pahalı (en azından verimlilik açısından), bu yüzden tam olarak derin kopyalamak için çok pahalı olan sınıflar için biriktiriyorum. Bu sınıflar genellikle kafesler ve görüntüler gibi ağır veri yapılarıdır ve ben genellikle değişimleri yeni bir değişmez kopya almak için bir "oluşturucu" nesnesi aracılığıyla onlara ifade etmek için değişken bir arayüz kullanırım. Ve bunu sınıfın merkezi seviyesinde değişmez garantiler almaya çalışacak kadar yapmıyorum. Sınıfı yan etkileri olmayan fonksiyonlarda kullanmama yardımcı oluyor. MeshYukarıda değişmez hale getirme arzum doğrudan ağları değişmez yapmak değil, aynı zamanda bir ağ girişi yapan ve karşılığında büyük bir bellek ve hesaplama maliyeti ödemeden yenisini çıkaran yan etkilerden arındırılmış fonksiyonların kolayca yazılmasını sağlamaktır.

Sonuç olarak, kod kodumun tamamında yalnızca 4 değişmez veri türüne sahibim ve hepsi ağır veri yapılarıdır, ancak yan etkileri olmayan işlevleri yazmama yardımcı olmak için bunları yoğun bir şekilde kullanıyorum. Bu cevap, benim gibi, her şeyi değiştirilemez hale getirmeyi kolaylaştıran bir dilde çalışıyorsanız uygulanabilir. Bu durumda, odağınızı işlevlerinizin çoğunun yan etkilerden kaçınmasını sağlamaya yönlendirebilirsiniz; bu noktada, seçili veri yapılarını değişmez hale getirmek isteyebilirsiniz, PDS türleri, pahalı tam kopyaları önlemek için bir optimizasyon detayı olarak. Bu arada böyle bir fonksiyona sahip olduğumda:

/// @return The v1 * v2.
Vector3f vec_mul(Vector3f v1, Vector3f v2);

... o zaman tam olarak kopyalayacak kadar ucuz oldukları için vektörleri değişmez hale getirme eğilimim yok. Vektörleri, değiştirilmemiş parçaları kopyalayabilen sığ yapılara dönüştürerek burada elde edilecek performans avantajı yoktur. Bu tür maliyetler, sadece vektörün tamamını kopyalamanın maliyetinden ağır basacaktır.

Foo a = new Foo();
a.setProperty1("asdf");
a.setProperty2("bcde");

Foo'nun sadece iki özelliği varsa, iki argüman alan bir kurucu yazmak kolaydır. Ancak başka bir özellik eklediğinizi varsayalım. O zaman başka bir kurucu eklemelisin:

public Foo(String a, String b, SomethingElse c)

Bu noktada, hala yönetilebilir. Ama ya 10 özellik varsa? 10 argüman içeren bir kurucu istemiyorsunuz. Oluşturucu desenini örnekler oluşturmak için kullanabilirsiniz, ancak bu karmaşıklık katar. Bu zamana kadar, "neden normal insanlar gibi tüm mülkler için belirleyiciler eklemedim" diye düşüneceksiniz?