Değişmez nesneler iyiyse, insanlar neden değişken nesneler oluşturmaya devam ediyor? [kapalı]

Değişmez nesneler¹ iyi, basit ve eşzamanlı programlamada faydalar sağlıyorsa, programcılar neden değişken nesneler oluşturmaya devam ediyor?

Java programlama konusunda dört yıllık bir deneyime sahibim ve gördüğüm gibi, insanların bir sınıf oluşturduktan sonra ilk yaptığı şey IDE'de alıcılar ve ayarlayıcılar üretmektir (bu nedenle değiştirilebilir hale getirmektir). Bir farkındalık eksikliği var mı yoksa çoğu senaryoda değişken nesneler kullanmaktan kurtulabilir miyiz?

^{Mm Değişmez nesne , oluşturulduktan sonra durumu değiştirilemeyen bir nesnedir.
² Değişken nesne , oluşturulduktan sonra değiştirilebilen bir nesnedir.}

Değişebilir ve değişmez nesnelerin her ikisinin de kendi kullanımları, artıları ve eksileri vardır.

Gerçekleştirilemeyen nesneler birçok durumda hayatı gerçekten kolaylaştırır. Özellikle nesnelerin kimliğinin olmadığı, kolaylıkla değiştirilebilecekleri değer türleri için geçerlidir. Ayrıca eşzamanlı programlamayı daha güvenli ve daha temiz hale getirebilirler (eşzamanlılık hatalarını bulmak en önemlisi zorlukla nihayetinde dişler arasında paylaşılan değişken durumdan kaynaklanır). Bununla birlikte, büyük ve / veya karmaşık nesneler için, her bir değişiklik için nesnenin yeni bir kopyasını oluşturmak çok maliyetli ve / veya sıkıcı olabilir. Farklı bir kimliğe sahip nesneler için, mevcut nesneleri değiştirmek, değiştirilmiş yeni bir kopyasını oluşturmaktan çok daha basit ve sezgiseldir.

Bir oyun karakteri düşünün. Oyunlarda hız önceliklidir, bu nedenle oyun karakterlerinizi değişken nesnelerle temsil etmek, oyunun her küçük değişiklik için oyun karakterinin yeni bir kopyasının üretildiği alternatif bir uygulamadan çok daha hızlı çalışmasını sağlar.

Dahası, gerçek dünya hakkındaki algımız kaçınılmaz olarak değişken nesnelere dayanmaktadır. Arabanızı benzin istasyonunda yakıtla doldurduğunuzda, onu tümüyle aynı nesne olarak algılarsınız (yani , durumu değişirken kimliği korunur ) - boş bir depoya sahip eski araba arka arkaya yenisiyle değiştirilmiş gibi değil araba örnekleri tanklarını yavaş yavaş gittikçe daha dolu hale getiriyor. Dolayısıyla, ne zaman bir gerçek dünya alanını bir programda modelleniyorsak, gerçek dünya varlıklarını temsil etmek için etkilenebilir modeli kullanarak etki alanı modelini uygulamak genellikle daha kolay ve kolaydır.

Bütün bu meşru sebeplerin yanı sıra, ne yazık ki, insanların değişken nesneler yaratmaya devam etmelerinin en muhtemel nedeni, zihinsel atalet, yani değişime dirençtir. Bugünün çoğu geliştiricisinin değişmezlikten (ve içerdiği paradigmadan, işlevsel programlamadan) etki alanı içinde "moda" haline gelmeden önce iyi eğitildiklerini ve ticaretimizin yeni araçları ve yöntemleri hakkındaki bilgilerini güncel tutmadıklarını unutmayın - Aslında, birçoğumuz insan olumlu yeni fikirlere ve süreçlere direnir . "Ben daha böyle programlama edilmiş nn yıl ve son aptal heveslere umurumda değil!"

Sanırım hepiniz en bariz cevabı kaçırdınız. Çoğu geliştirici değişken nesneler oluşturur çünkü değişkenlik zorunlu dillerde varsayılandır. Birçoğumuz zamanımızla ilgili olarak kodları varsayılan ayarlardan uzağa sürekli olarak değiştirmekten daha iyi şeyler yapıyoruz - daha doğru ya da değil. Ve değişmezlik başka bir yaklaşımdan daha derde deva değil. Bazı şeyleri kolaylaştırır ancak bazı cevapların daha önce işaret ettiği gibi diğerlerini daha da zorlaştırır.

