Apakah praktik yang buruk untuk mengembalikan setter ke "ini"?

Apakah ini ide yang baik atau buruk untuk membuat setter di java mengembalikan "ini"?

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

Pola ini dapat bermanfaat karena Anda dapat mengatur setter seperti ini:

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

alih-alih ini:

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

... tapi itu agak bertentangan dengan konvensi standar. Saya kira itu mungkin bermanfaat hanya karena dapat membuat setter itu melakukan sesuatu yang bermanfaat. Saya telah melihat pola ini menggunakan beberapa tempat (misalnya JMock, JPA), tetapi tampaknya tidak umum, dan hanya umumnya digunakan untuk API yang didefinisikan dengan sangat baik di mana pola ini digunakan di mana-mana.

Memperbarui:

Apa yang saya jelaskan jelas valid, tetapi yang benar-benar saya cari adalah beberapa pemikiran tentang apakah ini secara umum dapat diterima, dan jika ada jebakan atau praktik terbaik terkait. Saya tahu tentang pola Builder tetapi sedikit lebih terlibat daripada apa yang saya jelaskan - seperti yang dijelaskan oleh Josh Bloch, ada kelas Builder statis terkait untuk pembuatan objek.

Saya tidak berpikir ada sesuatu yang salah dengan itu, itu hanya masalah gaya. Ini berguna saat:

• Anda perlu mengatur banyak bidang sekaligus (termasuk pada konstruksi)
• Anda tahu bidang mana yang perlu Anda atur saat Anda menulis kode, dan
• ada banyak kombinasi berbeda untuk bidang mana yang ingin Anda atur.

Alternatif untuk metode ini mungkin:

1. Satu mega konstruktor (sisi negatifnya: Anda mungkin melewatkan banyak nilai nol atau standar, dan semakin sulit untuk mengetahui nilai mana yang sesuai dengan apa)
2. Beberapa konstruktor kelebihan beban (sisi negatifnya: menjadi sangat berat setelah Anda memiliki lebih dari beberapa)
3. Metode pabrik / statis (downside: sama dengan konstruktor yang kelebihan beban - menjadi berat saat ada lebih dari beberapa)

Jika Anda hanya akan menetapkan beberapa properti pada satu waktu saya akan mengatakan itu tidak layak mengembalikan 'ini'. Itu pasti jatuh jika Anda kemudian memutuskan untuk mengembalikan sesuatu yang lain, seperti status / indikator keberhasilan / pesan.

Itu bukan praktik yang buruk. Ini adalah praktik yang semakin umum. Sebagian besar bahasa tidak mengharuskan Anda untuk berurusan dengan objek yang dikembalikan jika Anda tidak ingin sehingga itu tidak mengubah sintaks penggunaan setter "normal" tetapi memungkinkan Anda untuk rantai setter bersama-sama.

Ini biasa disebut pola pembangun atau antarmuka yang lancar .

Ini juga umum di API Java:

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

Untuk meringkas:

• itu disebut "antarmuka lancar", atau "metode chaining".
• ini bukan Java "standar", meskipun Anda melihatnya lebih banyak hari ini (berfungsi dengan baik di jQuery)
• itu melanggar spesifikasi JavaBean, jadi itu akan pecah dengan berbagai alat dan perpustakaan, terutama pembangun JSP dan Spring.
• ini dapat mencegah beberapa optimasi yang biasanya dilakukan JVM
• beberapa orang berpikir itu membersihkan kode, yang lain berpikir itu "mengerikan"

Beberapa poin lain yang tidak disebutkan:

• Ini melanggar prinsip bahwa setiap fungsi harus melakukan satu (dan hanya satu) hal. Anda mungkin atau mungkin tidak percaya pada hal ini, tetapi di Jawa saya percaya itu bekerja dengan baik.

• IDE tidak akan menghasilkan ini untuk Anda (secara default).

• Saya akhirnya, inilah titik data dunia nyata. Saya punya masalah menggunakan perpustakaan yang dibangun seperti ini. Pembuat kueri Hibernate adalah contohnya di pustaka yang ada. Karena metode set * Query mengembalikan kueri, mustahil untuk mengetahui hanya dengan melihat tanda tangan bagaimana menggunakannya. Sebagai contoh:

  Query setWhatever(String what);

• Ini memperkenalkan ambiguitas: apakah metode memodifikasi objek saat ini (pola Anda) atau, mungkin Query benar-benar abadi (pola yang sangat populer dan berharga), dan metode ini mengembalikan yang baru. Itu hanya membuat perpustakaan lebih sulit untuk digunakan, dan banyak programmer tidak memanfaatkan fitur ini. Jika setter adalah setter, akan lebih jelas bagaimana menggunakannya.

Saya lebih suka menggunakan metode 'dengan' untuk ini:

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

Jadi:

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

Peringatan : withXsintaks ini biasanya digunakan untuk menyediakan "setter" untuk objek yang tidak dapat diubah, jadi penelepon dari metode ini mungkin mengharapkan mereka untuk membuat objek baru daripada bermutasi pada instance yang ada. Mungkin kata-kata yang lebih masuk akal adalah sesuatu seperti:

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

