Zincirleme ayarlayıcıları neden sıra dışı?

Fasulyelerde zincirleme yapılması çok kullanışlıdır: aşırı yüklenicilere, mega yapıcılara, fabrikalara gerek yoktur ve okunabilirliği arttırır. Nesnenizin değişmez olmasını istemediğiniz sürece herhangi bir olumsuz tarafı düşünemiyorum, bu durumda zaten herhangi bir ayarlayıcı bulunmayacak. Öyleyse bunun bir OOP sözleşmesi olmaması için bir neden var mı?

public class DTO {

    private String foo;
    private String bar;

    public String getFoo() {
         return foo;
    }

    public String getBar() {
        return bar;
    }

    public DTO setFoo(String foo) {
        this.foo = foo;
        return this;
    }

    public DTO setBar(String bar) {
        this.bar = bar;
        return this;
    }

}

//...//

DTO dto = new DTO().setFoo("foo").setBar("bar");

Öyleyse bu neden bir OOP sözleşmesi olmasın?

En iyi tahminim: CQS'yi ihlal ettiği için

Aynı yönteme karıştırılmış bir komut (nesnenin durumunu değiştirme) ve bir sorgu (durum kopyasını döndürme - bu durumda nesnenin kendisi) var. Bu mutlaka bir sorun değil, ancak temel kuralların bazılarını ihlal ediyor.

Örneğin, C ++ 'da std :: stack :: pop (), void döndüren bir komuttur ve std :: stack :: top (), yığındaki en üst öğeye başvuru döndüren bir sorgudur. Klasik olarak, ikisini birleştirmek istersiniz, ancak bunu yapamazsınız ve istisna güvenli olamazsınız . (Java'daki bir atama değil, çünkü Java'daki atama operatörü atmıyor).

DTO bir değer türü olsaydı, bununla benzer bir sonuç elde edebilirsiniz.

public DTO setFoo(String foo) {
    return new DTO(foo, this.bar);
}

public DTO setBar(String bar) {
    return new DTO(this.foo, bar);
}

Ayrıca, zincirleme geri dönüş değerleri, kalıtımla uğraşırken devasa bir acıdır. "Merakla yinelenen şablon kalıbı" konusuna bakın.

Son olarak, varsayılan kurucunun sizi geçerli bir durumda olan bir nesneyle bırakması gerektiği sorunu var. Eğer varsa gereken bir geçerli duruma nesneyi geri komutları bir demet çalıştırın şey çok yanlış gitti.

1. Birkaç tuş vuruşunu kaydetmek zorlayıcı değildir. Güzel olabilir, ancak OOP sözleşmeleri tuşlara basmadan değil, kavramlara ve yapılara daha çok önem veriyor.

2. Dönüş değeri anlamsız.

3. Anlamsız olmaktan bile öte, geri dönüş değeri yanıltıcıdır, çünkü kullanıcılar geri dönüş değerinin anlam kazanmasını bekleyebilirler. Bunun “değişmez bir düzenleyici” olmasını bekleyebilirler

   public FooHolder {
       public FooHolder withFoo(int foo) {
           /* return a modified COPY of this FooHolder instance */
       }
   }
   

   Gerçekte, pasörünüz nesneyi mutasyona uğratır.

4. Miras ile iyi çalışmaz.

   public FooHolder {
       public FooHolder setFoo(int foo) {
           ...
       }
   }
   

   public BarHolder extends FooHolder {
       public FooHolder setBar(int bar) {
           ...
       }
   } 
   

   yazabilirim

   new BarHolder().setBar(2).setFoo(1)

   Ama değil

   new BarHolder().setFoo(1).setBar(2)

Benim için, # 1'den 3'e kadar olanlar önemli olanlar. İyi yazılmış bir kod, hoş bir şekilde düzenlenmiş metinlerden ibaret değildir. İyi yazılmış kod, temel kavramlar, ilişkiler ve yapı ile ilgilidir. Metin, kodun gerçek anlamının yalnızca dışa yansımasıdır.

Bunun bir OOP sözleşmesi olduğunu sanmıyorum, daha çok dil tasarımı ve sözleşmeleriyle ilgili.

Java'yı kullanmak istiyor gibisin. Java, boş bırakılacak ayarlayıcının dönüş türünü belirten bir JavaBeans özelliğine sahiptir , yani ayarlayıcıların zincirlenmesiyle çakışmaktadır. Bu özellik, çeşitli araçlarda geniş çapta kabul görmekte ve uygulanmaktadır.

Elbette sorabilirsiniz, neden şartnamenin bir kısmını zincirlemiyorsunuz. Cevabı bilmiyorum, belki de bu desen o zamanlar bilinmiyor / popüler değildi.

