Strateji tasarım modeli ile Devlet tasarım modeli arasındaki farklar nelerdir? Web'de birkaç makaleden geçiyordum, ancak farkı net bir şekilde ortaya koyamadım.

Birisi layman'ın terimlerindeki farkı açıklayabilir mi?

Dürüst olmak gerekirse, iki model pratikte oldukça benzerdir ve aralarındaki tanımlayıcı fark, kime sorduğunuza bağlı olarak değişir. Bazı popüler seçenekler şunlardır:

• Devletler, bunları içeren bağlam nesnesine bir başvuru depolar. Stratejiler değil.
• Durumların kendilerini değiştirmelerine izin verilir (IE: bağlam nesnesinin durumunu başka bir şeye değiştirmek için), ancak Stratejiler buna izin verilmez.
• Stratejiler bağlam nesnesine parametre olarak iletilirken, Devletler bağlam nesnesinin kendisi tarafından oluşturulur.
• Stratejiler yalnızca tek, belirli bir görevi yerine getirirken, Devletler bağlam nesnesinin yaptığı her şey (veya çoğu her şey) için temel uygulamayı sağlar.

"Klasik" bir uygulama, listedeki her öğe için Eyalet veya Strateji ile eşleşir, ancak her ikisinin karışımları olan melezlerle karşılaşırsınız. Belirli bir kişinin daha fazla State-y ya da Strategy-y olması nihayetinde öznel bir sorudur.

• Strateji desen strateji gereğine göre bir uygulama diğer değiştirebilirsiniz böylece, (temelde) işlevi gören farklı uygulama aynı şey olması hakkında gerçekten. Örneğin, bir strateji modelinde farklı sıralama algoritmalarınız olabilir. Nesneyi arayanlar hangi stratejinin kullanıldığına bağlı olarak değişmez, ancak stratejiden bağımsız olarak hedef aynıdır (koleksiyonu sıralayın).
• Devlet deseni mümkün olan her devlet ağırlayabilecek yükünden kurtulmaktadır arayan bırakarak, devlete bağlı olarak farklı şeyler yapıyor hakkındadır. Örneğin getStatus(), nesnenin durumuna bağlı olarak farklı durumları döndürecek bir yönteminiz olabilir , ancak her potansiyel durumu hesaba katmak için yöntemin arayanının farklı kodlanması gerekmez.

Fark sadece farklı sorunları çözmelerinde yatmaktadır:

• Devlet ile desen fırsatlar Ne bir nesne (in) olduğu (devlet veya tipi) - bu ise, devlet-bağımlı davranışını kapsüller
• Strateji ile desen fırsatlar nasıl bir nesne belirli bir görevi yerine getirir - bu bir algoritma kapsüller.

Ancak bu farklı hedeflere ulaşmak için yapılan yapılar birbirine çok benzer; her iki örüntü de yetki verilen kompozisyonun örnekleridir.

Avantajları üzerine bazı gözlemler:

Devlet modelini kullanarak, devlet tutma (bağlam) sınıfı, hangi devlet veya türün olduğu ve hangi devlet veya tiplerin mevcut olduğu bilgisinden kurtulur . Bu, sınıfın açık-kapalı tasarım ilkesine (OCP) bağlı olduğu anlamına gelir: sınıf, hangi eyaletlerde / türlerde değişiklikler olduğu için kapalıdır, ancak durumlar / türler uzantılara açıktır.

Strateji kalıbını kullanarak, algoritma kullanma (bağlam) sınıfı, belirli bir görevin nasıl gerçekleştirileceği bilgisinden (- "algoritma") kurtulur. Bu dava aynı zamanda OCP'ye de bağlılık yaratmaktadır; sınıf, bu görevin nasıl gerçekleştirileceğiyle ilgili değişikliklere kapalıdır, ancak tasarım bu görevi çözmek için diğer algoritmaların eklenmesine çok açıktır.
Bu muhtemelen bağlam sınıfının tek sorumluluk ilkesine (SRP) bağlılığını geliştirir. Ayrıca, algoritma diğer sınıflar tarafından yeniden kullanılabilir hale gelir.

Birisi layman'ın terimleriyle açıklayabilir mi?

Tasarım örüntüleri gerçekten "layman" kavramları değildir, ancak mümkün olduğunca açıklığa kavuşturmaya çalışacağım. Herhangi bir tasarım deseni üç boyutta düşünülebilir:

1. Desenin çözdüğü sorun;
2. Desenin statik yapısı (sınıf diyagramı);
3. Desenin dinamiği (sıra diyagramları).

Devlet ve Stratejiyi karşılaştıralım.

Desenin çözdüğü problem

İki durumdan birinde devlet kullanılır [GoF book s. 306] :

• Bir nesnenin davranışı durumuna bağlıdır ve bu duruma bağlı olarak çalışma zamanında davranışını değiştirmelidir.
• İşlemler, nesnenin durumuna bağlı büyük, çok parçalı koşullu ifadelere sahiptir. Bu durum genellikle bir veya daha fazla numaralandırılmış sabit ile temsil edilir. Çoğu zaman, birkaç işlem aynı koşullu yapıyı içerecektir. Devlet modeli, koşulun her dalını ayrı bir sınıfa yerleştirir. Bu, nesnenin durumunu, kendi başına, diğer nesnelerden bağımsız olarak değişebilen bir nesne olarak ele almanızı sağlar.

Durum örüntüsünün çözdüğü soruna gerçekten sahip olduğunuzdan emin olmak istiyorsanız, nesnenin durumlarını sonlu durum makinesi kullanarak modelleyebilmelisiniz . Burada uygulamalı bir örnek bulabilirsiniz .

Her durum geçişi, Durum arayüzünde bir yöntemdir. Bu, bir tasarım için, bu modeli uygulamadan önce durum geçişleri konusunda oldukça emin olmanız gerektiği anlamına gelir. Aksi takdirde, geçiş ekler veya kaldırırsanız arayüzün ve onu uygulayan tüm sınıfların değiştirilmesi gerekir.

Ben şahsen bu modeli faydalı bulamadım. Sonlu durum makinelerini her zaman bir arama tablosu kullanarak uygulayabilirsiniz (OO yolu değildir, ancak oldukça iyi çalışır).

Strateji aşağıdakiler için kullanılmaktadır [GoF book s. 316] :

• birçok ilişkili sınıf sadece davranışlarında farklılık gösterir. Stratejiler, bir sınıfı birçok davranıştan biriyle yapılandırmak için bir yol sağlar.
• bir algoritmanın farklı varyantlarına ihtiyacınız vardır. Örneğin, farklı alan / zaman değişimlerini yansıtan algoritmalar tanımlayabilirsiniz. Bu varyantlar, algoritmaların sınıf hiyerarşisi olarak uygulandığında stratejiler kullanılabilir [HO87].
• bir algoritma istemcilerin bilmemesi gereken verileri kullanır. Karmaşık, algoritmaya özgü veri yapılarını göstermekten kaçınmak için Strateji modelini kullanın.
• bir sınıf birçok davranışı tanımlar ve bunlar işlemlerinde çoklu koşullu ifadeler olarak görünür. Birçok koşul yerine, ilgili koşullu dalları kendi Strateji sınıflarına taşıyın.

Stratejinin nereye uygulanacağı ile ilgili son durum, Polimorfizm ile koşullu olarak değiştir olarak bilinen yeniden düzenleme ile ilgilidir .

Özet: Devlet ve Strateji çok farklı sorunları çözmektedir. Sorununuz bir sonlu durum makinesiyle modellenemiyorsa, büyük olasılıkla Durum düzeni uygun değildir. Sorununuz karmaşık bir algoritmanın varyantlarını kapsüllemekle ilgili değilse, Strateji geçerli değildir.

Desenin statik yapısı

Durum aşağıdaki UML sınıf yapısına sahiptir:

Strateji aşağıdaki UML sınıf yapısına sahiptir:

Özet: statik yapı açısından, bu iki örüntü çoğunlukla özdeştir. Aslında, örneğin, kalıp tespit araçları bu bir o "dikkate [...] desendir aynıdır, (kavramsal bilgiye atıfta bulunmadan, örneğin) bir otomatik işlemle, ayrım yasaklayan. Yapısını "

Bununla birlikte, ConcreteStates devlet geçişlerine kendileri karar verirse büyük bir fark olabilir ( yukarıdaki şemada " belirleyebilir " ilişkilerine bakınız). Bu somut durumlar arasında birleşme ile sonuçlanır. Örneğin (bir sonraki bölüme bakın), A durumu B durumuna geçişi belirler. Context sınıfı bir sonraki somut duruma geçişe karar verirse, bu bağımlılıklar ortadan kalkar.

