Bir pasör dönüşü “bu” yapmak kötü bir uygulama mudur?

Java seters "bu" dönmek yapmak iyi ya da kötü bir fikir mi?

public Employee setName(String name){
   this.name = name;
   return this;
}

Bu desen yararlı olabilir çünkü daha sonra bu gibi ayarlayıcıları zincirleyebilirsiniz:

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

bunun yerine:

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

... ama standart sözleşmeye aykırı. Sanırım bu ayarlayıcının başka bir şey yapmasını sağlayabilir. Bu kalıbın bazı yerlerde (ör. JMock, JPA) kullanıldığını gördüm, ancak nadir görünüyor ve genellikle bu kalıbın her yerde kullanıldığı çok iyi tanımlanmış API'ler için kullanılıyor.

Güncelleme:

Açıkladığım şey açıkça geçerli, ama gerçekten aradığım şey bunun genel olarak kabul edilebilir olup olmadığı ve herhangi bir tuzak veya ilgili en iyi uygulamalar olup olmadığı hakkında bazı düşünceler. Builder desenini biliyorum ama ne tarif ettiğimden biraz daha ilgili - Josh Bloch'un tanımladığı gibi, nesne oluşturma için ilişkili bir statik Builder sınıfı var.

Özellikle yanlış bir şey olduğunu sanmıyorum, sadece bir stil meselesi. Aşağıdaki durumlarda yararlıdır:

• Aynı anda birçok alan ayarlamanız gerekir (inşaat dahil)
• kodu yazarken hangi alanları ayarlamanız gerektiğini biliyorsunuz ve
• hangi alanları ayarlamak istediğinizin birçok farklı kombinasyonu vardır.

Bu yönteme alternatifler şunlar olabilir:

1. Bir mega yapıcı (olumsuz: çok sayıda boş değer veya varsayılan değer iletebilirsiniz ve hangi değerin neye karşılık geldiğini bilmek zorlaşır)
2. Birkaç aşırı yüklenici (olumsuz: birkaç taneden fazlasına sahip olduğunuzda kullanışsız olur)
3. Fabrika / statik yöntemler (olumsuz: aşırı yüklü inşaatçılar ile aynı - birkaç taneden fazla olduğunda kötüleşir)

Bir seferde sadece birkaç özellik ayarlayacaksanız, 'bu' döndürmeye değmez diyebilirim. Daha sonra bir durum / başarı göstergesi / mesajı gibi başka bir şey döndürmeye karar verirseniz kesinlikle düşer.

Kötü bir uygulama değil. Giderek yaygınlaşan bir uygulamadır. Çoğu dil, "normal" ayarlayıcı kullanım sözdizimini değiştirmez, ancak ayarlayıcıları birbirine zincirlemenize izin verirse, döndürülen nesneyle ilgilenmenizi gerektirmez.

Buna genellikle bir yapıcı modeli veya akıcı bir arayüz denir .

Java API'sında da yaygındır:

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

Özetlemek:

• buna "akıcı arayüz" veya "yöntem zinciri" denir.
• Bu "standart" Java değildir, ancak bu günlerde daha fazla görüyorsunuz (jQuery'de harika çalışıyor)
• JavaBean spesifikasyonlarını ihlal ettiğinden, özellikle JSP oluşturucuları ve Spring olmak üzere çeşitli araçlar ve kütüphanelerle kırılacaktır.
• JVM'nin normalde yapacağı bazı optimizasyonları engelleyebilir
• bazı insanlar kodları temizlediğini, bazıları ise "korkunç" olduğunu düşünüyor

Bahsetilmeyen birkaç nokta daha:

• Bu, her işlevin bir (ve yalnızca bir) şey yapması gerektiği ilkesini ihlal eder. Buna inanabilir veya inanmayabilirsiniz, ancak Java'da iyi çalıştığına inanıyorum.

• IDE'ler bunları sizin için oluşturmayacak (varsayılan olarak).

• Sonunda, işte gerçek dünya veri noktası. Böyle bir kütüphane kullanmakta sorunlar yaşadım. Hazırda Beklet'in sorgu oluşturucusu, varolan bir kitaplıkta buna bir örnektir. Query'nin set * yöntemleri sorguları döndürdüğünden, yalnızca imzayı nasıl kullanacağına bakarak söylemek imkansızdır. Örneğin:

  Query setWhatever(String what);

• Bir belirsizlik getirir: yöntem geçerli nesneyi (deseninizi) değiştirir mi, yoksa Query gerçekten değişmezdir (çok popüler ve değerli bir model) ve yöntem yenisini döndürür. Sadece kütüphanenin kullanımını zorlaştırır ve birçok programcı bu özellikten yararlanmaz. Seterler seters olsaydı, nasıl kullanılacağı daha açık olurdu.

Bunun için 'ile' yöntemleri kullanmayı tercih ediyorum:

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

Böylece:

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

Uyarı : Bu withXsözdizimi, değişmez nesneler için "ayarlayıcılar" sağlamak için yaygın olarak kullanılır; Belki daha makul bir ifade şöyle olabilir:

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

ChainsetXyz () adlandırma kuralıyla neredeyse herkes mutlu olmalıdır.

'this'Ayarlayıcıdan dönmek istemiyorsanız ancak ikinci seçeneği kullanmak istemiyorsanız, özellikleri ayarlamak için aşağıdaki sözdizimini kullanabilirsiniz:

list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

Bir kenara ben C # biraz temiz düşünüyorum:

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

Yalnızca alıcıların / ayarlayıcıların kurallarını ihlal etmekle kalmaz, aynı zamanda Java 8 yöntemi referans çerçevesini de ihlal eder. MyClass::setMyValuebir BiConsumer<MyClass,MyValue>, ve myInstance::setMyValuebir Consumer<MyValue>. Setter dönüşünüz varsa this, artık geçerli bir örneği Consumer<MyValue>değil, a yerine geçer Function<MyValue,MyClass>ve bu ayarlayıcılara (geçersiz yöntemler oldukları varsayılarak) yöntem referanslarını kullanan herhangi bir şeyin bozulmasına neden olur.

Java bilmiyorum ama bunu C ++ ile yaptım. Diğer insanlar satırları okumayı gerçekten uzun ve gerçekten zorlaştırdığını söylediler, ama bunu defalarca yaptım:

list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));

Bu daha da iyi:

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

en azından bence. Ama sen beni alçaltıp bana korkunç bir programcı diyebilirsin. Ve bunu Java'da bile yapmanıza izin verilip verilmediğini bilmiyorum.

'Akıcı arayüz' olarak adlandırılan bu şema (cinayet amaçlı) şimdi oldukça popüler hale geliyor. Kabul edilebilir, ama gerçekten benim fincan çayım değil.

Hiçlik döndürmediği için, artık geçerli bir JavaBean özellik ayarlayıcısı değil. Görsel "Bean Builder" araçlarını kullanan dünyanın yedi kişisinden veya JSP-bean-setProperty öğelerini kullanan 17 kişiden biri olmanız önemli olabilir.

En azından teoride , çağrılar arasında yanlış bağımlılıklar ayarlayarak JVM'nin optimizasyon mekanizmalarına zarar verebilir.

Sözdizimsel şeker olması gerekiyordu, ancak aslında süper akıllı Java 43'ün sanal makinesinde yan etkiler yaratabilir.

Bu yüzden hayır oyu veriyorum, kullanma.

Hiç de kötü bir uygulama değil. Ancak JavaBeans Spec ile uyumlu değildir .

Ve bu standart erişimcilere bağlı çok fazla özellik var.

Onları her zaman birbirine birlikte yaşayabilirsiniz.

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

Şimdi onları birlikte kullanabiliriz.

new Some().value("some").getValue();

