Alıcıları ve ayarlayıcıları / erişimcileri neden kullanmalıyım?

Yalnızca bu değişkenler için ortak alanları kullanmak yerine, yalnızca elde edilen ve ayarlanan alıcıları ve ayarlayıcıları kullanmanın avantajı nedir?

Alıcılar ve ayarlayıcılar basit bir set / setten daha fazlasını yapıyorsa, bunu çok hızlı bir şekilde çözebilirim, ancak nasıl yapılacağı konusunda% 100 net değilim:

public String foo;

daha kötüdür:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

Halbuki ilki çok daha az kaynak plakası alır.

Aslında bir sınıfın alanlarını doğrudan ortaya koymak yerine erişimcileri kullanmayı düşünmek için birçok iyi neden vardır - sadece kapsülleme argümanı ve gelecekteki değişiklikleri kolaylaştırmak.

İşte farkında olduğum bazı nedenler:

• Mülk edinme veya ayarlama ile ilişkili davranışların kapsüllenmesi - bu, daha sonra daha kolay bir şekilde ek işlevin (doğrulama gibi) eklenmesini sağlar.
• Alternatif bir temsili kullanarak bir özelliği ortaya koyarken mülkün iç temsilini gizleme.
• Genel arayüzünüzü değişiklikten yalıtmak - uygulama mevcut tüketicileri etkilemeden değişirken genel arayüzün sabit kalmasını sağlar.
• Mülkün yaşam boyu ve bellek yönetimi (bertaraf) semantiğinin kontrol edilmesi - özellikle yönetilmeyen bellek ortamlarında (C ++ veya Objective-C gibi) önemlidir.
• Bir özelliğin çalışma zamanında değiştiğinde hata ayıklama önleme noktası sağlama - bir özelliğin belirli bir değere ne zaman ve nerede değiştiğini hata ayıklama, bazı dillerde bu olmadan oldukça zor olabilir.
• Mülkiyet alıcı / ayarlayıcılara karşı çalışmak üzere tasarlanmış kütüphanelerle birlikte çalışabilirlik geliştirildi - Alay, Serileştirme ve WPF akla geliyor.
• Mirasçıların, mülkün nasıl davrandığına ve maruz kaldıklarına ilişkin anlambilimlerini değiştirmesine izin veren alıcı / ayarlayıcı yöntemlerini geçersiz kılma.
• Alıcı / ayarlayıcının değerlerden ziyade lambda ifadeleri olarak iletilmesine izin vermek.
• Harfler ve ayarlayıcılar farklı erişim düzeylerine izin verebilir - örneğin erişim herkese açık olabilir, ancak küme korunabilir.

Ayarlayıcının değerin ayarlanmasından daha fazlasını yapması gerektiğini anladığınız andan itibaren 2 hafta (ay, yıl) olduğundan , mülkün doğrudan 238 diğer sınıfta kullanıldığını anlayacaksınız :-)

Ortak alan, alanı döndürmek ve alana atamak dışında hiçbir şey yapmayan bir alıcı / ayarlayıcı çiftinden daha kötü değildir. Birincisi, (çoğu dilde) işlevsel bir fark olmadığı açıktır. Herhangi bir fark, sürdürülebilirlik veya okunabilirlik gibi diğer faktörlerde olmalıdır.

Getter / setter çiftlerinin sıkça bahsedilen bir avantajı değil. Uygulamayı değiştirebileceğiniz ve müşterilerinizin yeniden derlenmesi gerekmediği yönünde bir iddia var. Sözde, ayarlayıcılar daha sonra doğrulama gibi işlevler eklemenize izin verir ve müşterilerinizin bunu bilmesine bile gerek yoktur. Bununla birlikte, bir ayarlayıcıya doğrulama eklemek, ön koşullarında bir değişikliktir , önceki sözleşmenin ihlali , oldukça basit bir şekilde, "buraya bir şey koyabilirsiniz ve aynı şeyi daha sonra alıcıdan alabilirsiniz".

Şimdi, sözleşmeyi kırdığınıza göre, kod tabanındaki her dosyayı değiştirmek, yapmak istemediğiniz bir şeydir, kaçınmak değil. Bundan kaçınırsanız, tüm kodların bu yöntemlere ilişkin sözleşmenin farklı olduğunu varsayarsınız.

Bu sözleşme olmasaydı, arabirim istemcilerin nesneyi geçersiz durumlara koymasına izin veriyordu. Bu, kapsüllemenin tam tersidir Eğer bu alan başlangıçtan itibaren hiçbir şeye ayarlanamazsa, neden başlangıçtan itibaren doğrulama yapılmadı?