1. Değişebilirlik için bir yer var. Etki alanına dayalı tasarım ilkeleri, neyin değişebilir olması ve neyin değişmemesi gerektiği konusunda sağlam bir anlayış sağlar. Eğer bunu düşünürseniz, bir nesneye yapılan her devlet değişikliğinin, onun imhasını ve onun yeniden birleştirilmesini ve onu referans alan her bir nesneye ihtiyaç duyduğu bir sistemi kavramanın pratik olmadığını fark edersiniz. Karmaşık sistemlerde bu, tüm sistemin nesne grafiğini tamamen silmeye ve yeniden oluşturmaya kolayca yol açabilir

2. Çoğu geliştirici, performans gereksinimlerinin eşzamanlılık (ya da bilgi sahibi tarafından evrensel olarak iyi uygulama olarak kabul edilen birçok uygulama) üzerinde yoğunlaşmaya ihtiyaç duydukları kadar önemli olduğu yerlerde hiçbir şey yapmaz.

3. İki yönlü ilişkilerde olduğu gibi, değişmez nesnelerle yapamayacağınız bazı şeyler var. Bir nesnede bir ilişkilendirme değeri belirledikten sonra, kimlik değişir. Böylece, yeni değeri diğer nesneye ayarladınız ve aynı zamanda değişiyor. Sorun, ilk nesnenin referansı artık geçerli değil çünkü nesneyi referansla temsil etmek üzere yeni bir örnek yaratıldı. Buna devam etmek sadece sonsuz gerileme ile sonuçlanacaktır. Sorunuzu okuduktan sonra küçük bir vaka incelemesi yaptım, işte nasıl görünüyor. Değişmezliği korurken bu tür işlevlere izin veren alternatif bir yaklaşımınız var mı?

       public class ImmutablePerson { 
   
        public ImmutablePerson(string name, ImmutableEventList eventsToAttend)
        {
             this.name = name;
             this.eventsToAttend = eventsToAttend;
        }
        private string name;
        private ImmutableEventList eventsToAttend;
   
        public string Name { get { return this.name; } }
   
        public ImmutablePerson RSVP(ImmutableEvent immutableEvent){
            // the person is RSVPing an event, thus mutating the state 
            // of the eventsToAttend.  so we need a new person with a reference
            // to the new Event
            ImmutableEvent newEvent = immutableEvent.OnRSVPReceived(this);
            ImmutableEventList newEvents = this.eventsToAttend.Add(newEvent));
            var newSelf = new ImmutablePerson(name, newEvents);
            return newSelf;
        }
       }
   
       public class ImmutableEvent { 
        public ImmutableEvent(DateTime when, ImmutablePersonList peopleAttending, ImmutablePersonList peopleNotAttending){
            this.when = when;     
            this.peopleAttending = peopleAttending;
            this.peopleNotAttending = peopleNotAttending;
        }
        private DateTime when; 
        private ImmutablePersonList peopleAttending;
        private ImmutablePersonList peopleNotAttending;
        public ImmutableEvent OnReschedule(DateTime when){
              return new ImmutableEvent(when,peopleAttending,peopleNotAttending);
        }
        //  notice that this will be an infinite loop, because everytime one counterpart
        //  of the bidirectional relationship is added, its containing object changes
        //  meaning it must re construct a different version of itself to 
        //  represent the mutated state, the other one must update its
        //  reference thereby obsoleting the reference of the first object to it, and 
        //  necessitating recursion
        public ImmutableEvent OnRSVPReceived(ImmutablePerson immutablePerson){
              if(this.peopleAttending.Contains(immutablePerson)) return this;
              ImmutablePersonList attending = this.peopleAttending.Add(immutablePerson);
              ImmutablePersonList notAttending = this.peopleNotAttending.Contains( immutablePerson ) 
                                   ? peopleNotAttending.Remove(immutablePerson)
                                   : peopleNotAttending;
              return new ImmutableEvent(when, attending, notAttending);
        }
       }
       public class ImmutablePersonList
       {
         private ImmutablePerson[] immutablePeople;
         public ImmutablePersonList(ImmutablePerson[] immutablePeople){
             this.immutablePeople = immutablePeople;
         }
         public ImmutablePersonList Add(ImmutablePerson newPerson){
             if(this.Contains(newPerson)) return this;
             ImmutablePerson[] newPeople = new ImmutablePerson[immutablePeople.Length];
             for(var i=0;i<immutablePeople.Length;i++)
                 newPeople[i] = this.immutablePeople[i];
             newPeople[immutablePeople.Length] = newPerson;
         }
         public ImmutablePersonList Remove(ImmutablePerson newPerson){
             if(immutablePeople.IndexOf(newPerson) != -1)
             ImmutablePerson[] newPeople = new ImmutablePerson[immutablePeople.Length-2];
             bool hasPassedRemoval = false;
             for(var i=0;i<immutablePeople.Length;i++)
             {
                hasPassedRemoval = hasPassedRemoval || immutablePeople[i] == newPerson;
                newPeople[i] = this.immutablePeople[hasPassedRemoval ? i + 1 : i];
             }
             return new ImmutablePersonList(newPeople);
         }
         public bool Contains(ImmutablePerson immutablePerson){ 
            return this.immutablePeople.IndexOf(immutablePerson) != -1;
         } 
       }
       public class ImmutableEventList
       {
         private ImmutableEvent[] immutableEvents;
         public ImmutableEventList(ImmutableEvent[] immutableEvents){
             this.immutableEvents = immutableEvents;
         }
         public ImmutableEventList Add(ImmutableEvent newEvent){
             if(this.Contains(newEvent)) return this;
             ImmutableEvent[] newEvents= new ImmutableEvent[immutableEvents.Length];
             for(var i=0;i<immutableEvents.Length;i++)
                 newEvents[i] = this.immutableEvents[i];
             newEvents[immutableEvents.Length] = newEvent;
         }
         public ImmutableEventList Remove(ImmutableEvent newEvent){
             if(immutableEvents.IndexOf(newEvent) != -1)
             ImmutableEvent[] newEvents = new ImmutableEvent[immutableEvents.Length-2];
             bool hasPassedRemoval = false;
             for(var i=0;i<immutablePeople.Length;i++)
             {
                hasPassedRemoval = hasPassedRemoval || immutableEvents[i] == newEvent;
                newEvents[i] = this.immutableEvents[hasPassedRemoval ? i + 1 : i];
             }
             return new ImmutableEventList(newPeople);
         }
         public bool Contains(ImmutableEvent immutableEvent){ 
            return this.immutableEvent.IndexOf(immutableEvent) != -1;
         } 
       }
   