İşte değişmez nesne için başka bir sürüm geliyor.

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

Şimdi bunu yapabiliriz.

new Some.Builder().value("value").build().getValue();

Tüm uygulamada aynı sözleşmeyi kullanırsanız iyi görünüyor.

Uygulamanızın mevcut kısmı standart kural kullanıyorsa, buna bağlı kalacağım ve daha karmaşık sınıflara inşaatçılar ekleyeceğim

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

        public NutritionalFacts build() {
            return new NutritionalFacts(this);
        }
    }

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Paulo Abrantes , JavaBean ayarlayıcılarını akıcı hale getirmenin başka bir yolunu sunar: her JavaBean için bir iç oluşturucu sınıfı tanımlayın. Değerleri döndüren ayarlayıcılar tarafından yanıklanan araçlar kullanıyorsanız, Paulo'nun deseni yardımcı olabilir.

Ben "bu" döner seters lehine. Fasulye uyumlu olup olmadığı umurumda değil. Bana göre, "=" ifadesine / ifadesine sahip olmak uygunsa, değer döndüren ayarlayıcılar iyidir.

Bu yaklaşımı tercih ederdim ama buna karşı karar verdim.

Nedenleri:

• Okunabilirlik. Her setFoo () işlevinin ayrı bir satıra sahip olması kodu daha okunaklı hale getirir. Kodu genellikle yazdığınız tek seferden çok, çok daha fazla okursunuz.
• Yan etki: setFoo () sadece alan foo ayarlamalıdır, başka bir şey değil. Bu iade ekstra bir "NE vardı".

Gördüğüm Oluşturucu deseni setFoo (foo) .setBar (bar) kuralını değil, daha foo (foo) .bar (bar) kullanmayın. Belki de tam da bu nedenlerden dolayı.

Her zaman olduğu gibi bir lezzet meselesidir. Sadece "en az sürpriz" yaklaşımını seviyorum.

Bu özel desene Yöntem Zincirleme denir. Wikipedia bağlantısı , bunun çeşitli programlama dillerinde nasıl yapıldığına dair daha fazla açıklama ve örnek var.

Not: Özel adı aradığım için burada bırakmayı düşündüm.

İlk bakışta: "Korkunç!"

Daha fazla düşünce üzerine

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

aslında hatadan daha az hata yapar

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

Çok ilginç. Alet çantasına fikir ekleniyor ...

Evet, bence iyi bir fikir.

Bir şey ekleyebilseydim, bu sorun ne olacak?

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

Bu çalışacak :

new Friend().setNickName("Bart").setName("Barthelemy");

Eclipse tarafından kabul edilmeyecek! :

new Friend().setName("Barthelemy").setNickName("Bart");

Bunun nedeni setName () öğesinin Arkadaş değil Kişi döndürmesi ve PeoplesetNickName olmamasıdır.

Sınıfın adı yerine SELF sınıfına dönmek için ayarlayıcıları nasıl yazabiliriz?

Böyle bir şey iyi olurdu (SELF anahtar sözcüğü varsa). Bu zaten var mı?

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

Genel olarak bu iyi bir uygulamadır, ancak set tipi işlevlerin, işlemin başarıyla tamamlanıp tamamlanmadığını belirlemek için Boolean tipini kullanmanız gerekebilir, bu da bir yöntemdir. Genel olarak, bunun iyi veya yatak olduğunu söyleyen hiçbir dogma yoktur, elbette durumdan gelir.

Açıklamadan

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

iki şey görüyorum

1) Anlamsız ifade. 2) Okunabilirlik eksikliği.

Bu daha az okunabilir olabilir

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); 

veya bu

list.add(new Employee()
          .setName("Jack Sparrow")
          .setId(1)
          .setFoo("bacon!")); 

Bu çok daha okunabilir:

Employee employee = new Employee();
employee.setName("Jack Sparrow")
employee.setId(1)
employee.setFoo("bacon!")); 
list.add(employee); 

