Getters ve Setters ne zaman haklı

Alıcı ve ayarlayıcılar genellikle uygun OO olmadığından eleştirilir. Öte yandan, gördüğüm çoğu OO kodunun geniş alıcıları ve belirleyicileri var.

Alıcılar ve belirleyiciler ne zaman haklı çıkar? Bunları kullanmaktan kaçınmaya çalışıyor musunuz? Genelde aşırı mı kullanılıyor?

En sevdiğiniz dil özelliklere sahipse (benimki) bu tür şeyler de bu soru için alıcılar ve belirleyiciler olarak kabul edilir. OO metodolojisi açısından aynı şeylerdir. Onlar sadece daha güzel sözdizimi var.

Alıcı / Belirleyici Eleştirisi Kaynakları (bazıları daha iyi görünürlük sağlamak için yorumlardan alınmıştır):

• http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
• http://typicalprogrammer.com/?p=23
• http://c2.com/cgi/wiki?AccessorsAreEvil
• http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm
• http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and
• http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

Eleştiriyi basitçe ifade etmek için: Alıcılar ve Düzenleyiciler, nesnelerin iç durumunu nesnenin dışından değiştirmenize olanak tanır. Bu kapsülleme ihlal ediyor. Sadece nesnenin kendisi içsel durumu önemsemelidir.

Ve örnek bir Prosedür kod sürümü.

struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}

Kodun mutator sürümü:

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

Alıcılar ve belirleyiciler, uygun kapsülleme sağlamadan kodu daha karmaşık hale getirdi. İçsel durum başka nesneler için erişilebilir olduğundan, bu alıcıları ve ayarlayıcıları ekleyerek çok fazla kazanamayız.

Soru daha önce Yığın Taşması ile tartışıldı:

• https://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil
• https://stackoverflow.com/questions/996179