Aynı argüman, bu doğrudan alıcı / ayarlayıcı çiftlerinin sözde diğer avantajları için de geçerlidir: daha sonra ayarlanan değeri değiştirmeye karar verirseniz, sözleşmeyi ihlal edersiniz. Türetilmiş bir sınıftaki varsayılan işlevselliği, zararsız birkaç değişikliğin (günlüğe kaydetme veya gözlemlenemeyen diğer davranışlar gibi) ötesinde geçersiz kılarsanız, temel sınıfın sözleşmesini bozarsınız. Bu, OO'nun ilkelerinden biri olarak görülen Liskov Değiştirilebilirlik Prensibinin ihlalidir.

Bir sınıfın her alan için bu aptal alıcıları ve ayarlayıcıları varsa, o zaman herhangi bir değişmezi olmayan, sözleşmesi olmayan bir sınıftır . Bu gerçekten nesne yönelimli bir tasarım mı? Sınıfın tamamı bu alıcılar ve ayarlayıcılarsa, bu sadece aptal bir veri sahibi ve aptal veri sahipleri aptal veri sahipleri gibi görünmelidir:

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

Böyle bir sınıfa doğrudan geçişli alıcı / ayarlayıcı çifti eklemek bir değer katmaz. Diğer sınıflar, yalnızca alanların sağladığı işlemleri değil, anlamlı işlemleri sağlamalıdır. Yararlı değişmezleri bu şekilde tanımlayabilir ve koruyabilirsiniz.

Müşteri : "Bu sınıfın bir nesnesiyle ne yapabilirim?"
Tasarımcı : "Birkaç değişkeni okuyabilir ve yazabilirsiniz."
Müşteri : "Ah ... güzel, sanırım?"

Alıcıları ve ayarlayıcıları kullanmanın nedenleri vardır, ancak bu nedenler mevcut değilse, yanlış kapsülleme tanrıları adına alıcı / ayarlayıcı çiftleri yapmak iyi bir şey değildir. Alıcıları veya belirleyicileri yapmak için geçerli nedenler, daha sonra doğrulama veya farklı dahili temsiller gibi daha sonra yapabileceğiniz potansiyel değişiklikler olarak belirtilenleri içerir. Ya da değer müşteriler tarafından okunabilir ancak yazılabilir olmamalıdır (örneğin, bir sözlüğün boyutunu okumak), bu yüzden basit bir alıcı iyi bir seçimdir. Ancak bu nedenleri, yalnızca daha sonra isteyebileceğiniz potansiyel bir şey olarak değil, seçim yaptığınızda orada olmalıdır. Bu bir YAGNI örneğidir ( Buna ihtiyacınız olmayacak ).

Birçok insan, alıcıların ve pasörlerin avantajlarından bahsediyor, ama şeytanın avukatını oynamak istiyorum. Şu anda programcıların her şeyi hazırlayan ve ayarlayıcı yapmaya karar verdikleri çok büyük bir programda hata ayıklama yapıyorum. Bu hoş görünebilir, ama tersine mühendislik kabusu.

Diyelim ki yüzlerce kod satırına bakıyorsunuz ve bununla karşılaşıyorsunuz:

person.name = "Joe";

Bir ayarlayıcı olduğunu anlayana kadar güzel bir kod parçası. Şimdi, bu ayarlayıcıyı takip edersiniz ve aynı zamanda person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName öğesini ayarlar ve veritabanına bir sorgu gönderen person.update () öğesini çağırırsınız. Oh, bu Hafıza sızıntınızın olduğu yer.

İlk bakışta yerel bir kod parçasını anlamak, alıcıların ve ayarlayıcıların kırılma eğilimi gösteren iyi okunabilirliğin önemli bir özelliğidir. Bu yüzden yapabildiğim zaman onlardan kaçınmaya ve kullandığımda yaptıklarını en aza indirmeye çalışıyorum.

Saf bir nesne yönelimli dünyada, alıcılar ve pasifler korkunç bir anti-modeldir . Bu makaleyi okuyun: Getters / Setters. Kötülük. Dönem . Özetle, programcıları veri yapıları olarak nesneler hakkında düşünmeye teşvik ederler ve bu tür düşünme saf prosedüreldir (COBOL veya C'deki gibi). Nesneye yönelik bir dilde veri yapısı yoktur, sadece davranışı gösteren nesneler vardır (nitelikler / özellikler değil!)

Bunlarla ilgili daha fazla bilgiyi Elegant Objects Bölüm 3.5'te (nesne yönelimli programlama hakkındaki kitabım) bulabilirsiniz.

Bir çok neden var. En sevdiğim, davranışı değiştirmeniz veya bir değişken üzerinde ayarlayabileceğiniz şeyleri düzenlemeniz gerektiğidir. Örneğin, bir setSpeed ​​(int speed) yönteminiz olduğunu varsayalım. Ancak, yalnızca maksimum 100 hız ayarlayabilmenizi istiyorsunuz.

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

Kodunuzda HER YERDE herkese açık alanı kullanıyorduysanız ve yukarıdaki gereksinime ihtiyacınız olduğunu fark ettiyseniz ne olacak? Sadece setterinizi değiştirmek yerine kamusal alanın her kullanımını avlayın.

Benim 2 sent :)