Seterlerimi bir süredir yapıyorum ve tek gerçek sorun, fasulye okuyucu / yazar fasulye erişimcilerini almak için katı getPropertyDescriptors ile yapışan kütüphaneler. Bu durumlarda, java "fasulye" beklediğiniz yazarları olmayacak.

Örneğin, kesin olarak test etmedim, ancak Jackson'ın json / maps'den java nesneleri oluştururken bunları ayarlayıcı olarak tanımayacağına şaşırmam. Umarım bu konuda yanılıyorum (yakında test edeceğim).

Aslında, hafif bir SQL merkezli ORM geliştiriyorum ve bunu döndüren tanınmış ayarlayıcılara getPropertyDescriptors beyong bazı kod eklemek zorunda.

Uzun zaman önce cevap, ama iki sent ... Güzel. Keşke bu akıcı arayüz daha sık kullanılsaydı.

'Fabrika' değişkenini tekrarlamak, daha fazla bilgi eklemez:

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

Bu daha temiz, imho:

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

Tabii ki, daha önce bahsedilen cevaplardan biri olarak, Java API'sı, kalıtım ve araçlar gibi bazı durumlar için bunu doğru bir şekilde yapmak için ayarlanmalıdır.

Varsa diğer dil yapılarını kullanmak daha iyidir. Örneğin, Kotlin'de, birlikte kullanır , uygular veya izin verirsiniz . Bu yaklaşımı kullanıyorsanız , ayarlayıcınızdan bir örnek döndürmeniz gerekmez .

Bu yaklaşım, istemci kodunuzun:

• Dönüş türüne kayıtsız
• Bakımı daha kolay
• Derleyici yan etkilerinden kaçının

İşte bazı örnekler.

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

Bir API yazıyorum, yalnızca bir kez ayarlanacak değerleri ayarlamak için "return this" kullanıyorum. Kullanıcının değiştirebilmesi gereken başka değerlerim varsa, bunun yerine standart bir void ayarlayıcı kullanırım.

Ancak, bu bir tercih meselesi ve zincirleme setçileri bence oldukça havalı görünüyor.

Bu JavaBeans spec sonları iddia tüm posterleri kabul ediyorum. Bunu korumak için nedenler var, ama aynı zamanda bu Builder Pattern'in (buna ayrılmış) kullanımının da yeri olduğunu hissediyorum; her yerde kullanılmadığı sürece kabul edilebilir olmalıdır. Bana göre "It's Place", bitiş noktasının bir "build ()" yöntemine çağrı olduğu yerdir.

Elbette tüm bu şeyleri ayarlamanın başka yolları da vardır, ancak buradaki avantaj, 1) çok parametreli kamu kurucularından ve 2) kısmen belirtilen nesnelerden kaçınmasıdır. Burada, yapıcıya ihtiyaç duyulan şeyleri toplayın ve sonunda "build ()" olarak adlandırın. Alternatif "parametre nesneleri" olacaktır, ancak IMHO sorunu sadece bir seviyeye iter.

Birçok parametre yapıcılarını sevmiyorum, çünkü yanlış argümanların parametrelere iletilmesini kolaylaştırabilecek aynı tür argümanlarının çoğunun geçirilmesini daha olası hale getiriyorlar. Nesne tamamen yapılandırılmadan önce kullanılabileceğinden, ayarlayıcıların çoğunu kullanmaktan hoşlanmıyorum. Ayrıca, önceki seçimlere dayalı varsayılan değerlere sahip olma fikri bir "build ()" yöntemi ile daha iyi sunulur.

Kısacası, doğru kullanılırsa iyi bir uygulama olduğunu düşünüyorum.

Kötü alışkanlık: bir pasör bir alıcı olsun

bir yöntemi açıkça bildirmeye ne dersiniz, bunu U için yapar

setPropertyFromParams(array $hashParamList) { ... }