Desenin dinamiği

Yukarıdaki Sorun bölümünde belirtildiği gibi, Durum davranışın bir nesnenin bazı durumuna bağlı olarak çalışma zamanında değiştiğini ima eder . Bu nedenle, sonlu durum makinesinin ilişkisi ile tartışıldığı gibi , durum geçişi kavramı geçerlidir . [GoF] geçişlerin ConcreteState alt sınıflarında veya merkezi bir konumda (tablo tabanlı bir konum gibi) tanımlanabileceğinden bahseder.

Basit bir sonlu durum makinesini varsayalım:

Alt sınıfların durum geçişine karar verdiklerini varsayarsak (bir sonraki durum nesnesini döndürerek), dinamik şöyle görünür:

Stratejinin dinamiklerini göstermek için gerçek bir örnek almak yararlıdır .

Özet : Her kalıp, bağlama bağlı olarak bir şeyler yapmak için polimorfik bir çağrı kullanır. Durum modelinde, polimorfik çağrı (geçiş) sıklıkla bir sonraki durumda bir değişikliğe neden olur . Strateji modelinde, polimorfik çağrı genellikle içeriği değiştirmez (örneğin, bir kez kredi kartıyla ödeme yapmak, bir dahaki sefere PayPal ile ödeme yapacağınız anlamına gelmez). Yine, Devlet paterninin dinamikleri, (benim için) bu paternin doğru uygulanması için gerekli olan karşılık gelen parazit durumu makinesi tarafından belirlenir .

Strateji Kalıbı, bir algoritmanın uygulanmasını bir barındırma sınıfından taşımayı ve ayrı bir sınıfa yerleştirmeyi içerir. Bu, host sınıfının, her bir algoritmanın kendisinin uygulanmasını sağlaması gerekmediği anlamına gelir;

Sıralama algoritmaları genellikle hepsi aynı türden şeyler (sıralama) yaptığı için örnek olarak kullanılır. Her farklı sıralama algoritması kendi sınıfına yerleştirilirse, istemci hangi algoritmanın kullanılacağını kolayca seçebilir ve desen ona erişmek için kolay bir yol sağlar.

Durum Modeli, nesnenin durumu değiştiğinde bir nesnenin davranışını değiştirmeyi içerir. Bu, host sınıfının içinde bulunabileceği tüm farklı durumlar için davranışın uygulanmasını sağlamadığı anlamına gelir. Host sınıfı genellikle belirli bir durumda gerekli olan işlevselliği sağlayan ve farklı bir sınıfa geçen bir sınıfı kapsar. devlet değiştiğinde.

Müşteri çağrılarını yöneten bir IVR (Sesli Yanıt) sistemini düşünün. Müşterileri şu konularda işlemek üzere programlamak isteyebilirsiniz:

• Çalışma günleri
• Bayram

Bu durumu ele almak için bir Durum Kalıbı kullanabilirsiniz .

• Tatil : IVR sadece ' Aramalar sadece sabah 9'dan akşam 5'e kadar çalışma günlerinde alınabilir ' şeklinde yanıt verir .
• Çalışma günleri : müşteriyi müşteri hizmetleri yöneticisine bağlayarak yanıt verir.

Bir müşteriyi bir destek yöneticisine bağlama süreci, yöneticilerin aşağıdakilerden herhangi birine göre seçildiği bir Strateji Kalıbı kullanılarak uygulanabilir :

• Yuvarlak Robin
• En Son Kullanılanlar
• Öncelik tabanlı diğer algoritmalar

Strateji paterni, bazı eylemlerin nasıl yapılacağına karar verir ve durum paterni, ne zaman yapılacağına karar verir .

Strateji, aynı başlangıç ​​ve bitiş sonuçlarıyla ancak dahili olarak farklı metodolojiler kullanarak bir şey "yapan" nesneleri temsil eder. Bu anlamda, bir fiilin uygulanmasını temsil etmeye benzerler. Durum düzeni OTOH, bir şey olan "bir işlem" olan nesneleri kullanır. Bu veriler üzerindeki işlemleri de temsil etseler de, bir fiilden ziyade bir ismin temsil edilmesine benzerler ve devlet makinelerine uyarlanırlar.