"Tamamen işlevsel veri yapıları" okudum ve değişken nesneler kullanarak uygulanması çok daha kolay olan birkaç veri yapısının olduğunu fark etmemi sağladı.

İkili arama ağacını uygulamak için, her seferinde yeni bir ağaç döndürmeniz gerekir: Yeni ağacınız, değiştirilen her düğümün bir kopyasını çıkarmak zorunda kalacak (değiştirilmemiş dallar paylaşılır). Ekleme işleviniz için bu çok kötü değil, ama benim için, silme ve yeniden dengeleme üzerinde çalışmaya başladığımda işler hızla oldukça etkisizleşti.

Gerçekleştirmesi gereken bir diğer şey ise, yıllarca nesneye yönelik kod yazmaya devam edebilmeniz ve eğer kodunuz eşzamanlılık problemlerini ortaya çıkaracak şekilde çalıştırılmamışsa, paylaşılan değişken durumun ne kadar korkunç olabileceğini asla bilemeyeceğinizdir.

Benim bakış açıma göre bu farkındalık eksikliği. Bilinen diğer JVM dillerine (Scala, Clojure) bakarsanız, değişken nesneler kodda nadiren görülür ve bu yüzden insanlar bunları tek diş açmanın yeterli olmadığı senaryolarda kullanmaya başlar.

Halen Clojure öğreniyorum ve Scala'da (Java'da da 4 yıl +) biraz deneyimim var ve kodlama tarzınız durum bilinci nedeniyle değişiyor.

Bir önemli bir faktör göz ardı edilmiştir düşünüyorum: Java Fasulye nesneleri mutasyona ve (özellikle kaynağın göz önünde bulundurarak) belirli bir stil temeline dayanmaktadır epeyce kişi almaya görünüyor bir (hatta olarak bir) kanonik örnek nasıl tüm Java yazılmalıdır.

Kariyerim boyunca çalıştığım her kurumsal Java sistemi, Hazırda Beklet veya Java Kalıcılık API'sını (JPA) kullanır. Hazırda Bekletme ve JPA, esasen sisteminizin değiştirilebilir nesneler kullanmasını zorunlu kılar; çünkü bunların tüm önceliği, veri nesnelerinizde değişiklikleri algılamaları ve kaydetmeleridir. Pek çok proje için Hazırda Bekletme'nin getirdiği gelişme kolaylığı, değişmeyen nesnelerin faydalarından daha zorlayıcıdır.

Açıkçası, değişebilen nesneler Hazırda Bekletme durumundan çok daha uzun süredir vardır, bu nedenle Hazırda Bekletme büyük olasılıkla değiştirilebilen nesnelerin popülerliğinin orijinal nedeni değildir. Belki değişken nesnelerin popülaritesi, Hazırda Bekletme'nin gelişmesine izin verdi.

Fakat bugün birçok küçük programcı, Hazırda Bekletme veya başka bir ORM kullanarak kurumsal sistemlerde dişlerini keserse, muhtemelen değişken nesneler kullanma alışkanlığını edineceklerdir. Hazırda Bekletme gibi çerçeveler değiştirilebilir nesnelerin popülaritesini koruyor olabilir.