Erişimcilerin ve mutasyon yapanların bir avantajı, doğrulama gerçekleştirebilmenizdir.

Örneğin foo, herkese açık olsaydı , bunu kolayca ayarlayabilirdim nullve sonra başka biri nesne üzerinde bir yöntemi çağırmayı deneyebilirdi. Ama artık orada değil! Bir setFooyöntemle, bunun fooasla ayarlanmadığından emin olabilirdim null.

Erişimciler ve mutasyoncular da kapsüllemeye izin verir - eğer değeri bir kez ayarlandığında (belki de yapıcıda ayarlanır ve daha sonra yöntemlerle kullanılır, ancak asla değiştirilmemesi gerekiyordu) görülmezseniz, asla kimse tarafından görülmez. Ancak, diğer sınıfların görmesine veya değiştirmesine izin verebiliyorsanız, uygun erişimci ve / veya mutatör sağlayabilirsiniz.

Dilinize bağlıdır. "Java" yerine "nesne yönelimli" olarak etiketlediniz, bu yüzden ChssPly76'nın cevabının dile bağlı olduğunu belirtmek isterim. Örneğin Python'da alıcıları ve ayarlayıcıları kullanmak için hiçbir neden yoktur. Davranışı değiştirmeniz gerekirse, temel özellik erişiminin çevresine alıcı ve ayarlayıcıyı saran bir özellik kullanabilirsiniz. Bunun gibi bir şey:

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

Eh, sadece değişkenlerinizin / nesnelerin kapsüllenmesi ve güvenliği için gerekli olsalar bile, gerçek bir Nesne Odaklı Programı kodlamak istiyorsak, o zaman AKSESUARLARI AŞMAK DURMALIYIM , çünkü bazen çok bağımlıyız gerçekten gerekli olmadığında ve bu, değişkenleri herkese açık hale getirmemizle hemen hemen aynıdır.

Teşekkürler, bu düşüncemi gerçekten açıklığa kavuşturdu. Şimdi, alıcıları ve ayarlayıcıları kullanmamak için (neredeyse) 10 (neredeyse) iyi neden:

1. Değeri ayarlamak ve almaktan daha fazlasını yapmanız gerektiğini fark ettiğinizde, alanı özel hale getirebilirsiniz, bu da size doğrudan nereden eriştiğinizi anında söyleyecektir.
   
2. Orada gerçekleştirdiğiniz herhangi bir doğrulama yalnızca bağlamdan bağımsız olabilir; bu, nadiren uygulamada olur.
   
3. Ayarlanan değeri değiştirebilirsiniz - bu, arayan kişi size [şok korkusu] OLDUĞU GİBİ saklamanızı istediği bir değeri ilettiğinde mutlak bir kabus olur.
   
4. Dahili temsili gizleyebilirsiniz - harika, böylece tüm bu işlemlerin simetrik olduğundan emin olursunuz değil mi?
   
5. Genel arayüzünüzü sayfaların altındaki değişikliklerden yalıttınız - bir arayüz tasarlıyorsanız ve bir şeye doğrudan erişimin uygun olup olmadığından emin değilseniz, tasarım yapmaya devam etmeliydiniz.
   
6. Bazı kütüphaneler bunu bekler, ancak çok fazla değil - yansıma, serileştirme, sahte nesneler, ortak alanlarla iyi çalışır.
   
7. Bu sınıfı devralarak, varsayılan işlevselliği geçersiz kılabilirsiniz - başka bir deyişle, yalnızca uygulamayı gizlemekle kalmayıp tutarsız hale getirerek arayanları GERÇEKTEN şaşırtabilirsiniz.
   

Sadece son gittiğim (N / A veya D / C) ...

Biraz geç olduğunu biliyorum, ancak performansla ilgilenen bazı insanlar olduğunu düşünüyorum.

Küçük bir performans testi yaptım. Ben bir tamsayı tutan bir "NumberHolder" sınıfı yazdım. Bu Tamsayı'yı getter yöntemini kullanarak anInstance.getNumber()veya numarayı kullanarak doğrudan erişerek okuyabilirsiniz anInstance.number. Programım her iki yolla da 1.000.000.000 kez okur. Bu işlem beş kez tekrarlanır ve saat yazdırılır. Aşağıdaki sonucu aldım:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(Zaman 1 doğrudan yoldur, Zaman 2 alıcıdır)