Dengan konvensi penamaan chainsetXyz () hampir semua orang pasti senang.

Jika Anda tidak ingin kembali 'this'dari setter tetapi tidak ingin menggunakan opsi kedua, Anda dapat menggunakan sintaks berikut untuk mengatur properti:

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

Sebagai tambahan saya pikir itu sedikit lebih bersih di C #:

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

Itu tidak hanya merusak konvensi getter / setter, tetapi juga merusak kerangka referensi metode Java 8. MyClass::setMyValueadalah BiConsumer<MyClass,MyValue>, dan myInstance::setMyValuemerupakan Consumer<MyValue>. Jika Anda memiliki setter kembali this, maka itu bukan lagi contoh yang valid Consumer<MyValue>, tetapi lebih dari Function<MyValue,MyClass>, dan akan menyebabkan apa pun menggunakan referensi metode untuk setter tersebut (dengan asumsi mereka adalah metode batal) untuk istirahat.

Saya tidak tahu Java tapi saya sudah melakukan ini di C ++. Orang lain mengatakan itu membuat garis sangat panjang dan sangat sulit dibaca, tapi saya sudah sering melakukannya seperti ini:

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

Ini bahkan lebih baik:

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

setidaknya, saya pikir. Tapi Anda dipersilakan untuk menurunkan saya dan memanggil saya seorang programmer yang buruk jika Anda mau. Dan saya tidak tahu apakah Anda diizinkan untuk melakukan ini di Jawa.

Skema ini (pun intended), yang disebut 'antarmuka lancar', menjadi cukup populer sekarang. Itu bisa diterima, tapi itu bukan cangkir teh saya.

Karena tidak mengembalikan batal, itu bukan lagi setter properti JavaBean yang valid. Itu mungkin penting jika Anda salah satu dari tujuh orang di dunia menggunakan alat visual "Bean Builder", atau salah satu dari 17 orang menggunakan elemen JSP-bean-setProperty.

Setidaknya secara teori , ini dapat merusak mekanisme optimisasi JVM dengan mengatur dependensi palsu antara panggilan.

Seharusnya gula sintaksis, tetapi sebenarnya dapat membuat efek samping di mesin virtual Java 43 super-cerdas.

Itu sebabnya saya memilih tidak, jangan menggunakannya.

Itu sama sekali bukan praktik buruk. Tapi itu tidak kompatibel dengan JavaBeans Spec .

Dan ada banyak spesifikasi tergantung pada pengakses standar tersebut.

Anda selalu dapat membuat mereka hidup berdampingan satu sama lain.

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;
}

Sekarang kita bisa menggunakannya bersama.

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

Di sinilah versi lain untuk objek abadi.

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;
}

Sekarang kita bisa melakukan ini.

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

Jika Anda menggunakan konvensi yang sama di seluruh aplikasi, sepertinya tidak masalah.

Di sisi lain jika bagian yang ada dari aplikasi Anda menggunakan konvensi standar saya akan tetap menggunakannya dan menambahkan pembangun ke kelas yang lebih rumit

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 menawarkan cara lain untuk membuat JavaBean setter fasih: mendefinisikan kelas pembangun batin untuk setiap JavaBean. Jika Anda menggunakan alat yang bingung oleh setter yang mengembalikan nilai, pola Paulo bisa membantu.

Saya mendukung pemukim memiliki "ini" kembali. Saya tidak peduli jika itu tidak sesuai dengan kacang. Bagi saya, jika boleh memiliki ekspresi / pernyataan "=", maka seters bahwa nilai pengembalian baik-baik saja.

Saya dulu lebih suka pendekatan ini tetapi saya telah memutuskan untuk tidak melakukannya.

Alasan:

• Keterbacaan. Itu membuat kode lebih mudah dibaca untuk membuat setiap setFoo () pada baris terpisah. Anda biasanya membaca kode berkali-kali, lebih banyak daripada saat Anda menuliskannya.
• Efek samping: setFoo () seharusnya hanya mengatur field foo, tidak ada yang lain. Mengembalikan ini adalah tambahan "APA itu".

Pola Builder yang saya lihat tidak menggunakan konvensi setFoo (foo) .setBar (bar) tetapi lebih banyak foo (foo) .bar (bar). Mungkin karena alasan-alasan itu.

Memang, seperti biasa soal selera. Saya hanya menyukai pendekatan "kejutan kecil".

Pola khusus ini disebut Metode Chaining. Tautan Wikipedia , ini memiliki lebih banyak penjelasan dan contoh bagaimana melakukannya dalam berbagai bahasa pemrograman.

PS: Baru saja berpikir untuk meninggalkannya di sini, karena saya sedang mencari nama yang spesifik.

Pada pandangan pertama: "Mengerikan!".

Dipikirkan lebih lanjut

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

sebenarnya lebih sedikit kesalahan daripada

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

Sangat menarik. Menambahkan ide ke toolbag ...

Ya, saya pikir itu ide yang bagus.

Jika saya bisa menambahkan sesuatu, bagaimana dengan masalah ini:

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;
    }
}

Ini akan berhasil:

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

Ini tidak akan diterima oleh Eclipse! :

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

