Özelliklerin anlamı nedir?

İşte özellikler ve karşı argümanlarım için bazı argümanlar:

Alıcı ve ayarlayıcı yöntemleri yazmaktan daha kolay

Getter ve setter yöntemi çiftleri bir kod kokusudur. Bunları yazmayı kolaylaştırmak, Scantron formunu kullanarak ve tüm 'C'leri doldurarak bir matematik testinde başarısız olmayı kolaylaştırmak gibidir. Kalıcılık için yalnızca durum içeren nesneler alıcılar / ayarlayıcılar kullanmamalı ve kalıcılık anında değişmez nesneler oluşturmalıdır.

Bir nesnenin tüketicisi için önemli olan, nasıl yaptığı değil, yaptığı şeydir. Davranışı yaptığı şeydir; onun durumu nasıl yapıyor. Kendinizi bir nesnenin durumu hakkında önemsiyorsanız (kalıcılık hariç, bu aynı zamanda OO'yu da kırıyorsa), sadece OOP yapmazsınız ve avantajlarını kaybedersiniz.

Tüketicilere kabaca bir performans göstergesi veriyorlar

Bu, herhangi bir mülk için gelecekte değişebilecek bir şeydir. 1.0 sürümünde, PropertyX'e erişmenin yalnızca bir alan döndürdüğünü varsayalım. Sürüm 1.5'te, alan null ise, PropertyX yeni bir null nesne oluşturmak için Null Nesne desenini kullanır. Sürüm 2.0, alan PropertyX içindeki getter yöntemi ile daha da doğrulanıyor.

Mülk gittikçe karmaşıklaştıkça, bir mülkü kullanmanın performans göstergesi gittikçe daha az doğru görünüyor.

Kamusal alanlardan daha iyidirler

Bu doğru. Ama yöntemler de öyle.

Bir nesnenin yöntemden çok farklı bir yönünü temsil ederler ve nesnenin tüm tüketicileri bunu önemsemelidir

Yukarıdaki ifadelerin her ikisinin de doğru olduğundan emin misiniz?

Yazmak daha kolay, adamım

Elbette, yazmak yazmaktan myObject.Lengthdaha kolaydır myObject.Length(), ancak bu biraz sözdizimsel şekerle düzeltilemez mi?

Neden özellikler yerine yöntemler kullanılmalı?

• Performans garantisi yoktur. Yöntem daha karmaşık hale gelse bile API doğru kalacaktır. Tüketici, performans sorunlarıyla karşılaşıyorsa ve API kelimesine güvenmiyorsa kodunu profille oluşturması gerekir.

• Tüketicinin düşünmesi için daha az. Bu tesiste bir pasör var mı? Emin bir yöntem değildir.

• Tüketici uygun bir OOP zihniyetinden düşünüyor. Bir API'nin tüketicisi olarak, bir nesnenin davranışıyla etkileşime girmekle ilgileniyorum. API'de özellikler gördüğümde, duruma çok benziyor. Aslında, özellikler çok fazla işliyorsa, özellik olmamalı, hatta gerçekte bir API ARE'deki özellikler tüketicilere göründüğü haliyle.

• API programcısı dönüş değerlerine sahip yöntemler hakkında daha derin düşünecek ve mümkünse bu yöntemlerde nesnenin durumunu değiştirmekten kaçınacaktır. Komutların sorgulardan ayrılması mümkün olan her yerde uygulanmalıdır.

Size soruyorum, neden yöntemler yerine özellikleri kullanalım? Üzerindeki noktaların çoğu MSDN kod içinde ve kendileri kokuyor, ve ya özellik ve yöntemlerle ait değil.

(Bu düşünceler CQS'yi düşündükten sonra bana geldi.)

Neden "özelliklere karşı yöntemler"? Bir yöntem bir şey yapar. Özellik, bir nesnenin üyesidir. Tamamen farklı şeylerdir, ancak genellikle yazılan iki tür yöntem - alıcılar ve ayarlayıcılar - özelliklere karşılık gelir. Özelliklerin yöntemlerle genel olarak karşılaştırılması anlamlı olmadığından, alıcılar / ayarlayıcılar hakkında konuşmak istediğinizi varsayacağım.

Getter ve setter yöntemi çiftleri bir kod kokusudur.

Mutlaka tartışmam gerekecekti, ama her iki durumda da bu özellik getters / setters ve mülkler meselesi değil, her ikisinin de kullanılması gerekip gerekmediği meselesi. Ayrıca, örneğin setXsalt okunur özellikler yapabileceğiniz gibi parçayı dışarıda bırakabileceğinizi de unutmayın .

Bir nesnenin tüketicisi için önemli olan, nasıl yaptığı değil, yaptığı şeydir. Davranışı yaptığı şeydir; onun durumu nasıl yapıyor. Kendinizi bir nesnenin durumu hakkında önemsiyorsanız (kalıcılık hariç, bu aynı zamanda OO'yu da kırıyorsa), sadece OOP yapmazsınız ve avantajlarını kaybedersiniz.

Son derece tartışmalı bir tutum. GUI a tarafından tutulan verileri DataStuffManagerImplçıkarmak istiyorsa, bu sayıyı bir şekilde alması gerekir (ve hayır, uygulamanın yarısını widget sınıfına sıkıştırmak bir seçenek değildir).

Mülk gittikçe karmaşıklaştıkça, bir mülkü kullanmanın performans göstergesi gittikçe daha az doğru görünüyor.

[Yöntemler var] Performans garantisi yoktur. Yöntem daha karmaşık hale gelse bile API doğru kalacaktır. Tüketici, performans sorunlarıyla karşılaşıyorsa ve API kelimesine güvenmiyorsa kodunu profille oluşturması gerekir.

Hemen hemen tüm durumlarda, tüm doğrulama mantığı vb. Hala etkili bir şekilde O (1) veya başka bir şekilde maliyetsizdir. Değilse, belki çok ileri gittiniz ve değişim zamanı. Ve bir getX()yöntem genellikle ucuz olarak kabul edilir!

Tabii, myObject.Length yazmak myObject.Length () yazmaktan daha kolaydır, ancak bu biraz sözdizimsel şekerle düzeltilemez mi?

Özellikleri şunlardır o sözdizimsel şeker.

Tüketicinin düşünmesi için daha az. Bu tesiste bir pasör var mı? Emin bir yöntem değildir.

"Bu alıcı için bir pasör var mı?" Aynı farklılık.

API programcısı dönüş değerlerine sahip yöntemler hakkında daha derin düşünecek ve mümkünse bu yöntemlerde nesnenin durumunu değiştirmekten kaçınacaktır. Komutların sorgulardan ayrılması mümkün olan her yerde uygulanmalıdır.

Bize burada ne anlatmaya çalıştığından emin değilim. Mülkler için, yan etkilere neden olmamak için daha güçlü bir yazılı yasa yoktur.

Getter ve setter yöntemi çiftleri bir kod kokusudur.

Bu hatalı bir varsayımdır ve tamamen yanlıştır. Get / Set yöntemleri bir veri elemanını kapsüllemenin bir yoludur ve hiçbir şekilde bir "kod kokusu" değildir. Gerçekten bazı insanlar "kod kokusu" terimi etrafında atmaktan nefret ediyorum, ama yine de ...

Bu, herhangi bir mülk için gelecekte değişebilecek bir şeydir. 1.0 sürümünde, PropertyX'e erişmenin yalnızca bir alan döndürdüğünü varsayalım. Sürüm 1.5'te, alan null ise, PropertyX yeni bir null nesne oluşturmak için Null Nesne desenini kullanır. Sürüm 2.0, alan PropertyX içindeki getter yöntemi ile daha da doğrulanıyor.

Mülk gittikçe karmaşıklaştıkça, bir mülkü kullanmanın performans göstergesi gittikçe daha az doğru görünüyor.

Kötü tasarlanmış bir API gibi geliyor, bu özellik sözdizimi hatası nasıl görmüyorum.

C # 'daki özellikler, programcılar olarak hayatımızı biraz daha kolaylaştıran çok yaygın bir model için sözdizimsel şekerdi. Bununla birlikte, bu günlerde, veri bağlamayı kullanmak istiyorsanız, özellikleri kullanmalısınız, böylece bunlar sözdizimsel şekerden biraz daha fazladır. Sanırım gerçekten hiçbir noktanıza katılmıyorum ve neden doğrudan ortak bir modeli destekleyen bir dil özelliğini sevmediğinizi anlamıyorum.

Sizin öncülünüz yanlış.

Mülkler hiçbir şekilde performans veya dahili uygulama ya da her neyse bir sözleşme değildir.
Özellikler, dilerseniz anlamsal olarak bir özniteliği temsil eden özel yöntem çiftleridir. Ve böylece tek sözleşme, bir mülkün, bir özelliğin davranmasını beklediğiniz gibi davrandığıdır.
Bir nesnenin rengini sorarsam, düz alan erişimi ile elde edilip edilmediğini veya tam zamanında hesaplanıp hesaplanmadığını varsaymıyorum.
Bütün mesele, ister bir alan ister erişimci kullansanız da, bir özniteliğin davranışlarını yöntemler kullanarak ortaya çıkarma yeteneğine sahip olmak, arabirimin tüketicisine açıktır.

Niteliklere sahip olmak (ve özelliklerin alanlara zıt olarak uygulamalarını gizlemek), görsel nesne denetleyicilerine ve diğer otomatik görüntüleme oluşturmaya, veri bağlama ve diğer birçok yararlı şeye sahip olmanın temeli olan güçlü bir bildirim özelliğidir. Ve en önemlisi, bu bilgileri diğer programcılarınız için de açıkça taşır.

Tüketici uygun bir OOP zihniyetinden düşünüyor. Bir API'nin tüketicisi olarak, bir nesnenin davranışıyla etkileşime girmekle ilgileniyorum. API'de özellikler gördüğümde, duruma çok benziyor. Aslında, özellikler çok fazla işliyorsa, özellik olmamalı, hatta gerçekte bir API ARE'deki özellikler tüketicilere göründüğü haliyle.

Bir mülkün devlet olması gerekiyordu . Altta yatan ayarlayıcı veya alıcı kodu eklemek değiştirirse anlamlı setine gerekli işlenmesine veya sonra devlet olsun gerçekten artık bir özelliktir ve gereken yöntemleri ile değiştirin. Bu, kodun geliştiricisi olarak size kalmış.

Bir ayarlayıcıya veya alıcıya çok fazla (ne kadar çok bağlı) kod koymak yanlıştır, ancak her durumda paterni atmak için bir neden değildir.

Eksik olan bir şey var ve bunun cehaletten kaynaklanıp kaynaklanmadığını veya kasıtlı olarak bu ayrıntıyı gözden geçirip geçirmediğinizi bilmiyorum, özellikler ARE yöntemleri.

C # 'ın özellik sözdizimini kullandığınızda, derleyici sessizce getter ve setter yöntemlerini meta veriyle oluşturur. Aslında, istediğin sözdizimsel şeker. CLR'de çalıştırılabilecek birkaç dil bu ayrıntıyı sizden tamamen gizlemez (Boo, bellek bana hizmet ediyorsa ve bazı Lisp uygulamaları) ve alıcıları ve ayarlayıcıları açıkça arayabilirsiniz.

Özelliklerin, bazen değişiklik bildirim olaylarını tetikleme (örneğin INotifyPropertyChanged) veya bir sınıf örneğini kirli olarak işaretleme gibi yan etkileri vardır. Burası gerçek değerlerine sahip oldukları yerdir, ancak onları oluşturmak biraz daha fazla iştir (sözdizimi meraklı makrolara sahip Boo hariç).

Şimdi, daha geniş olan soru, alıcı ve belirleyici yöntemlerin aslında İyi Bir Şey olup olmadığıdır. Açıkça ödünleşmeler var; mutator yöntemleriniz varsa, artık iş parçacığı senkronizasyonu sorunlarıyla uğraşmanız gerektiğinden, kodunuz doğal olarak daha az paralelleştirilebilir. Ve mutasyon yöntemleri (ister özellikler ister alıcı / ayarlayıcı yöntemleri olarak adlandırılır; eşdeğerdir) kullanarak Demeter Yasasını ihlal etme riskiniz olabilir, çünkü bunu yapmak çok uygun.

Ancak bazen yapılması gereken doğru şey budur. Bazen sorununuz bazı kaynaklardan veri almak, biraz değiştirmek, güncellenmiş verileri kullanıcıya sunmak ve değişiklikleri kaydetmek. Bu deyim, özellikler tarafından iyi hizmet edilir. As Allen Holub makalesi diyor, Alıcılar ve ayarlayıcılar sorunları var sırf bunları kullanmak asla gelmez. (Papağan soyut Guruspeak zararlı olarak kabul edilir). Sınıf / Sorumluluklar / İşbirliği Yapanlar yaklaşımını izleseniz bile, yine de birisine bilgi ya da bilgi sunumları sunmaya başlarsınız; amaç dolaşıklığın yüzey alanını en aza indirmektir.

Özelliklerin tersi, başka bir nesnenin bunlardan faydalanmasının çok kolay olmasıdır. Özelliklerin dezavantajı, başka bir nesnenin bunlardan faydalanmasının çok kolay olmasıdır ve bunu kolayca önleyemezsiniz.

Nesne mutasyonu, örneğin bir MVC mimarisinde kontrolör katmanında anlamlıdır. Bu sizin ortak çalışanınız. Görüşünüz aynı zamanda bir ortaktır, ancak nesnelerinizi doğrudan değiştirmemelidir, çünkü farklı sorumlulukları vardır. Sunum kodunu iş nesnelerinize dönüştürmek, alıcıları / ayarlayıcıları da önlemek için doğru yol değildir.

Saf OO soyutlamaları yerine fonksiyonel kullanırsanız denklem biraz değişir, bu da genellikle bir "kayıt" nesnesinin kopyalarını, birkaç değişiklikle oldukça özgür olsa da, oldukça önemsiz hale getirir. Ve hey, Performans garantileri almaya çalışıyorsanız, özellikler genellikle değişmez bir koleksiyonun tembel olarak yeniden yapılandırılmasından daha öngörülebilir.

Kitabımdaki özelliklerin kullanılmasının bir başka önemli nedeni, okunabilirliği büyük ölçüde artırabilmeleridir.

account.setBalance(Account.getBalance()+deposit);

açıkça daha az okunabilir

account.Balance += deposit;

Bana neredeyse tam tersi dini bakış açısına sahipsiniz :)

Delphi Java taşındı zaman özellikleri eksikliği bana büyük bir hakaret oldu. Ben bir özellik bildirmek ve ya doğrudan özel bir değişkene işaret ya da (korumalı) alıcı ve ayarlayıcı yazma sonra "onları sıhhi tesisat" özelliği için kullanılır. Bu, mülkü kapsülledi ve açık bir şekilde nasıl erişilmesi gerektiğini kontrol etti. Erişildiğinde toplamı hesaplayan salt okunur bir özelliğiniz olabilir ve buna "_getTotal ()" veya benzeri balonlar değil "Toplam" debilirsiniz. Ayrıca, soyut temel sınıfta korunmalarını sağlayıp sonra herkese açık veya alt sınıflarda yayınlayarak mülklere erişimi kısıtlayabileceğiniz anlamına da geliyordu.

Bana göre, özellikler nesnenin durumunu ayarlamanın ve elde etmenin daha doğal ve etkileyici bir yoludur. Güçlendirilmemiş kodlama kurallarına güvenmek, özelliklerini eleştirdiğiniz her şeyden çok bir "kod kokusudur". Ayrıca, diğerlerinin söylediği gibi, kötü tasarlanmış bir mülk kullanımı bulmak ve başarısızlıklarını genel olarak mülk kavramını denemek ve reddetmek için kullanmak son derece kötü bir formdur. Sadece mülklerin kötü kullanımını gördünüz ve sanırım öyle olduğunu varsayıyorum ama çok dogmatik olmadan önce daha fazla araştırma yapmalısınız.

Özelliklerin Java Fasulye Çerçevesi'nde kullanılmasının nedenlerinden biri, bir IDE ile entegrasyona izin vermekti - bu bileşenleri IDE'ye sürükleyebilir ve özellik düzenleyicilerini kullanarak özellikleri düzenleyebilirsiniz.

(o zamanlar sadece düzenli alıcılar ve ayarlayıcılardı - ve sadece adlandırma kuralı tarafından tanımlandılar - ve bu gerçekten kokuyordu)

Bugün, hata ayıklama gibi, normal kod aracılığıyla özelliklere erişilemediği ve değiştirildiği daha da fazla durum var.

Başka bir açı - gerçekten VB'den geldi. Unutmayın, .NET'in tasarlandığı 20. yüzyılın karanlık günlerinde, VB için kolay, açılan bir yedek olması, VB programcılarınızın şeyleri web formlarına sürükleyip bırakabilmeleriydi. VB'nin özellikleri vardı, bu yüzden şeyleri doğru çevirmek için bu özelliği korumanız gerekiyordu.

Mülkler için en az iki amaç vardır:

• Farklı uygulansalar bile , kavramsal olarak alanlarla aynıdırlar . Alıcı, nesnenin durumunu değiştirmemeli ve hiçbir yan etkisi olmamalıdır. Bir ayarlayıcı, durumu yalnızca kavramsal olarak bir alanı değiştirmeye benzer şekilde değiştirmeli ve başka yan etkilere sahip olmamalıdır.

• Sözdizimsel olarak herkese açık (muhtemelen salt okunur) alanlarla aynıdır. Bu, ortak alanın, arayanları kaynak düzeyinde bozmadan bir mülke dönüştürülebileceği anlamına gelir.