Görüyorsunuz, yakalayıcı (neredeyse) her zaman biraz daha hızlıdır. Sonra farklı sayılarla denedim. 1 milyon yerine 10 milyon ve 0,1 milyon kullandım. Sonuçlar:

10 milyon döngü:

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

10 milyon döngü ile süreler neredeyse aynı. İşte 100 bin (0,1 milyon) döngü:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

Ayrıca farklı miktarlardaki döngülerde, alıcı normal yoldan biraz daha hızlıdır. Umarım bu sana yardımcı olmuştur.

Mevcut teslimatınız için gerekli olmadıkça alıcı ayarlayıcılarını kullanmayın Gelecekte ne olacağı hakkında çok fazla düşünmeyin, değiştirilecek herhangi bir şey varsa, çoğu üretim uygulamasında, sistemde bir değişiklik talebidir.

Basit, kolay düşünün, gerektiğinde karmaşıklık katın.

Derin teknik bilginin işletme sahiplerinin bilgisizliğinden faydalanmam, çünkü doğru olduğunu düşündüğüm için ya da yaklaşımı sevdim.

Sadece erişim değiştiricileri ve n mantık işlemini doğrulamak için bazı yöntemler ile alıcılar ayarlayıcıları olmadan yazılmış büyük bir sistemim var. Kesinlikle ihtiyacınız varsa. Herhangi bir şey kullanın.

Alıcıları ve ayarlayıcıları kullanıyoruz:

• yeniden kullanılabilirlik için
• programlamanın ilerleyen aşamalarında doğrulama yapmak

Alıcı ve ayarlayıcı yöntemleri, özel sınıf üyelerine erişmek için ortak arabirimlerdir.

Kapsülleme mantra

Kapsülleme mantrası alanları özel ve yöntemleri herkese açık hale getirmektir.

Alıcı Yöntemleri: Özel değişkenlere erişebiliriz.

Setter Yöntemleri: Özel alanları değiştirebiliriz.

Alıcı ve ayarlayıcı yöntemleri yeni işlevler eklemese de, daha sonra bu yöntemi yapmak için fikrimizi değiştirebiliriz

• daha iyi;
• daha güvenli; ve
• Daha hızlı.

Bir değer kullanılabilecek her yerde, bu değeri döndüren bir yöntem eklenebilir. Onun yerine:

int x = 1000 - 500

kullanım

int x = 1000 - class_name.getValue();

Layman'ın terimleriyle

Bunun ayrıntılarını saklamamız gerektiğini varsayalım Person. Bu Personalanlar vardır name, ageve sex. Bunu yapmak name, ageve için yöntemler oluşturmayı içerir sex. Biz başka bir kişiyi oluşturmak gerekirse Şimdi, için yöntemler oluşturmak için gerekli olur name, age, sexbaştan.

Bunu yapmak yerine, class(Person)alıcı ve ayarlayıcı yöntemleriyle bir fasulye oluşturabiliriz . Yani yarın class(Person class)yeni bir kişi eklememiz gerektiğinde bu fasulyenin nesnelerini yaratabiliriz (şekle bakınız). Böylece fasulye sınıfının alanlarını ve yöntemlerini yeniden kullanıyoruz, ki bu çok daha iyi.

Java davası için bunu düşünerek biraz zaman geçirdim ve asıl nedenlerin olduğuna inanıyorum:

1. Uygulamaya değil, arayüze kod
2. Arabirimler alanları değil, yalnızca yöntemleri belirtir

Başka bir deyişle, arabirimdeki bir alanı belirtmenin tek yolu, yeni bir değer yazmak için bir yöntem ve geçerli değeri okumak için bir yöntem sağlamaktır.

Bu yöntemler rezil alıcı ve ayarlayıcı ....

Tembel yükleme için yararlı olabilir. Söz konusu nesnenin bir veritabanında saklandığını ve ihtiyacınız olmadığı sürece onu almak istemediğinizi varsayalım. Nesne bir alıcı tarafından alınırsa, iç nesne birisi isteyinceye kadar boş olabilir, o zaman onu alıcıya ilk çağrıda alabilirsiniz.

Birkaç farklı web servis çağrısından bazı verileri yükleyen bir projede bana verilen bir temel sayfa sınıfım vardı, ancak bu web servis çağrılarındaki veriler her zaman tüm alt sayfalarda kullanılmadı. Web hizmetleri, tüm faydaları için, yeni "yavaş" tanımlarına öncülük eder, böylece gerekmiyorsa bir web hizmeti çağrısı yapmak istemezsiniz.

