C # 3.0 otomatik özellikleri - yararlı ya da değil? [kapalı]

Not: Bu C # başladığımda gönderildi. 2014 bilgisiyle, otomatik özelliklerin C # dilinin başına gelmiş en iyi şeyler arasında olduğunu söyleyebilirim.

Özel ve ortak bir alan kullanarak C # özellikleri oluşturmak için kullanılır:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Şimdi, .NET 3.0 ile otomatik özellikler aldık:

public string Title { get; set; }

Bunun daha felsefi / sübjektif sorular olduğunu biliyorum, ancak her alan için beş satır kod kaydetme dışında bu otomatik özellikleri kullanmak için herhangi bir neden var mı? Benim kişisel yakınlığım, bu özelliklerin benden bir şeyler saklaması ve kara büyünün büyük bir hayranı değilim.

Aslında, gizli özel alan hata ayıklayıcıda bile görünmez, bu da get / set işlevlerinin hiçbir şey yapmadığı göz önüne alındığında tamamdır. Ama aslında bazı alıcı / ayarlayıcı mantığını uygulamak istediğimde, özel / ortak çifti yine de kullanmalıyım.

Daha sonra alıcı / ayarlayıcı mantığını değiştirme yeteneğini kaybetmeden kod çok (bir vs altı satır) kaydetmek yarar görüyorum, ama sonra tekrar ben zaten sadece bir ortak alan "Genel dize Başlık" bildirerek yapabilirim {get; Ayarlamak; } böylece daha fazla kod tasarrufu sağlar.

Peki, burada ne eksik? Neden birisi otomatik özellikleri kullanmak isteyesin ki?

Yığın Taşmasında her zaman kullanıyoruz.

Ayrıca, Özellikler ve Ortak Değişkenler üzerine bir tartışma da ilginizi çekebilir . IMHO gerçekten buna bir tepki ve bu amaçla harika.

Evet, sadece kod tasarrufu sağlar. Çok fazla yüklediğinizde okumak çok daha kolay. Yazması daha hızlı ve bakımı daha kolaydır. Kod kaydetmek her zaman iyi bir hedeftir.

Farklı kapsamlar ayarlayabilirsiniz:

public string PropertyName { get; private set; }

Böylece özellik sadece sınıf içinde değiştirilebilir. Özel ayarlayıcıya yansıma yoluyla erişebildiğiniz için bu gerçekten değişmez değil.

C # 6'dan itibaren gerçek readonlyözellikler de oluşturabilirsiniz - yani yapıcı dışında değiştirilemeyen değişmez özellikler:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Derleme zamanında:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

Çok sayıda üyesi olan değişmez sınıflarda bu çok fazla kod tasarrufu sağlar.

Özellikler yerine alanları kullanmanın üç büyük dezavantajı:

1. Bir alana veri atamazsınız, bir mülke
2. Bir alanı kullanmaya başlarsanız, daha sonra (kolayca) bunları bir mülke değiştiremezsiniz
3. Bir alana ekleyemediğiniz bir özelliğe ekleyebileceğiniz bazı özellikler var

Ben şahsen oto-özellikleri seviyorum. Kod satırlarını kaydetmenin nesi yanlış? Alıcılarda veya ayarlayıcılarda bir şeyler yapmak istiyorsanız, bunları daha sonra normal özelliklere dönüştürmek için sorun yoktur.

Dediğiniz gibi alanları kullanabilirsiniz ve bu alanlara daha sonra mantık eklemek isterseniz, bunları özelliklere dönüştürürdünüz. Ancak bu, herhangi bir yansıma kullanımı (ve muhtemelen başka bir yerde?) İle ilgili sorunlar yaratabilir.

Ayrıca özellikler, alanla yapamayacağınız alıcı ve ayarlayıcı için farklı erişim düzeyleri ayarlamanıza olanak tanır.

Sanırım var anahtar kelimesi ile aynı. Kişisel tercih meselesi.

C ++ yaratıcısı Bjarne Stroustrup'tan:

Özellikle birçok get ve set fonksiyonuna sahip sınıflardan hoşlanmıyorum. Bu genellikle ilk etapta bir sınıf olmaması gerektiğinin bir göstergesidir. Bu sadece bir veri yapısı. Ve eğer gerçekten bir veri yapısı ise, onu bir veri yapısı yapın.

Ve biliyor musun? O haklı. Özel alanları bir get ve set içinde, ne zaman get / set içinde hiçbir şey yapmadan basitçe sararsınız, çünkü bunun yapılması "nesne odaklı" bir şeydir. Bu Microsoft'un soruna çözümü; bunlar temel olarak bağlanabileceğiniz genel alanlardır.