Diğer insanların söylediği gibi, buna genellikle akıcı bir arayüz denir .

Normalde ayarlayıcılar bir uygulamadaki mantık koduna cevaben değişkenlerde çağrı yapmaktır ; DTO sınıfınız buna bir örnektir. Ayarlayıcılar hiçbir şey döndürmediğinde geleneksel kod bunun için en iyisidir. Diğer cevaplar yolu açıkladı.

Bununla birlikte, akıcı ara yüzün iyi bir çözüm olabileceği birkaç durum vardır , bunlar ortaktır.

• Sabitler belirleyicilere geçiyor
• Program mantığı ayarlayıcılara iletileni değiştirmez.

Konfigürasyon ayarlama, örneğin akıcı-nhibernate

Id(x => x.Id);
Map(x => x.Name)
   .Length(16)
   .Not.Nullable();
HasMany(x => x.Staff)
   .Inverse()
   .Cascade.All();
HasManyToMany(x => x.Products)
   .Cascade.All()
   .Table("StoreProduct");

Özel TestDataBulderClasses (Object Anneleri) kullanarak birim testlerinde test verileri ayarlama

members = MemberBuilder.CreateList(4)
    .TheFirst(1).With(b => b.WithFirstName("Rob"))
    .TheNext(2).With(b => b.WithFirstName("Poya"))
    .TheNext(1).With(b => b.WithFirstName("Matt"))
    .BuildList(); // Note the "build" method sets everything else to
                  // senible default values so a test only need to define 
                  // what it care about, even if for example a member 
                  // MUST have MembershipId  set

Ancak, iyi akıcı bir arayüz oluşturmak çok zordur , bu yüzden sadece “statik” bir kurulum yaptığınızda buna değer. Ayrıca, akıcı arayüz “normal” sınıflarla karıştırılmamalıdır; bu yüzden yapıcı desen sıklıkla kullanılır.

Bence bir ayarlayıcıyı birbiri ardına zincirlemenin bir nedeni olmama nedeni, bu durumlarda bir kurucuda bir seçenek nesnesi ya da parametresi görmenin daha tipik olmasıdır. C # da bir başlatıcı sözdizimine sahiptir.

Onun yerine:

DTO dto = new DTO().setFoo("foo").setBar("bar");

Bir yazabilir:

(JS’de)

var dto = new DTO({foo: "foo", bar: "bar"});

(C # ile)

DTO dto = new DTO{Foo = "foo", Bar = "bar"};

(Java’da)

DTO dto = new DTO("foo", "bar");

setFoove setBardaha sonra başlatma için artık gerekli değildir ve daha sonra mutasyon için kullanılabilir.

Zincirleme özelliği bazı durumlarda faydalı olsa da, sadece yeni satır karakterlerini azaltmak uğruna her şeyi tek bir satırda yapmaya çalışmamak önemlidir.

Örneğin

dto.setFoo("foo").setBar("fizz").setFizz("bar").setBuzz("buzz");

ne olduğunu okumak ve anlamak zorlaştırır. Yeniden biçimlendirme:

dto.setFoo("foo")
    .setBar("fizz")
    .setFizz("bar")
    .setBuzz("buzz");

Anlaması çok daha kolaydır ve ilk versiyondaki "hatayı" daha belirgin hale getirir. Kodu bu formata yeniden ekledikten sonra, bunun üzerinde gerçek bir avantaj yoktur:

dto.setFoo("foo");
dto.setBar("bar");
dto.setFizz("fizz");
dto.setBuzz("buzz");

Bu teknik aslında Oluşturucu düzeninde kullanılır.

x = ObjectBuilder()
        .foo(5)
        .bar(6);

Ancak, genel olarak bundan kaçınılır, çünkü belirsizdir. Dönüş değerinin nesne olup olmadığı (yani diğer ayarlayıcıları çağırabilirsiniz) veya dönüş nesnesinin yeni atanan değer olup olmadığı açıktır (ayrıca ortak bir kalıp). Buna göre, En Az Sürpriz Prensibi, nesnenin tasarımında temel olmadıkça, kullanıcının bir çözümü ya da diğerini görmek istediğini varsaymaya çalışmamanızı önerir.

Bu bir cevaptan çok bir yorumdur, ama yorum yapamam, o yüzden ...

sadece bu sorunun beni şaşırttığından bahsetmek istedim çünkü bunu hiç nadir görmüyorum . Aslında benim çalışma ortamımda (web geliştirici) çok yaygındır.

Oluşturmak: Örneğin, bu Symfony'nin doktrini nasıl kişiler otomatik oluşturduğu komuta tüm setters , varsayılan olarak .

jQuery tür çok benzer bir şekilde zincirler onun yöntemlerin çoğu.