Genel alanlardan alıcılara geçtim ve şimdi alıcılar önbelleği kontrol ediyor ve eğer yoksa web servisini arayın. Biraz sargı ile çok sayıda web hizmeti çağrısı engellendi.

Böylece alıcı beni her alt sayfada neye ihtiyacım olacağını anlamaya çalışmaktan kurtarıyor. İhtiyacım olursa, alıcıyı ararım ve eğer zaten yoksa benim için bulmaya gider.

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

Şimdiye kadar cevaplarda kaçırdığım bir yön, erişim belirtimi:

• üyeler için hem ayarlama hem de alma için yalnızca bir erişim belirtiminiz vardır
• ayarlayıcılar ve alıcılar için ince ayar yapabilir ve ayrı olarak tanımlayabilirsiniz

DÜZENLEME: Bu soruyu cevapladım, çünkü bunu soran programlamayı öğrenen bir sürü insan var ve cevapların çoğu teknik olarak yetkin, ancak bir acemi iseniz anlamak kolay değil. Hepimiz yeniydik, bu yüzden elimi daha acemi dostu bir cevapta deneyeceğim diye düşündüm.

İki ana polimorfizm ve validasyon. Sadece aptal bir veri yapısı olsa bile.

Diyelim ki bu basit sınıfımız var:

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

İçinde ne kadar sıvı olduğunu ve kapasitesinin ne olduğunu tutan çok basit bir sınıf (mililitre cinsinden).

Yaptığımda ne olur:

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

Bunun çalışmasını beklemezdin, değil mi? Bir tür akıl sağlığı kontrolünün olmasını istiyorsunuz. Daha da kötüsü, maksimum kapasiteyi hiç belirtmezsem ne olur? Ah canım, bir sorunumuz var.

Ama başka bir sorun daha var. Şişeler sadece bir çeşit konteyner olsaydı ne olurdu? Ya kapasiteleri ve miktarları sıvı dolu olan birkaç kabımız olsaydı? Sadece bir arayüz oluşturabilirsek, programımızın geri kalanının bu arayüzü kabul etmesine izin verebilirdik ve şişeler, bidonlar ve her türlü şey birbirinin yerine kullanılabilirdi. Daha iyi olmaz mıydı? Arayüzler yöntem gerektirdiğinden, bu da iyi bir şeydir.

Sonunda şöyle bir şey buluruz:

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

Harika! Ve şimdi Şişeyi buna değiştiriyoruz:

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

BottleOverflowException tanımını okuyucuya alıştırma olarak bırakacağım.

Şimdi bunun ne kadar daha sağlam olduğuna dikkat edin. Bottle yerine LiquidContainer'ı kabul ederek kodumuzdaki her türlü konteyneri ele alabiliriz. Ve bu şişelerin bu tür şeylerle nasıl başa çıktığı farklı olabilir. Değiştiğinde durumlarını diske yazan şişeleriniz olabilir ya da SQL veritabanlarına veya GNU'ya kaydedilen şişelerin başka neleri bildiğini görebilirsiniz.

Ve tüm bunların çeşitli boğmacalarla başa çıkmanın farklı yolları olabilir. Şişe sadece kontrol eder ve taşarsa bir RuntimeException kurar. Ama bu yanlış bir şey olabilir. (Hata işleme konusunda yararlı bir tartışma var, ancak burada bunu çok basit bir şekilde saklıyorum. Yorumdaki insanlar muhtemelen bu basit yaklaşımın kusurlarını gösterecektir.))

Ve evet, çok basit bir fikirden hızlıca daha iyi cevaplar almaya gittik.

Bir şişenin kapasitesini değiştiremeyeceğinizi lütfen unutmayın. Şimdi taşa konmuş. Bunu son olarak ilan ederek bir int ile yapabilirsiniz. Ancak bu bir liste olsaydı, listeyi boşaltabilir, listeye yeni şeyler ekleyebilir ve böyle devam edebilirsiniz. İç kısımlara dokunmaya erişimi sınırlandıramazsınız.

Herkesin ele almadığı üçüncü şey de var: alıcılar ve ayarlayıcılar yöntem çağrılarını kullanıyor. Bu, diğer her yerde normal yöntemlere benzedikleri anlamına gelir. DTO'lar ve şeyler için garip bir sözdizimine sahip olmak yerine, her yerde aynı şeye sahipsiniz.