Kimsenin bahsetmediği bir şey, oto-özelliklerin maalesef değişmez nesneler (genellikle değişmez yapılar) için ne kadar yararlı olmadığıdır. Çünkü bunun için gerçekten yapmanız gerekenler:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(alan, yapıcıda geçirilen bir parametre aracılığıyla başlatılır ve sonra salt okunurdur.)

Yani bunun basit get/ otomatik private setpilotlara göre avantajları vardır .

Arabirim tanımındaki özellikleri kullanabileceğiniz, arabirim tanımındaki ortak alanları kullanamayacağınız için her zaman ortak alanlar yerine özellikler oluşturuyorum.

Otomatik özellikler, C # 'da herhangi bir şey kadar kara bir sihirdir. Bir kez normal bir C # özelliğine genişletilmesi yerine IL'ye derleme açısından düşündüğünüzde, öncelikle diğer birçok dil yapısından çok daha az kara büyü.

Her zaman otomatik özellikler kullanıyorum. C # 3'ten önce tüm yazımlardan rahatsız olamadım ve bunun yerine genel değişkenler kullandım.

Özlediğim tek şey bunu yapabilmek:

public string Name = "DefaultName";

Varsayılanları özellikleri olan yapıcılarınıza kaydırmanız gerekir. sıkıcı :-(

Ben sezgisel ve kod satırlarını azaltır herhangi bir yapı büyük bir artı olduğunu düşünüyorum.

Bu tür özellikler Ruby gibi dilleri bu kadar güçlü kılan özelliklerdir (bu ve aşırı özellikler azaltılmasına yardımcı olan dinamik özellikler).

Ruby tüm bunları şöyle sürdürdü:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Onlarla ilgili tek sorun, yeterince ilerlememeleri. Otomatik özellikleri ekleyen derleyicinin aynı sürümü, kısmi yöntemler ekledi. Neden ikisini bir araya getirmediler beni aştı. Basit bir "kısmi Açık <MülkAdı> Değişti", bu şeyleri gerçekten gerçekten yararlı hale getirirdi.

Çok basit, kısa ve tesisin gövdesinde bir yerde gerçek bir uygulama oluşturmak istiyorsanız, türünüzün dış arayüzünü bozmaz.

Kadar basit.

Burada not edilmesi gereken bir şey, benim anlayışım için, bu sadece C # 3.0 ucundaki sözdizimsel şeker, yani derleyici tarafından üretilen IL aynıdır. Kara büyüden kaçınmayı kabul ediyorum, ama aynı şey için aynı, daha az satır genellikle iyi bir şeydir.

Bence, genel alanlar yerine her zaman otomatik özellikler kullanmalısınız. Bununla birlikte, bir uzlaşma:

Bir mülk için kullanacağınız adlandırma kuralını kullanarak dahili bir alanla başlayın . İlkini sen ne zaman

• montaj alanının dışından alana erişmesi veya
• alıcıya / ayarlayıcıya mantık eklemeniz gerekir

Bunu yap:

1. alanı yeniden adlandır
2. onu özel yap
3. halka açık bir mülk ekle

İstemci kodunuzun değiştirilmesi gerekmez.

Bir gün, sisteminiz büyüyecek ve onu ayrı montajlara ve çoklu çözümlere ayıracaksınız. Bu durumda, Jeff'in belirttiği gibi, ortak bir alanı genel bir mülke dönüştürmek bir API değişikliği olduğu için, maruz kalan alanlar sizi rahatsız edecek şekilde geri gelecektir .

CodeRush kullanıyorum, otomatik özelliklerden daha hızlı.

Bunu yapmak için:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Toplam sekiz tuş vuruşu gerektirir.

Kod parçacıkları ile aynı ada sahip bir otomatik özellik toplamda yedi tuş vuruşudur;)

@Domenic: Anlamıyorum .. Bunu otomatik özelliklerle yapamaz mısın ?:

public string Title { get; }

veya

public string Title { get; private set; }

Bahsettiğiniz bu mu?

Otomatik özelliklere sahip en büyük tutkum, zamandan tasarruf etmek için tasarlandıkları, ancak daha sonra onları tam gelişmiş özelliklere genişletmem gerektiğine inanıyorum.

VS2008 eksik olan bir Explode Auto-Property refactor olduğunu.

Biz işin doğrusunu kapsülü alan Refactor sadece kamu alanlarını kullanmak daha hızlı bir yol Ben iş yapar.