Henüz belirtilmeyen önemli bir noktası, bir nesnenin durumunu kesilebilir olması olan mümkün kılmasıdır olan kimlik durum değişmez olması kapsüller nesne.

Birçok program, doğal olarak değişken olan gerçek dünyadaki şeyleri modellemek için tasarlanmıştır. Saat 12: 51'de, bazı değişkenlerin AllTrucks, bir filonun o andaki (12:51) tüm kamyonlarında hangi yükün bulunduğunu gösteren bir veri yapısının kökü olan # 451 nesnesine bir başvuruda bulunduğunu varsayalım. BobsTruck# 24601 nesnesine bir referans almak için kullanılabilir, o anda Bob'un kamyonunda hangi yükün bulunduğunu gösteren bir nesneyi gösterir (12:51). Saat 12: 52'de, bazı kamyonlar (Bob's dahil) yüklenir ve boşaltılır ve veri yapıları güncellenir, böylece AllTrucksşimdi kargo 12: 52'den itibaren tüm kamyonlarda olduğunu gösteren bir veri yapısına referans olacaktır.

Ne olmalı BobsTruck?

Eğer her bir kamyon nesnesinin 'cargo' özelliği değişmez ise, o zaman # 24601 no.lu nesne, Bob'un kamyonunun saat 12: 51'de sahip olduğu durumu temsil eder. Eğer BobsTruck# 24601 nesne doğrudan başvuru tutan güncelleyen kod sürece, daha sonra AllTrucksda güncellemek olur BobsTruck, Bülent'in kamyonun mevcut durumunu temsil sona erecek. Ayrıca BobsTruck, bir değişebilir nesne biçiminde saklanmadıkça, güncelleme yapan kodun güncellenebilmesinin tek yolu, kodun AllTrucksbunu yapmak için açıkça programlanmış olmasından kaynaklanabileceğini unutmayın.

Eğer kişi BobsTrucktüm nesneleri değişmez tutarken Bob'un kamyonunu gözlemlemek için kullanabilmek isterse , herhangi bir zamanda veya belirli bir zamanda sahip BobsTruckolduğu değere göre AllTrucks, Bob'un kamyonunun durumunu verecek olan değiştirilemez bir fonksiyon olabilir . o zaman. Biri, biri yukarıda olduğu gibi, diğeri bir filo devletine ve yeni bir kamyon durumuna referans kabul eden ve yeni bir filo durumuna referans veren bir çift değişmez fonksiyona sahip olabilir. eskisi ile eşleşti, ancak Bob'un kamyonu yeni bir duruma sahip olacaktı.

Ne yazık ki, Bob'un kamyonunun durumuna erişmek istediği her seferinde böyle bir işlevi kullanmak zorunda kalmak, sinir bozucu ve hantal hale gelebilir. Alternatif bir yaklaşım, # 24601 nesnesinin her zaman ve sonsuza dek (birileri referans aldığı sürece) Bob'un kamyonunun şu anki durumunu temsil edeceğini söylemek olacaktır . Bob'un kamyonunun mevcut durumuna art arda erişmek isteyecek olan kod, her zaman zaman alan bir işlevi çalıştırmak zorunda kalmayacaktı, bu nesnenin Bob'un kamyonu olduğunu bulmak için bir kez sadece bir arama işlevi yapabilirdi ve sonra basitçe Bob'un kamyonunun şu anki durumunu görmek istediği zaman bu nesneye eriş.

İşlevsel yaklaşımın, tek dişli bir ortamda veya dişlerin çoğunlukla onu değiştirmek yerine yalnızca verileri gözlemleyeceği çok dişli bir ortamda avantajsız olmadığını unutmayın. İçinde bulunan nesne referansını kopyalayan herhangi bir gözlemci ipliğiAllTrucksve ardından temsil edilen kamyon durumlarını inceler, böylece referansı aldığı andan itibaren tüm kamyonların durumunu görür. Bir gözlemci iş parçacığı daha yeni verileri görmek istediğinde, başvuruyu yeniden alabilir. Öte yandan, tek bir değişmez nesne ile temsil edilen filonun tüm durumuna sahip olmak, aynı anda farklı kamyonları aynı anda güncelleyen iki ipliğin bulunmasını engelleyecektir, çünkü her bir iplik kendi cihazlarına bırakıldığında, dahil olan yeni bir "filo durumu" nesnesi üretecektir. kamyonunun yeni hali ve birbirlerinin eski halleri. Her bir iş parçacığı yalnızca değişmediyse CompareExchangegüncelleme yapmak AllTrucksiçin kullanırsa ve başarısız olmuşsa yanıtlarsa, doğruluk sağlanabilirCompareExchangedurum nesnesini yenilemek ve işlemi yeniden denemekle birlikte, birden fazla iş parçacığı eşzamanlı bir yazma işlemi yapmaya çalışırsa, performans genellikle tek bir iş parçacığında tüm yazı yazılmasından daha kötü olacaktır; ne kadar çok iş parçacığı bu tür eşzamanlı işlemleri denerse, performans o kadar kötü olur.