"Özellikleri" (C ++, Java) desteklemeyen veya alanları özelliklere (C #) değiştirirken istemcilerin yeniden derlenmesini gerektiren dillerde, get / set yöntemlerini kullanmak daha kolaydır. Örneğin, bir setFoo yöntemine doğrulama mantığı eklemek, bir sınıfın genel arabiriminin değiştirilmesini gerektirmez.

"Gerçek" özellikleri destekleyen dillerde (Python, Ruby, belki Smalltalk?) Yöntem almanın / ayarlamanın anlamı yoktur.

OO tasarımının temel prensiplerinden biri: Kapsülleme!

Size birçok avantaj sağlar, bunlardan biri sahne arkasındaki alıcı / ayarlayıcı uygulamasını değiştirebilmenizdir, ancak bu değerdeki herhangi bir tüketici, veri türü aynı kaldığı sürece çalışmaya devam edecektir.

Aşağıdaki durumlarda alıcıları ve ayarlayıcıları kullanmalısınız:

• Kavramsal bir özellik olan bir şeyle uğraşıyorsunuz, ancak:
  • Dilinizde özellikler (veya Tcl'nin değişken izleri gibi benzer bir mekanizma) yok veya
  • Dilinizin özellik desteği bu kullanım durumu için yeterli değil veya
  • Dilinizin (veya bazen çerçevenizin) deyimsel kuralları, bu kullanım durumu için alıcıları veya ayarlayıcıları teşvik eder.

Bu çok nadiren genel bir OO sorusudur; farklı diller (ve farklı kullanım örnekleri) için farklı cevapları olan dile özgü bir sorudur.

Bir OO teorisi açısından, alıcılar ve ayarlayıcılar işe yaramaz. Sınıfınızın arayüzü, ne olduğu, ne olduğu değil. (Değilse, yanlış sınıfı yazdınız.) Çok basit durumlarda, örneğin bir sınıfın sadece dikdörtgen koordinatlarda bir noktayı temsil ettiği durumlarda, * özellikler arayüzün bir parçasıdır; alıcılar ve ayarlayıcılar sadece bulut. Ancak çok basit durumlarda, ne nitelikler ne de alıcılar ve ayarlayıcılar arayüzün bir parçası değildir.

Başka bir deyişle: Sınıfınızın tüketicilerinin bir spamözelliğiniz olduğunu bile bilmemesi gerektiğine inanıyorsanız, bunu willy-nilly'yi değiştiremezsiniz, ardından onlaraset_spam yöntem vermek yapmak istediğiniz son şeydir.

_{* Bu basit sınıf için bile, xve ydeğerlerinin ayarlanmasına izin vermek istemeyebilirsiniz . Bu gerçekten bir sınıf ise, böyle yöntemler olmamalıdır translate, rotatevb? Eğer dilinizde kayıtlar / yapılar / adlandırılmış tuples olmadığı için bu sadece bir sınıfsa, bu gerçekten OO meselesi değildir…}

Ama hiç kimse genel OO tasarımı yapmıyor. Belirli bir dilde tasarım ve uygulama yapıyorlar. Ve bazı dillerde, alıcılar ve ayarlayıcılar işe yaramaz olmaktan uzaktır.

Dilinizde özellikler yoksa, kavramsal olarak bir nitelik olan, ancak aslında hesaplanan veya doğrulanan vb. Bir şeyi temsil etmenin tek yolu alıcılar ve ayarlayıcılardır.

Dilinizde özellikler olsa bile, bunların yetersiz veya uygunsuz olduğu durumlar olabilir. Örneğin, alt sınıfların bir özniteliğin anlambilimini denetlemesine izin vermek istiyorsanız, dinamik erişime sahip olmayan dillerde, bir alt sınıf bir öznitelik için hesaplanmış bir özelliğin yerini alamaz.

"Ya daha sonra uygulamamı değiştirmek istersem?" soru (hem OP'nin sorusu hem de kabul edilen cevapta farklı ifadelerde birden çok kez tekrarlanır): Bu gerçekten saf bir uygulama değişikliğiyse ve bir öznitelikle başladıysanız, arayüzü etkilemeden bir özelliğe değiştirebilirsiniz. Tabii ki, diliniz bunu desteklemiyorsa. Yani bu yine aynı durum.

Ayrıca, kullandığınız dilin (veya çerçevenin) deyimlerini takip etmek de önemlidir. C # 'da güzel Ruby tarzı kod yazarsanız, sizden başka deneyimli C # geliştiricisi onu okumakta zorlanır ve bu kötüdür. Bazı diller, sözleşmeleri etrafında diğerlerinden daha güçlü kültürlere sahiptir. - ve deyimsel alıcıların nasıl olduğu spektrumunun karşı uçlarında olan Java ve Python'un en güçlü iki kültüre sahip olması tesadüf olmayabilir.

İnsan okuyucuların ötesinde, sözleşmeleri izlemenizi ve istemezseniz hayatınızı zorlaştıracak kütüphaneler ve araçlar olacaktır. Hoj Interface Builder widget'larını ObjC özelliklerinden başka bir şeye ya da belirli Java alay kitaplıklarını alıcılar olmadan kullanmak, hayatınızı daha da zorlaştırıyor. Araçlar sizin için önemliyse, onlarla savaşmayın.

Nesne yönelimi tasarım açısından, her iki alternatif de sınıfların kapsüllenmesini zayıflatarak kodun korunmasına zarar verebilir. Bir tartışma için bu mükemmel makaleyi inceleyebilirsiniz: http://typicalprogrammer.com/?p=23

Getter ve setter yöntemleri erişimci yöntemleridir, yani özel sınıf üyelerini değiştirmek için genellikle genel bir arabirimdir. Bir özelliği tanımlamak için getter ve setter yöntemlerini kullanırsınız. Sınıf içinde yöntemler olarak tanımlasanız bile, alıcı ve ayarlayıcı yöntemlerine sınıf dışındaki özellikler olarak erişirsiniz. Sınıf dışındaki bu özelliklerin, sınıftaki özellik adından farklı bir adı olabilir.

Alıcı ve ayarlayıcı yöntemlerini kullanmanın, benzer özelliklere erişebileceğiniz karmaşık işlevlere sahip üyeler oluşturmanıza izin verme gibi bazı avantajları vardır. Ayrıca salt okunur ve salt yazılır özellikler oluşturmanıza da olanak tanır.

Alıcı ve ayarlayıcı yöntemleri yararlı olsa da, bunları aşırı kullanmamaya dikkat etmelisiniz, çünkü diğer sorunların yanı sıra, kod bakımını belirli durumlarda daha zor hale getirebilirler. Ayrıca, genel üyeler gibi sınıf uygulamanıza erişim sağlarlar. OOP uygulaması, bir sınıf içindeki özelliklere doğrudan erişimi engeller.

Sınıf yazarken, her zaman örnek değişkenlerinizi mümkün olduğunca özel hale getirmeniz ve buna göre alıcı ve ayarlayıcı yöntemleri eklemeniz önerilir. Bunun nedeni, kullanıcıların sınıflarınızdaki belirli değişkenleri değiştirmesine izin vermek istemeyebileceğiniz birkaç kez olmasıdır. Örneğin, belirli bir sınıf için oluşturulan örnek sayısını izleyen özel bir statik yönteminiz varsa, kullanıcının bu sayacı kod kullanarak değiştirmesini istemezsiniz. Yalnızca yapıcı ifadesi çağrıldığında bu değişkeni artırmalıdır. Bu durumda, özel bir örnek değişkeni oluşturabilir ve yalnızca sayaç değişkeni için bir alıcı yöntemine izin verebilirsiniz; bu, kullanıcıların geçerli değeri yalnızca alıcı yöntemini kullanarak alabilecekleri ve yeni değerler ayarlayamayacakları anlamına gelir. setter yöntemini kullanarak.

Kod gelişir . veri üyesi korumasına ihtiyacınızprivate olduğunda mükemmeldir . Sonunda tüm sınıflar iyi tanımlanmış bir arayüze sahip bir çeşit "miniprogram" olmalıdır . .

Bununla birlikte, yazılım geliştirme , sınıfın son versiyonunu, ilk denemede bir miktar dökme demir heykeline basıyormuş gibi ayarlamakla ilgili değildir. Onunla çalışırken, kod daha çok kil gibidir. Siz geliştirdikçe ve çözdüğünüz problem alanı hakkında daha fazla bilgi edindikçe gelişir . Gelişim sırasında sınıflar birbirleriyle etkileşime girmeleri gerekenden (çarpanlarına ayırmayı planladığınız bağımlılık), birleşerek veya bölünebilirler. Bence bu tartışma dini olarak yazmak istemeyen insanlara dayanıyor

int getVar() const { return var ; }

Yani:

doSomething( obj->getVar() ) ;

Onun yerine

doSomething( obj->var ) ;

Sadece getVar()görsel olarak gürültülü olmakla kalmaz, gettingVar()bir şekilde gerçekte olduğundan daha karmaşık bir süreçtir. (Sınıf yazarı olarak) kutsallığı varnasıl değerlendirdiğinizi, bir passthru ayarlayıcı varsa, sınıfınızın bir kullanıcısı için özellikle kafa karıştırıcıdır - o zaman bu kapıları değerli ısrar etmek için "korumak" gibi görünüyor, (ancak kutsallığını koruduğunuzda varbile) var, kimsenin set varne yaptıklarına bakmadan, içeri girme ve istedikleri değere sahip olma yeteneğiyle çok fazla değmez .

Bu yüzden aşağıdaki gibi program (bir "çevik" tipi yaklaşım varsayalım - yani tam olarak ne yapacağını bilmeden kod yazarken / ayrıntılı bir şelale tarzı arayüz seti planlamak için zaman veya deneyimim yok):

1) Veri ve davranışa sahip temel nesneler için tüm kamu üyeleri ile başlayın. Bu yüzden tüm C ++ "örnek" kodumda beni her yerde kullanmak structyerine fark edeceksiniz class.

2) Bir nesnenin bir veri üyesi için iç davranışı yeterince karmaşık hale geldiğinde (örneğin, bir iç std::listdüzeni bir tür düzende tutmayı sever ), erişimci türü işlevleri yazılır. Ben kendim programlama ediyorum çünkü ben her zaman üye set yok privatehemen, ama sınıf üyesi evrimi aşağı bir yere "terfi" olacak ya protectedyaprivate .

3) tamamen fleshed ve donanımları hakkında katı kurallar (yani sahiptir Sınıflar onlar yaptıklarını tam olarak bilmek ve "lanet" (teknik terim için değildir) verilmiştir onun iç elemanlar) classtanımı, özel üyelerini varsayılan, ve yalnızca seçili birkaç üyenin olmasına izin verilir public.