Ini karena setName () mengembalikan Orang dan bukan Teman, dan tidak ada PeoplesetNickName.

Bagaimana kita bisa menulis setter untuk mengembalikan kelas SELF alih-alih nama kelas?

Sesuatu seperti ini akan baik-baik saja (jika kata kunci DIRI akan ada). Apakah ini ada?

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

Secara umum ini adalah praktik yang baik, tetapi Anda mungkin perlu untuk fungsi tipe-set menggunakan tipe Boolean untuk menentukan apakah operasi berhasil diselesaikan atau tidak, itu juga salah satu caranya. Secara umum, tidak ada dogma untuk mengatakan bahwa ini baik atau ranjang, itu berasal dari situasi, tentu saja.

Dari pernyataan itu

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

saya melihat dua hal

1) Pernyataan tidak berarti. 2) Kurangnya keterbacaan.

Ini mungkin kurang mudah dibaca

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

atau ini

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

Ini jauh lebih mudah dibaca daripada:

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

Saya telah membuat setter saya cukup lama dan satu-satunya masalah sebenarnya adalah dengan perpustakaan yang tetap dengan getPropertyDescriptors yang ketat untuk mendapatkan aksesor pembaca kacang / penulis bean. Dalam kasus itu, "kacang" java Anda tidak akan memiliki pembungkus yang Anda harapkan.

Sebagai contoh, saya belum mengujinya dengan pasti, tetapi saya tidak akan terkejut bahwa Jackson tidak akan mengenali mereka sebagai setter ketika membuat Anda objek java dari json / maps. Saya harap saya salah dalam hal ini (saya akan segera mengujinya).

Bahkan, saya sedang mengembangkan ORM SQL sentris ringan dan saya harus menambahkan beberapa kode getPropertyDescriptors beyong ke setter diakui yang mengembalikan ini.

Dulu jawaban, tapi dua sen saya ... Tidak apa-apa. Saya berharap antarmuka yang lancar ini digunakan lebih sering.

Pengulangan variabel 'pabrik' tidak menambahkan info lebih lanjut di bawah ini:

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

Ini lebih bersih, ya:

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

Tentu saja, sebagai salah satu jawaban yang telah disebutkan, Java API harus di-tweak untuk melakukan ini dengan benar untuk beberapa situasi, seperti warisan dan alat.

Lebih baik menggunakan konstruksi bahasa lain jika tersedia. Misalnya, dalam Kotlin, Anda akan menggunakan dengan , menerapkan , atau biarkan . Jika menggunakan pendekatan ini, Anda tidak perlu mengembalikan instance dari setter Anda.

Pendekatan ini memungkinkan kode klien Anda menjadi:

• Tidak peduli dengan tipe pengembalian
• Lebih mudah dirawat
• Hindari efek samping kompiler

Berikut ini beberapa contohnya.

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"
}

Jika saya menulis API, saya menggunakan "kembalikan ini" untuk menetapkan nilai yang hanya akan ditetapkan satu kali. Jika saya memiliki nilai lain yang harus dapat diubah oleh pengguna, saya menggunakan setter void standar sebagai gantinya.

Namun, itu benar-benar masalah preferensi dan pengaturan rantai memang terlihat cukup keren, menurut saya.

Saya setuju dengan semua poster yang mengklaim bahwa ini melanggar spesifikasi JavaBeans. Ada alasan untuk melestarikan itu, tetapi saya juga merasa bahwa penggunaan Pola Pembangun ini (yang disinggung) memiliki tempatnya; selama itu tidak digunakan di mana-mana, itu harus dapat diterima. "It's Place", bagi saya, adalah titik akhir panggilan untuk metode "build ()".

Ada cara lain untuk mengatur semua hal ini tentu saja, tetapi keuntungan di sini adalah bahwa ia menghindari 1) banyak konstruktor publik parameter dan 2) objek yang ditentukan sebagian. Di sini, Anda memiliki pembangun mengumpulkan apa yang dibutuhkan dan kemudian memanggilnya "build ()" di akhir, yang kemudian dapat memastikan bahwa objek yang ditentukan sebagian tidak dibangun, karena operasi itu dapat diberikan visibilitas kurang dari-publik. Alternatifnya adalah "objek parameter", tetapi IMHO hanya mendorong masalah kembali satu tingkat.

Saya tidak suka konstruktor banyak-parameter karena mereka membuatnya lebih mungkin bahwa banyak argumen tipe-sama diteruskan, yang dapat membuatnya lebih mudah untuk menyampaikan argumen yang salah ke parameter. Saya tidak suka menggunakan banyak setter karena objek dapat digunakan sebelum sepenuhnya dikonfigurasi. Selanjutnya, gagasan memiliki nilai default berdasarkan pilihan sebelumnya lebih baik disajikan dengan metode "build ()".

Singkatnya, saya pikir ini adalah praktik yang baik, jika digunakan dengan benar.

Kebiasaan buruk: seorang setter mengatur getter get

bagaimana dengan mendeklarasikan metode secara eksplisit, yang melakukannya untuk U

setPropertyFromParams(array $hashParamList) { ... }