Tek tek kamyon nesneleri değişken ise ancak değişken kimlikleri varsa , çok iş parçacıklı senaryo daha temiz hale gelir. Herhangi bir kamyonda bir seferde yalnızca bir ipliğin çalışmasına izin verilebilir, ancak farklı kamyonlarda çalışan ipliğin parazitsiz yapılabilmesi mümkündür. Değişmez nesneler kullanırken bile böyle bir davranışı taklit etmenin yolları olsa da (örneğin, biri "AllTrucks" nesnelerini tanımlayabilir, böylelikle XXX'a ait kamyonun SSS'ye ayarlanması durumu basitçe bir nesnenin oluşturulmasını gerektirir. [XXX] 'a ait kamyonun durumu şimdi [SSS]; her şeyin durumu [AllTrucks’ın eski değeri] ". Böyle bir nesneyi oluşturmak, çekişme durumunda bile yeterince hızlı olacaktı.CompareExchangedöngü uzun sürmezdi. Öte yandan, böyle bir veri yapısının kullanılması, belirli bir kişinin kamyonunu bulmak için gereken süreyi büyük ölçüde arttıracaktır. Değişmez kimlikleri olan değişken nesneler kullanmak bu sorunu önler.

Doğru ya da yanlış yok, sadece ne istediğine bağlı. Bazı insanların bir paradigmayı diğerine, diğeri veri modelini tercih eden dilleri tercih etmesinin bir nedeni var. Bu sadece sizin tercihinize ve ne elde etmek istediğinize bağlı (ve her iki yaklaşımı da bir taraf veya diğer tarafın sert taraftarlarını yabancılaştırmadan rahatça kullanabilmek, bazı dillerin peşinde olduğu kutsal bir kâsedir).

Bence sorunuza cevap vermenin en hızlı ve en iyi yolu , Mutability ve Mutabilite ile Artıları ve Eksileri Eksenleri'ne yönelmenizdir .

Bu blog gönderisine bakın: http://www.yegor256.com/2014/06/09/objects-should-be-immutable.html . Değişmez nesnelerin neden değişkenden daha iyi olduklarını özetler. İşte argümanların kısa bir listesi:

• değişmez nesnelerin oluşturulması, test edilmesi ve kullanılması daha kolaydır
• gerçekten değişken nesneler her zaman iş parçacığı için güvenlidir
• geçici kaplin oluşumunu önlemeye yardımcı olurlar
• kullanımları yan etki içermez (savunma kopyası yoktur)
• kimlik değişebilirliği probleminden kaçınılır
• her zaman başarısızlık atomitesi var
• önbelleklemesi çok daha kolaydır

İnsanlar anlayabildiğim kadar değişken nesneler kullanıyorlar çünkü hala OOP'yi zorunlu prosedürel programlama ile karıştırıyorlar.

Java'da değişmez nesneler, nesnenin tüm özelliklerini alacak bir yapıcı gerektirir (veya yapıcı bunları başka argümanlardan veya varsayılanlardan oluşturur). Bu özellikler olmalıdır işaretlenecektir son .

Bununla ilgili çoğunlukla veri bağlama ile ilgili dört problem vardır :

1. Java Yapıcıları meta verilerini yansıtma argüman adlarını korumaz.
2. Java Yapıcıları (ve yöntemleri), adlandırılmış parametrelere (etiket olarak da adlandırılır) sahip değildir, bu nedenle birçok parametreyle karıştırır.
3. Bir başka değişmez nesne miras alırken, uygun bir kurucu sırası çağrılmalıdır. Bu, alanlardan birini nihai olmayan bırakma ve bırakma noktasında oldukça zor olabilir.
4. Çoğu ciltleme teknolojisi (Spring MVC Veri Bağlama, Hazırda Bekletme vb. Gibi) yalnızca bağımsız değişken oluşturucularla çalışır (bunun nedeni açıklamaların her zaman bulunmamasıydı).

@ConstructorPropertiesDeğişmeyen nesneyi oluşturmak için başka bir değiştirilebilir oluşturucu nesne (genellikle akıcı) gibi ek açıklamalar kullanarak ve bunları değiştirerek # 1 ve # 2 değerini azaltabilirsiniz .

Performans iyileştirme avantajlarından kimsenin bahsetmediğinden şaşırdım. Dile bağlı olarak, derleyici değişmez verilerle uğraşırken bir sürü optimizasyon yapabilir, çünkü verilerin asla değişmeyeceğini bilir. Her türlü malzeme atlanır ve bu da size olağanüstü performans avantajları sağlar.

Ayrıca değişmez nesneler neredeyse bütün devlet hata sınıfını ortadan kaldırır.

Olması gerektiği kadar büyük değil, çünkü zor, her dile uygulanmaz ve çoğu kişiye zorunlu kodlama öğretildi.

Ayrıca çoğu programcının kutusunda mutlu olduğunu ve çoğu zaman tam olarak anlamadıkları yeni fikirlere karşı dirençli olduklarını keşfettim. Genelde insanlar değişmekten hoşlanmaz.

Ayrıca, çoğu programcının durumunun kötü olduğunu da unutmayın. Vahşi doğada yapılan çoğu programlama korkunç ve bunun bir anlayış ve politika eksikliğinden kaynaklanıyor.

İnsanlar neden herhangi bir güçlü özellik kullanıyor? İnsanlar neden meta-programlama, tembellik veya dinamik yazmayı kullanıyor? Cevap kolaylıktır. Değişken devlet çok kolaydır. Güncellemesi o kadar kolaydır ve değişmez durumun çalışılabilir durumdan daha üretken olduğu proje büyüklüğü eşiği oldukça yüksektir, bu yüzden seçim bir süredir sizi ısırmaz.

Programlama dilleri bilgisayarlar tarafından yürütülecek şekilde tasarlanmıştır. Tüm önemli bilgisayar blokları - CPU, RAM, önbellek, diskler - değişkendir. Bunlar olmadığında (BIOS), onlar gerçekten değişken değildir ve siz de yeni değişmez nesneler yaratamazsınız.

Bu nedenle, değişmez nesnelerin üzerine inşa edilen herhangi bir programlama dili, uygulamasında bir temsil boşluğu çekmektedir. Ve C gibi erken diller için, bu büyük bir engeldi.

Değişken nesneler olmadan devletiniz olmaz. Kuşkusuz, bunu yönetebiliyorsanız ve bir nesneye birden fazla iş parçacığından referans verilme olasılığı varsa, bu iyi bir şeydir. Ancak program oldukça sıkıcı olacak. Bir çok yazılım, özellikle web sunucuları, veritabanları, işletim sistemleri, sistem kütüphaneleri, vb. Üzerinde değişkenliği ortadan kaldırarak değişken nesnelerin sorumluluğunu almaktan kaçınır. Pratik bir mesele olarak, programcıyı değişkenlik problemlerinden kurtarır ve web (ve diğer) uygun fiyatlı. Fakat değişkenlik hala orada.

Genel olarak, üç tür sınıfa sahipsiniz: dikkatlice korunmaları ve korunmaları gereken normal, iş parçacığı güvenli olmayan sınıflar; serbestçe kullanılabilen değişmez sınıflar; ve serbestçe kullanılabilen ancak aşırı dikkatle yazılması gereken değişken, güvenli dişliler. İlk tip, sorunlu olandır, en kötüsü üçüncü tip olduğu düşünülenlerdir . Tabii ki, ilk tip yazmak kolay olanlardır.

Genelde, dikkatlice izlemem gereken birçok normal, değişken sınıfla karşılaşıyorum. Çok iş parçacıklı bir durumda, gerekli senkronizasyon, ölümcül bir kucaklaşmadan kaçınabildiğimde bile her şeyi yavaşlatıyor. Bu yüzden, genellikle değişebilir sınıfın değişmez kopyalarını yapıyorum ve bunları kullanabilecek kişilere teslim ediyorum. Orignal mutasyonların her seferinde yeni bir değişmez kopya gereklidir, bu yüzden zaman zaman orjinalinin yüzlerce kopyasına sahip olduğumu hayal ediyorum. Ben tamamen Çöp Toplama'ya bağımlıyım.

Özetle, çoklu iş parçacığı kullanmıyorsanız, iş parçacığı güvenli olmayan değiştirilebilir nesneler iyidir. (Ancak çok iş parçacığı her yere yayılıyor - dikkatli olun!) Yerel değişkenlerle kısıtlarsanız veya bunları titizlikle senkronize ederseniz, güvenle kullanılabilirler. Bunları başkalarının kanıtlanmış kodunu (DB'ler, sistem çağrıları, vb.) Kullanarak önleyebilirsiniz. Eğer varsa olabilir değişmez bir sınıfını kullanın Bunu yapmak. Ve bence , genel olarak insanlar ya çok iş parçacığı sorunlarından habersizler ya da (duyusal olarak) korkutuyorlar ve çok iş görmekten kaçınmak için her türlü hileyi kullanıyorlar (veya bunun yerine başka bir yere sorumluluk yüklüyorlar).

Bir PS olarak, Java alıcılarının ve ayarlayıcılarının kullanımdan çıktığını hissediyorum. Kontrol bu dışarı.

Birçok insanın iyi cevapları vardı, bu yüzden dokunduğun bir şeye dikkat çekmek istedim, çok gözlemciydi ve son derece doğru ve burada başka bir yerde bahsedilmedi.

Ayarlayıcıları ve alıcıları otomatik olarak oluşturmak korkunç, korkunç bir fikirdir ancak yine de prosedürel düşünenlerin OO'yu zihniyetlerine zorlamaya çalıştıkları ilk yoldur. Ayarlayıcılar ve alıcılar, özelliklerle birlikte, yalnızca gereksinim duyduğunuzda her varsayılan ayar için değil

Aslında, düzenli olarak alıcılara ihtiyaç duymanıza rağmen, ayarlayıcıların veya yazılabilir özelliklerin kodunuzda var olması gereken tek yol, nesnenin tamamen başlatılmasından sonra kilitlendikleri bir oluşturucu paternidir.

Birçok sınıf yaratıldıktan sonra değişkendir, sadece özelliklerinin doğrudan manipüle edilmemesi gerekir - bunun yerine özelliklerini gerçek iş mantığına sahip yöntem çağrıları yoluyla manipüle etmesi istenir (Evet, bir ayarlayıcı hemen hemen aynıdır) doğrudan özellik manipüle gibi şey)

Şimdi bu gerçekten "Scripting" stil kodu / dilleri için geçerli değil, başkaları için yarattığınız kod için ve başkalarının yıllar içinde tekrar tekrar okumasını beklemeniz için geçerli değildir. Son zamanlarda bu ayrımı yapmaya başlamam gerekti, çünkü Groovy ile uğraşmaktan çok zevk alıyorum ve hedeflerde büyük bir fark var.

Değiştirilebilir nesneler, nesneyi başlattıktan sonra katları değerlerini ayarlamanız gerektiğinde kullanılır.

Örneğin altı parametreli bir kurucunuz olmamalıdır. Bunun yerine nesneyi setter yöntemleriyle değiştirirsiniz.

Buna örnek olarak font, oryantasyon vb. Ayarlayıcıları olan bir Report nesnesidir.

Kısacası: değişkenler, bir nesneye ayarlanacak çok fazla devletiniz olduğunda ve çok uzun bir kurucu imzanın olması pratik olmazsa kullanışlıdır.

EDIT: Oluşturucu deseni, nesnenin bütün durumunu oluşturmak için kullanılabilir.

Değişken nesnelerin kullanılmasının zorunlu düşünceden kaynaklandığını düşünüyorum: değişken değişkenlerin içeriğini adım adım değiştirerek bir sonucu hesaplarsınız (yan etki ile hesaplama).

İşlevsel olarak düşünürseniz, değişmez duruma sahip olmak ve işlevleri uygulayarak ve eskilerinden yeni değerler yaratarak sistemin sonraki hallerini temsil etmek istersiniz.

İşlevsel yaklaşım daha temiz ve daha güçlü olabilir, ancak kopyalama nedeniyle çok verimsiz olabilir, böylece artımlı olarak değiştirdiğiniz paylaşılan veri yapısına geri dönmek istiyorsunuz.

En makul bulduğum takas şu: Değişmez nesnelerle başlayın ve uygulamanız yeterince hızlı değilse değiştirilebilir nesnelere geçin. Bu bakış açısına göre, değişken nesnelerin sistematik olarak baştan kullanılması bir tür erken optimizasyon olarak düşünülebilir: en baştan daha verimli (ancak bunu anlamak ve hata ayıklamak için daha zor) bir uygulamayı seçersiniz.

Peki, neden birçok programcı değişken nesneler kullanıyor? IMHO iki nedenden dolayı:

1. Birçok programcı, zorunlu (usule dayalı veya usule dayalı) bir paradigma kullanarak nasıl programlanacağını öğrenmiştir, bu nedenle değişkenlik, hesaplamanın tanımlanmasında temel yaklaşımdır, yani ne zaman ve nasıl kullanılacağını bilmedikleri için, aşina olmadıklarını bilmezler.
2. Pek çok programcı, performans konusunda çok erken endişe duymaktadır; ancak, öncelikle işlevsel olarak doğru bir program yazmaya odaklanmak ve ardından darboğazları bulmaya ve en iyi duruma getirmeye çalışmak daha etkilidir.

Java hakkında soru sorduğunu biliyorum, ama objektif-c'de her zaman değişmez vs değişmez kullanıyorum. Değişmez bir dizi NSArray ve değişken bir dizi NSMutableArray vardır. Bunlar, kesin kullanımı ele almak için özel olarak optimize edilmiş bir şekilde yazılmış iki farklı sınıftır. Bir dizi oluşturmanız ve içeriğini asla değiştirmem gerekmiyorsa, daha küçük bir nesne olan NSArray'i kullanırdım ve değişken bir diziye kıyasla daha hızlı bir şekilde yapardım.

Dolayısıyla, değişmeyen bir Person nesnesi oluşturursanız, o zaman sadece bir kurucu ve alıcılara ihtiyacınız olur, bu nedenle nesne daha küçük olacak ve daha az bellek kullanacaktır, bu da programınızı gerçekten daha hızlı hale getirecektir. Oluşturulduktan sonra nesneyi değiştirmeniz gerekirse, değişken bir Person nesnesi daha iyi olacaktır, böylece yeni bir nesne oluşturmak yerine değerleri değiştirebilir.

Yani: Nesne ile ne yapmayı planladığınıza bağlı olarak, değişken veya değişken olan değişkenleri seçmek, performans söz konusu olduğunda büyük bir fark yaratabilir.

Burada verilen diğer birçok nedene ek olarak, bir sorun, ana dillerin değişmezliği iyi desteklememesidir. En azından, const veya final gibi ek anahtar kelimeler eklemek zorunda olduğunuz ve çok sayıda argüman veya kod uzun oluşturucu desenleri olan okunaksız yapıcılar kullanmanız gerektiği için değişmezlik için ceza alırsınız.

Akılda kalıcılık ile yapılan dillerde bu çok daha kolay. İsteğe bağlı olarak adlandırılmış bağımsız değişkenlerle bir sınıf Kişisi tanımlamak ve değiştirilmiş bir niteliğe sahip bir kopya oluşturmak için bu Scala kod parçasını göz önünde bulundurun:

case class Person(id: String, firstName: String, lastName: String)

val joe = Person("123", "Joe", "Doe")
val spouse = Person(id = "124", firstName = "Mary", lastName = "Moe")
val joeMarried = joe.copy(lastName = "Doe-Moe")

Dolayısıyla, geliştiricilerin değişmezliği benimsemelerini istiyorsanız, bu neden daha modern bir programlama diline geçmeyi düşünebileceğinizin sebeplerinden biridir.

Değişmez, değeri değiştiremeyeceğiniz anlamına gelir ve değişken, ilkel ve nesneler açısından düşünüyorsanız, değeri değiştirebileceğiniz anlamına gelir. Nesneler, Java'daki ilkellerden farklıdır, çünkü bunlar türlerde yerleşiktir. İlkel karakterler int, boolean ve void gibi tiplerde üretilirler.

Bir çok insan, ilkel bir değiştiriciye sahip olan ilkellerin ve nesnelerin değişkenlerinin önlerinde değişmez olduğunu düşünüyor, ancak bu tam olarak doğru değil. Yani final neredeyse değişkenler için değişmez anlamına gelmez. Bir kod örneği için bu bağlantıya göz atın :

public abstract class FinalBase {

    private final int variable; // Unset

    /* if final really means immutable than
     * I shouldn't be able to set the variable
     * but I can.
     */
    public FinalBase(int variable) { 
        this.variable = variable;
    }

    public int getVariable() {
        return variable;
    }

    public abstract void method();
}

// This is not fully necessary for this example
// but helps you see how to set the final value 
// in a sub class.
public class FinalSubclass extends FinalBase {

    public FinalSubclass(int variable) {
        super(variable);
    }

    @Override
    public void method() {
        System.out.println( getVariable() );
    }

    @Override
    public int getVariable() {

        return super.getVariable();
    }

    public static void main(String[] args) {
        FinalSubclass subclass = new FinalSubclass(10);
        subclass.method();
    }
}

Arayüz pencereleri gibi "gerçek hayat" değişken "nesneleri" modellemek için iyi bir neden olacağını düşünüyorum. Birisi bazı kargo liman operasyonlarını kontrol etmek için bir yazılım yazmayı denediğinde OOP'un icat edildiğini okuduğumu belli belirsiz hatırlıyorum.

Java, çoğu durumda değişken nesneleri zorunlu kılar, örneğin, bir ziyaretçide veya çalıştırılabilir bir şeyi saymak veya iade etmek istediğinizde, çoklu kullanım olmadan bile, son değişkenlere ihtiyacınız vardır.