Strateji: strateji sabittir ve genellikle birkaç adımdan oluşur. (Sıralama sadece bir adımdır ve bu nedenle bu modelin amacını anlamak için çok ilkel olduğu için çok kötü bir örnektir). Stratejideki "ana" rutininiz birkaç soyut yöntem çağırıyor. Örneğin, "Oda Stratejisine Girin", "ana yöntem" goThroughDoor () şeklindedir ve şöyle görünür: approachDoor (), if (locked ()) openLock (); açık kapı(); enterRoom (); ) (Sıra; kapıyı kapat(); if (wasLocked ()) lockDoor ();

Şimdi olası bir kilitli kapıdan bir odadan diğerine geçmek için bu genel "algoritmanın" alt sınıfları algoritmanın adımlarını uygulayabilir.

Diğer bir deyişle, stratejinin alt sınıflaması temel algoritmaları değiştirmez, sadece bireysel adımları değiştirir.

YUKARIDA BİR Şablon Yöntem Kalıbıdır. Şimdi kendi uygulama nesnelerine ait (kilit açma / kilitleme ve açma / kapama) adımları atın ve onlara delege edin. Örneğin, anahtarlı bir kilit ve kod kartlı bir kilit iki tür kilittir. Stratejiden "Adım" nesnelerine yetki verin. Şimdi bir Strateji modeliniz var.

Durum Paterni tamamen farklı bir şeydir.

Bir sarma nesneniz ve sarılmış nesneniz var. Sarılı olan "durum" dur. Durum nesnesine yalnızca sarmalayıcısı üzerinden erişilir. Artık sarılmış nesneyi istediğiniz zaman değiştirebilirsiniz, böylece sarıcı durumunu, hatta "sınıfını" veya türünü değiştirmiş gibi görünür.

Örneğin, bir oturum açma hizmetiniz var. Bir kullanıcı adı ve şifre kabul eder. Yalnızca bir yöntemi vardır: oturum açma (String userName, String passwdHash). Oturum açmanın kabul edilip edilmeyeceğine kendisi karar vermek yerine, kararı bir devlet nesnesine devreder. Bu durum nesnesi genellikle yalnızca kullanıcı / geçiş kombinasyonunun geçerli olup olmadığını kontrol eder ve bir oturum açma işlemi gerçekleştirir. Ancak artık "Denetleyici" yi, yalnızca ayrıcalıklı kullanıcıların oturum açmasına izin veren biriyle (örneğin ana süre boyunca) veya hiç kimsenin oturum açmasına izin vermeyen biriyle değiştirebilirsiniz. Yani "denetleyici" sistemin "oturum açma durumunu" ifade eder.

En önemli fark şudur: Bir strateji seçtiğinizde, işiniz bitene kadar ona bağlı kalırsınız. Bu, onun "ana yöntemi" olarak adlandırdığınız anlamına gelir ve bir tanesi çalıştığı sürece asla stratejiyi değiştirmezsiniz. Sisteminizin çalışma süresi boyunca bir durum düzeni durumunda OTOH, uygun gördüğünüz gibi durumu keyfi olarak değiştirirsiniz.

Belirli bir görev için birden fazla algoritmaya sahip olduğunuzda ve istemci çalışma zamanında kullanılacak gerçek uygulamaya karar verdiğinde strateji deseni kullanılır.

Wiki Strateji kalıp makalesinden UML diyagramı :

Ana Özellikler:

1. Davranışsal bir örüntü.
2. Delegasyona dayanıyor.
3. Yöntem davranışını değiştirerek nesnenin bağırsaklarını değiştirir.
4. Algoritmalar ailesi arasında geçiş yapmak için kullanılır.
5. Nesnenin çalışma zamanında davranışını değiştirir.

Daha fazla bilgi ve gerçek dünya örnekleri için bu gönderiye bakın:

Strateji Modelinin Gerçek Dünya Örneği

Durum modeli, bir nesnenin dahili durumu değiştiğinde davranışını değiştirmesine izin verir

Wiki Devlet kalıp makalesinden UML diyagramı :

Bir nesnenin davranışını durumuna göre değiştirmek zorunda kalırsak, Object içinde bir durum değişkenine sahip olabilir ve duruma dayalı farklı eylemler gerçekleştirmek için if-else koşul bloğunu kullanabiliriz. Durum paterni, Bağlam ve Devlet uygulamaları yoluyla bunu başarmak için sistematik ve kayıp-bağlı bir yol sağlamak için kullanılır .

Daha fazla ayrıntı için bu journaldev makalesine bakın.

Kaynak yapımı ve journaldev makalelerinden temel farklılıklar :

1. Devlet ve Strateji arasındaki fark bağlama zamanı ile ilgilidir. Strateji bir zamanlar birbirine bağlı bir kalıp iken, Devlet daha dinamiktir .
2. Devlet ve Strateji arasındaki fark niyettedir. Strateji ile algoritma seçimi oldukça kararlıdır . Durum ile, "bağlam" nesnesinin durumundaki bir değişiklik, nesnenin Strateji nesnelerinin "paletinden" seçimine neden olur .
3. Bağlam örneği değişken olarak durumunu içerir eden ve uygulama bağlı olabilir birden fazla görevi olabilir halde oysa strateji model stratejisi yöntemine değişken gibi geçirilir bağlam depolamak için herhangi bir değişken olmayan nesne.

Layman'ın dilinde,

Strateji modelinde, hiçbir eyalet yoktur veya hepsinin durumu aynıdır. Farklı doktorlar aynı hastanın aynı hastalığına aynı durumda farklı şekillerde davranır gibi, hepsinin farklı bir görevi yerine getirme yolları vardır.

Durum Paterninde subjektif olarak, bir sonraki eylem yoluna (ilaç reçetesi) karar verilecek olan hastanın mevcut durumu (yüksek sıcaklık veya düşük sıcaklık diyelim) gibi durumlar vardır ve bir durum başka bir duruma yol açabilir, bu nedenle devlet vardır devlet bağımlılığına (teknik olarak kompozisyon).

Teknik olarak anlamaya çalışırsak, her ikisinin de kod karşılaştırmasına dayanarak, durumun öznelliğini kaybedebiliriz, çünkü her ikisi de çok benzer görünüyor.

Her iki örüntü de birkaç türevi olan bir temel sınıfa delege eder, ancak yalnızca türev örüntüsünde bu türev sınıflarının bağlam sınıfına bir referansı vardır.

Buna bakmanın bir başka yolu, Strateji modelinin Devlet modelinin daha basit bir versiyonudur; isterseniz bir alt örüntü. Bu gerçekten türetilmiş devletlerin referansları bağlama geri almasını isteyip istemediğinize bağlıdır (yani: bağlamda yöntemleri çağırmasını ister misiniz).

Daha fazla bilgi için: Robert C Martin (& Micah Martin) bunu "C #'daki Çevik İlkeler, Desenler ve Uygulamalar" başlıklı kitabında yanıtlıyor. ( http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 )

Bu oldukça eski bir soru, ama yine de aynı cevapları arıyordum ve keşfettiğim şey de bu.

Durum paterni için Medial Player Play düğmesinin bir örneğini ele alalım. Oynadığımızda oynamaya başlar ve bağlamın oynandığının farkında olur. İstemci oyun işlemini her yapmak istediğinde, oynatıcının geçerli durumunu kontrol eder. Artık istemci, nesnenin durumunun bağlam nesnesi üzerinden oynatıldığını biliyor, bu yüzden duraklatma durumu nesnelerini eylemler yöntemini çağırıyor. İstemcinin durumu fark eden kısmı ve ne tür bir işlem yapması gerektiği otomatikleştirilebilir.

https://www.youtube.com/watch?v=e45RMc76884 https://www.tutorialspoint.com/design_pattern/state_pattern.htm

Strateji düzeni söz konusu olduğunda, sınıf diyagramının düzenlenmesi durum düzeni ile aynıdır. Müşteri bu düzenlemeye biraz işlem yapmak için gelir. Yani farklı durumlar yerine farklı algoritmalar vardır, örneğin desen üzerinde yapılması gereken farklı analizler. Burada müşteriler bağlamı ne yapmak istediğini hangi algoritmayı (iş tanımlı özel algoritma) söyler ve daha sonra bunu gerçekleştirir.

https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm

Her ikisi de açık kapatma ilkesini uygular, böylece geliştirici durum düzenine ve yeni algoritmaya yeni durumlar ekleme yeteneğine sahiptir.

Ancak fark, nesnenin durumuna bağlı olarak farklı mantığı yürütmek için kullanılan durum paternidir. Ve bir strateji durumunda farklı mantık.

Devlet, devletten türetilen sınıflar içinde biraz bağımlılıklar ile gelir: bir devlet, ondan sonra gelen diğer devletleri bilir. Örneğin, Yaz her mevsim durumu için kıştan sonra veya alışveriş için Mevduat durumundan sonra Teslim durumundan gelir.

Öte yandan, Strateji'nin bu gibi bağımlılıkları yoktur. Burada, program / ürün türüne göre her türlü durum başlatılabilir.

Aradaki fark http://c2.com/cgi/wiki?StrategyPattern . Verileri analiz etmek için genel bir çerçeve içinde farklı algoritmaların seçilmesine izin vermek için Strateji modelini kullandım. Bu sayede, genel çerçeveleri ve mantığını değiştirmek zorunda kalmadan algoritmalar ekleyebilirsiniz.

Bunun tipik bir örneği, amy'nin bir işlevi optimize etmek için bir çerçeveye sahip olmasıdır. Çerçeve, veri ve parametreleri ayarlar. Strateji modeli, çerçeveyi değiştirmeden en alt inişler, eşlenik gradyanlar, BFGS, vb. Gibi algoritmaları seçmenize olanak tanır.

Hem Strateji hem de Devlet modeli aynı yapıya sahiptir. Her iki desen için UML sınıf diyagramına bakarsanız, tamamen aynı görünürler, ancak niyetleri tamamen farklıdır. Durum tasarım deseni bir nesnenin durumunu tanımlamak ve yönetmek için kullanılırken, Strateji desen bir dizi değiştirilebilir algoritmayı tanımlamak için kullanılır ve istemcinin bunlardan birini seçmesine izin verir. Bu nedenle, Strateji deseni istemci tarafından yönlendirilen bir modelken, Object orada devletin kendisini yönetebilir.

Kısacası, strateji paterni ile, hareket halindeyken bazı davranışlar belirleyebiliriz, durum paterni ile, bir nesnenin davranışını kendi durumunun değişmesiyle dahili olarak değiştireceğinden emin olabiliriz.

2 göreve ayrılabilecek bir projeniz olduğunda:

görev 1: gerçekleştirmek için iki farklı algoritmadan birini kullanabilirsiniz: alg1, alg2

görev 2: gerçekleştirmek için üç farklı algoritmadan birini kullanabilirsiniz: alg3, alg4, alg5

alg1 ve alg2 birbirinin yerine kullanılabilir; alg3, alg4 ve alg5 birbirinin yerine kullanılabilir.

Görev 1 ve görev 2'de hangi algoritmanın gerçekleştirileceğini seçmek durumlara bağlıdır:

durum 1: görev 1'de alg1'e ve görev 2'de alg3'e ihtiyacınız var

durum 2: Görev 1'de alg2'ye ve görev 2'de alg5'e ihtiyacınız var

Bağlamınız durum nesnesini durum 1'den durum 2'ye dönüştürebilirsiniz. Ardından göreviniz alg1 ve alg3 yerine alg2 ve alg5 tarafından gerçekleştirilecektir.

Görev 1 veya görev 2 için daha fazla değiştirilebilir algoritmalar ekleyebilirsiniz. Bu, strateji modelidir.

Görev 1 ve görev 2'de farklı algoritma kombinasyonlarıyla daha fazla duruma sahip olabilirsiniz. Durum kalıbı, bir durumdan diğerine geçiş yapmanızı ve farklı algoritma kombinasyonlarını gerçekleştirmenizi sağlar.

'Strateji' sadece ihtiyacınız olduğunda farklı durumlarda değiştirebileceğiniz bir algoritmadır ve sizin için bir şey işler. Ör. bir dosyanın nasıl sıkıştırılacağını seçebilirsiniz. zip veya rar ... bir yöntemle.

Ancak 'Durum' değiştiğinde tüm nesne davranışınızı değiştirebilir, Diğer alanları değiştirse bile ... bu yüzden sahibine bir referansı var. Bir nesne alanını değiştirmenin nesne davranışını değiştirebileceğini fark etmelisiniz. Ör. Objede State0 değerini State1 olarak değiştirdiğinizde, bir tamsayıyı 10 olarak değiştirirsiniz. Bu nedenle, bazı hesaplama yapan ve bu tamsayıyı kullanan obj.f0 () öğesini çağırdığımızda, sonucu etkiler.