Bu yaklaşımın, bir sınıfın evriminin ilk aşamalarında, çok sayıda veri üyesi göç ettiğinde, etrafında değiştiğinde vb.

Erişimcileri kullanmayı düşünmek için iyi bir sebep var, mülk mirası yok. Sonraki örneğe bakın:

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

Çıktı:

0
0
4

Harfler ve ayarlayıcılar , Nesneye Yönelik Programlamanın temel yönlerinden ikisini uygulamak için kullanılır:

1. Soyutlama
2. kapsülleme

Bir Çalışan sınıfımız olduğunu varsayalım:

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

Burada Tam Ad'ın uygulama ayrıntıları kullanıcıdan gizlenir ve genel bir öznitelikten farklı olarak doğrudan kullanıcı tarafından erişilebilir değildir.

Diğer bir kullanım (özellikleri destekleyen dillerde) ayarlayıcıların ve alıcıların bir işlemin önemsiz olduğunu ima edebilmeleridir. Genellikle, bir mülkte hesaplama açısından pahalı olan herhangi bir şey yapmaktan kaçınmak istersiniz.

Alıcıların / ayarlayıcıların nispeten modern bir avantajı, etiketli (dizinlenmiş) kod editörlerinde koda göz atmayı kolaylaştırmasıdır. Örneğin, bir üyeyi kimin ayarladığını görmek istiyorsanız, ayarlayıcının arama hiyerarşisini açabilirsiniz.