Alıcıların ve ayarlayıcıların olması kendi başına enkapsülasyonu bozmaz. Kapsüllemeyi bozan , herhangi bir düşünce yapmadan, her veri üyesi için ( java lingo'daki her alan ) otomatik olarak bir alıcı ve ayarlayıcı eklemektir . Bu, tüm veri üyelerini halka açıklamaktan daha iyi olsa da, sadece küçük bir adım.

Kapsülleme meselesi, nesnenin durumunu nesnenin dışından tanıyamayacağınız veya değiştirebilmeniz değil, bunun için makul bir politikaya sahip olmanız gerektiğidir .

• Bazı veri üyeleri tamamen nesnenin içinde olabilir ve alıcıları veya ayarlayıcıları olmamalıdır.

• Bazı veri üyeleri salt okunur olmalıdır, bu nedenle alıcılara ihtiyaç duyabilir ancak ayarlayıcılara gerek kalmayabilir.

• Bazı veri üyelerinin birbirleriyle tutarlı tutulması gerekebilir. Böyle bir durumda, her birine bir ayarlayıcı sağlayamazsınız, aynı anda bunları ayarlamak için tek bir yöntem kullanırsınız, böylece tutarlılık için değerleri kontrol edebilirsiniz.

• Bazı veri üyelerinin, sabit bir miktarda artırılması veya azaltılması gibi yalnızca belirli bir şekilde değiştirilmesi gerekebilir. Bu durumda, bir belirleyici yerine, increment()ve / veya bir decrement()yöntem sağlarsınız.

• Yine de başkalarının okuma yazma yazması gerekebilir ve hem alıcı hem de ayarlayıcı olur.

Bir örneğini düşünün class Person. Birinin bir ismi, sosyal güvenlik numarası ve yaşı olduğunu varsayalım. Diyelim ki insanların isimlerini veya sosyal güvenlik numaralarını değiştirmelerine izin vermeyiz. Ancak, kişinin yaşı her yıl 1 artırılmalıdır. Bu durumda, adı ve SSN'yi verilen değerlere başlatacak ve yaşını 0'a başlatacak bir kurucu sağlayacaksınız. Ayrıca incrementAge(), yaşı 1'e çıkaracak bir yöntem de sunacaksınız. üçü için alıcılar. Bu durumda ayarlayıcı gerekmez.

Bu tasarımda nesnenin durumunun sınıf dışından kontrol edilmesine izin verirsiniz ve sınıf dışından değiştirilmesine izin verirsiniz. Ancak, devletin keyfi olarak değiştirilmesine izin vermezsiniz. İsmin ve SSN'nin hiçbir şekilde değiştirilemeyeceğini ve yaşın bir kerede 1 yıl artırılabileceğini etkili bir şekilde belirten bir politika var.

Şimdi bir kişinin de maaşı olduğunu varsayalım. Ve insanlar istedikleri zaman işleri değiştirebilir, bu da maaşlarının da değişeceği anlamına gelir. Bu durumu modellemek için başka bir setSalary()yöntemimiz yok! Maaşın istenildiği zaman değiştirilmesine izin vermek, bu durumda tamamen makul bir politikadır.

Bu arada, senin örnekte, ben sınıfını verecek ve yerine yöntemleri ve . O zaman hala kapsülleme yapardın.FridgeputCheese()takeCheese()get_cheese()set_cheese()

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

Java’da alıcıların ve belirleyicilerin temel nedeni çok basittir:

• Arabirimde yalnızca yöntemleri değil yöntemleri belirleyebilirsiniz .

Bu nedenle, bir alanın arayüzden geçmesine izin vermek istiyorsanız, bir okuyucuya ve bir yazar yöntemine ihtiyacınız olacaktır. Bunlara geleneksel olarak x alanı için getX ve setX adı verilir.

Gönderen http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and

JavaBean tarzı:

connection.setUser("dukie");
connection.setPwd("duke");
connection.initialize();

OO tarzı:

connection.connect("dukie","duke");

Açıkçası, ikinci yaklaşımı tercih ediyorum; Uygulama ayrıntılarını akıtmaz, daha basit ve daha özlüdür ve tüm gerekli bilgiler yöntem çağrısına dahil edilmiştir, bu nedenle doğru olması daha kolaydır. Ayrıca, mümkün olduğunda, yapıcıdaki parametreleri kullanarak özel üyeler ayarlamayı tercih ederim.

Sorunuz, alıcı / alıcı ne zaman haklı? Belki bir mod değişikliğine ihtiyaç duyulduğunda veya bazı bilgiler için bir nesneyi sorgulamanız gerektiğinde.

myObject.GetStatus();
myObject.SomeCapabilitySwitch = true;

Bunu düşünürken, C # 'da ilk kez kodlamaya başladığımda, yukarıda gösterilen Javabeans tarzında çok fazla kod yazdım. Ancak, dil konusunda deneyim kazandıkça, kurucuda daha çok üye belirleme yapmaya ve yukarıdaki OO stiline daha çok benzeyen yöntemleri kullanmaya başladım.

Alıcılar ve belirleyiciler ne zaman haklı çıkar?

"Get" ve "set" davranışları aslında modelinizdeki davranışlarla eşleştiğinde, pratikte hiçbir zaman değildir .

Diğer her kullanım sadece bir aldatmacadır, çünkü işletme alanının davranışları açık değildir.

Düzenle

Bu cevap saygısız olarak ortaya çıkmış olabilir, bu yüzden genişleyeyim. Yukarıdaki cevaplar çoğunlukla doğrudur, ancak OO tasarımının programlama paradigmalarına ve bazıları da büyük resmi özleyenlere odaklanmaktadır. Tecrübelerime göre bu, insanların kazanımlardan ve belirleyicilerden kaçınmanın OO programlama dilleri için bazı akademik kurallar olduğunu düşünmelerini sağlar (örneğin, alıcıların özelliklerle özelliklerinin değiştirilmesinin büyük olduğunu düşünür)

Aslında bu tasarım sürecinin bir sonucudur. Bu paradigmaları kırıp kırmadığını ve iyi OO programlamanın ne olup olmadığını tartışarak arayüzlere, kapsülleme ve kalıplara girmeniz gerekmez. Nihayetinde önemli olan tek şey, etki alanınızda bu şekilde çalışan bir şey yoksa, bunları size koyarak, etki alanınızı modellemiyor olmanızdır.

Gerçek şu ki, etki alanınızdaki herhangi bir sistemin alıcıları ve ayarlayıcıları olması pek olası değildir. Maaş bordrosundan sorumlu olan kadın veya erkeğe yürüyemez ve "Bu maaşı X'e ayarla" veya "Bana bu maaşı al " diyemezsiniz . Böyle bir davranış basitçe mevcut değil

Bunu kodunuza ekliyorsanız, sisteminizi etki alanınızın modeline uygun şekilde tasarlamıyorsunuzdur. Evet, bu arayüzleri ve enkapsülasyonu kırar, ama mesele bu değil. Mesele şu ki, var olmayan bir şeyi modelliyorsun.

Muhtemelen önemli bir adım ya da süreci kaçırıyorsunuzdur, çünkü büyük olasılıkla ödeme yapmak için yürüyemem ve bu maaşın X olarak ayarlandığını söylememin bir nedeni vardır.

İnsanlar alıcıları ve ayarlayıcıları kullandıklarında, bu işlem için kuralları yanlış yere itme eğilimindedirler. Bu etki alanınızdan daha da uzaklaşıyor. Gerçek dünya örneğini kullanarak, içeri giren rastgele birinin bu değerleri alma iznine sahip olduğunu kabul etmek, aksi halde onlardan ricada bulunmayacağını kabul etmek gibidir. Sadece alan değil, alanın nasıl olduğu konusunda da yalan söylüyor.

Genel bir kural olarak, alıcılar ve belirleyiciler kötü bir fikirdir. Bir alan mantıksal olarak arayüzün bir parçası değilse ve onu özel yaparsanız, sorun değil. Mantıken arayüzün bir parçasıysa ve herkese açık yaparsanız, sorun değil. Ancak, bir özel ve daha sonra bir alıcı ve ayarlayıcı sağlayarak arkanı dönüp etkin bir şekilde halka açtırırsanız, kodunuzun artık daha ayrıntılı ve şaşkın olması dışında başladığınız yere geri dönersiniz.

Açıkçası, istisnalar var. Java'da arayüzleri kullanmanız gerekebilir. Java standart kütüphanesi, normal kod kalitesi ölçümlerinden daha ağır basacak kadar ileri düzeyde geriye dönük uyumluluk gereksinimlerine sahiptir. Aslında efsanevi durumla başa çıkmanız bile mümkündür, ancak nadir bir durum olması durumunda, daha sonra arayüzü kırmadan, depolanan bir alanı anında hesaplamanızla değiştirebilirsiniz. Ancak bunlar istisnalar. Alıcı ve ayarlayıcılar özel gerekçelendirme gerektiren bir kalıptır.

Alanın doğrudan mı yoksa yöntem yoluyla mı erişilebilir olduğu gerçekten önemli değil.

Sınıf değişmezleri (faydalı olanlar) önemlidir. Ve onları korumak için, bazen dışardan bir şeyi değiştirmememiz gerekmiyor. Örneğin. Ayrı genişliği ve yüksekliği olan Kare sınıfımız varsa, bunlardan birini değiştirmek onu kare dışında bir şey haline getirir. Bu yüzden yöntem değişikliğine ihtiyacımız varSide Dikdörtgen ise, ayarlayıcılarımıza / genel alana sahip olabiliriz. Ancak ayarlayıcı, sıfırdan büyük olanın daha iyi olup olmadığını test edecek.

Ve somut dillerde (örneğin, java) bu yöntemlere (arabirimler) ihtiyaç duymamızın nedenleridir. Ve yöntemin bir başka nedeni de uyumluluktur (kaynak ve ikili). Bu yüzden onları eklemek daha kolay, sonra kamuya açık alanın yeterli olup olmadığını düşünün.

Btw. Halka açık alanlara sahip, değişmez basit değer tutma sınıfları kullanmayı seviyorum.

Arayüzleri aynı tutarken içindekileri ne olursa olsun ile değiştirmek isteyebilirsiniz. Arabirimleriniz değişmezse, kodlamanız gerekmez. İçini istediğin gibi değiştirebilirsin.

Benim yaklaşımım bu -

Daha sonra verilerle uğraşmayı beklediğimde, bir alıcı / alıcı belirlenir. Ayrıca, değişiklik oluyorsa, genellikle verileri alıcı / ayarlayıcıya iletirim.

Eğer bu bir POD yapısıysa, yuvaları boş bırakıyorum.

Daha soyut bir düzeyde, soru “verileri kimin yönettiği” dir ve bu projeye bağlıdır.

Alıcıları ve ayarlayıcıları kullanmak karmaşıklaşıyorsa, sorun kavramın kendisi değil de dil olabilir.

İşte Ruby'de yazılmış ikinci örnekteki kod :

class Fridge
  attr_accessor :cheese
end

def go_shopping fridge
  fridge.cheese += 5
end

Java'daki ilk örneğe çok benziyor mu? Alıcılar ve belirleyiciler birinci sınıf vatandaşlar olarak muamele gördüklerinde, kullanmaya alışkanlık değillerdir ve ilave esneklik bazen gerçek bir nimet olabilir - örneğin, yeni bir buzdolabında peynir için varsayılan bir değer döndürmeye karar verebiliriz:

class Fridge
  attr_accessor :cheese

  def cheese
    @cheese || 0
  end
end

Elbette herkese açık olarak gösterilmemesi gereken birçok değişken olacak. Gereksiz yere dahili değişkenleri açığa çıkarmak kodunuzu daha da kötüleştirir, ancak alıcıları ve ayarlayıcıları zorla suçlayabilirsiniz.

SizeGenişliği ve yüksekliği kaplayan bir sınıf düşünün . Yapıcıyı kullanarak ayarlayıcıları ortadan kaldırabilirim ama bu nasıl bir dikdörtgen çizmeme yardımcı oluyor Size? Genişlik ve yükseklik sınıfa dahil olan iç veriler değildir; Boyut tüketicileri için olması gereken paylaşılan verilerdir.

Nesneler davranışlardan ve durum - veya niteliklerden oluşur. Maruz kalan bir devlet yoksa, sadece davranışlar halka açıktır.

Devlet olmadan, bir nesne koleksiyonunu nasıl sıralarsınız? Bir nesnenin belirli bir örneğini nasıl ararsınız? Yalnızca yapıcılar kullanırsanız, nesnenizde uzun bir öznitelik listesi olduğunda ne olur?

Hiçbir yöntem parametresi doğrulama olmadan tüketilmemelidir. Bu nedenle yazmak tembelliktir:

setMyField(int myField){
    this.myField = myField;
}

Bu şekilde yazarsanız, en azından ayarlayıcıyı doğrulama için kullanmaya hazırlandınız; halka açık bir alandan daha iyidir - ancak ancak. Ancak en azından, müşterilerinizin kodunu kırmadan geri gelip geçerlilik kuralları koyabileceğiniz tutarlı bir ortak arayüze sahipsiniz.

Alıcılar, ayarlayıcılar, mülkler, mutasyonlar, onlara ne yapacağınızı söyleyin ama onlar gerekli.

Alıcılar ve belirleyiciler, kapsülleme ve gerçek OO'yu ihlal ederse, o zaman başım derde girer.

Her zaman bir nesnenin, yapmanız gereken akla en iyi gelen şeyi temsil ettiğini hissettim.

Java'da Labirent üreten bir program yazmayı bitirdim ve “Labirent Kareleri” ni temsil eden bir sınıfım var. Bu sınıfta koordinatları, duvarları ve boolelleri vb. Temsil eden veriler var.

Bu verileri değiştirmek / değiştirmek / değiştirmek için bir yolum olmalı! Alıcı ve ayarlayıcı olmadan ne yapabilirim? Java özellikleri kullanmaz ve bu sınıfa yerel olan tüm verilerimi herkese açık olarak ayarlama, KESİNLİKLE bir kapsülleme ve OO ihlalidir.

Öncelikle, yorumlayacağım iki tür nesne vardır: değer ve hizmet türleri.

Hizmet türleri asla ayarlayıcılara sahip olmamalı, ihtiyaç duydukları bağımlılık ne olursa olsun elde edilememelidir. Bağımlılıkları geçmenin en iyi yolu, tüm örneklerin başlangıçtan itibaren tamamen düz, basit bir şekilde oluşturulduğu bir kurucu ya da fabrika aracılığıyladır.

Değer türleri de değişmez olmalıdır, diğer taraftan, bunun ORM gibi pratik olmadığı veya bir widget'tan nesneye gibi başka bir eşlemenin olduğu zamanlar vardır. Sistemin etrafında bir katmandan veya bir parçadan diğerine geçen diğer tüm değer tipleri değişmez olmalı ve ayarlayıcılara sahip olmamalıdır.

Bir Getter / Setter, başka herhangi bir kamu yönteminin haklı olduğu gibi haklı. Gerekçe temelde, sınıfımızın diğer sınıflarla nasıl etkileşime girdiğini tanımlayan dış dünyaya bir arayüz sağlamak istediğimizdir. Bunu esas olarak yapıyoruz, çünkü ayrı varlıklar arasındaki eşleşmeyi azaltmak istiyoruz. Bağlantının azaltılması birçok nedenden dolayı iyi bir şeydir:

• Şu anki kodumdan aynı sınıf arayüzünü kullanabilirim, ancak bu arada sınıf yeni yöntemler ekledi (ancak eski arayüzü korudu).
• Bir sınıfın iç temsilini, tüketicilerini etkilemeden değiştirebilir
• Hata olasılığını azaltın: dahili verilerinizi özel yaparsanız, harici kodun dahili verilerinizle karışmayacağından emin olabilirsiniz

Evet, alıcılar ve ayarlayıcılar nesne yönelimli programlamada anti-paterndir ve asla kullanılmamalıdır: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html . Özetle, nesneye yönelik paradigmaya uymuyorlar çünkü bir nesneyi veri yapısı gibi ele almanızı teşvik ediyorlar. Bu büyük bir yanılgıdır.

Programlama dilinizi otomatik olarak geliştiren firma tarafından geliştirilen IDE'nin "Nesne Oryantasyonunun Prensipleri" ni ihlal etmediğini umuyorum.

Demek ki, ne zaman kamuya açık bir değişkene sahipseniz, bir alıcı ve bir alıcı kullanın ve altınsınız. Son derece nesne yönelimli kapsülleme ilkesinin gerekli unsuru gibi görünüyor - çok fazla önemsiz kod gibi görünse bile.

Bunları kullanmanın nedeni, doğru kapsüllemenin henüz gerçekleşmiş olabileceği ve nesnenizle birlikte maymun mayının nesnesini hissetmesini sağlayan tabakayı soyutladığınız sürece, nesneyi haklı bile bilmeden kaldırabileceğiniz mi?

Söylemek yeterli, bölünmüş bir ev dayanamıyor, OO'nun kiracılarından biri kendiliğinden açılmıyor ve hem kapsülleme hem de erken optimizasyona hizmet edemiyorsunuz.

Burada daha genel cevaplar alacağımızı düşündüm

Alıcılar ve ayarlayıcılar genel olarak son derece OOP'dur (herhangi bir şeyin yanlış olduğunu söyleyen herhangi biri, bu kadar basit).

Aşırı mühendis olmadığınızı hatırlamanız gerekse de, asla gerekmeyen bir alıcı veya ayarlayıcı yapmayın. Başka bir sınıf tarafından kullanmayacağınız herhangi bir bilgi için, alıcı veya ayarlayıcınız olmamalıdır.

Bununla birlikte, alanları kamuya açmamanın ve bunun yerine alıcıların ve ayarlayıcıların olmasının nedeni çoğunlukla:

• Alanları kullanarak uygun testler yapmak mümkün değildir. Alıcılar / alıcılar bu konuda çok daha iyi.

• Alanları gerçek zamanlı programlama ortamında doğru kullanmak imkansızdır. Senkronize alıcı / ayarlayıcılar gitme yoludur.

• Arabirim konusu (zaten açıklanmayacağım, açıklamayacağım)

• Sistemi doğru bir şekilde yeniden kullanırken kullanımı daha kolaydır.

• Sınıfınızı kullanan hangi sınıfları ve bir alanı bir alıcı / ayarlayıcıdan daha fazla değiştirirseniz neyin kırılacağını bilmek çok daha zordur.

Bu yüzden, alıcı / belirleyici yerine halka açık bir alan kullandığınız tek zaman resmi bir proje yapmadığınız, bunun yerine sadece eğlence için yaptığınız ve alıcı / belirleyicileri rahatsız edemediğiniz zamandır.