Öte yandan, üye herkese açıksa, araçlar üyeye okuma / yazma erişimini filtrelemeyi mümkün kılmaz. Bu yüzden üyenin tüm kullanımları olsa trudge gerekir.

Nesneye yönelik bir dilde yöntemler ve bunların erişim değiştiricileri, o nesnenin arabirimini bildirir. Yapıcı ile erişimci ve mutasyona uğratıcı yöntemler arasında geliştiricinin bir nesnenin iç durumuna erişimi kontrol etmesi mümkündür. Değişkenler yalnızca kamuya açıklanırsa, bu erişimi düzenlemenin bir yolu yoktur. Ayarlayıcıları kullanırken, kullanıcıyı ihtiyacımız olan girdi için kısıtlayabiliriz. Bu çok değişkenin beslemesinin uygun bir kanaldan geleceği ve kanal bizim tarafımızdan önceden tanımlandığı anlamına gelir. Bu yüzden ayarlayıcıları kullanmak daha güvenlidir.

Ayrıca bu, sınıfınızı "geleceğe dönük" hale getirmektir. Özellikle, bir alandan bir mülke geçmek bir ABI molasıdır, bu yüzden daha sonra sadece "alanı ayarla / al" dan daha fazla mantığa ihtiyacınız olduğuna karar verirseniz, elbette herhangi bir şey için sorun yaratan ABI'yi kırmanız gerekir. sınıfınıza karşı derlenmiş başka.

Sadece ek açıklama fikrini atmak istiyorum: @getter ve @setter. @Getter ile obj = class.field = class.field = obj komutunu kullanamamanız gerekir. @Setter ile, tam tersi. @Getter ve @setter ile her ikisini de yapabilmeniz gerekir. Bu, çalışma zamanında önemsiz yöntemleri çağırmayarak kapsüllemeyi koruyacak ve zamanı azaltacaktır.