Có phải đó là một thực tế tồi để thực hiện một setter quay trở lại với điều này không?

Nó là một ý tưởng tốt hay xấu để làm cho setters trong java trả lại "cái này"?

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

Mẫu này có thể hữu ích vì sau đó bạn có thể xâu chuỗi setters như thế này:

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

thay vì điều này:

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

... nhưng nó đi ngược lại quy ước tiêu chuẩn. Tôi cho rằng nó có thể đáng giá chỉ vì nó có thể khiến setter đó làm một cái gì đó hữu ích khác. Tôi đã thấy mẫu này được sử dụng ở một số nơi (ví dụ: JMock, JPA), nhưng có vẻ không phổ biến và thường chỉ được sử dụng cho các API được xác định rất rõ trong đó mẫu này được sử dụng ở mọi nơi.

Cập nhật:

Những gì tôi đã mô tả rõ ràng là hợp lệ, nhưng những gì tôi thực sự tìm kiếm là một số suy nghĩ về việc liệu điều này thường được chấp nhận, và nếu có bất kỳ cạm bẫy hoặc thực tiễn tốt nhất liên quan. Tôi biết về mẫu Builder nhưng nó liên quan nhiều hơn một chút sau đó là những gì tôi đang mô tả - như Josh Bloch mô tả nó có một lớp Builder tĩnh liên quan để tạo đối tượng.

Tôi không nghĩ có gì đặc biệt sai với nó, đó chỉ là vấn đề về phong cách. Nó hữu ích khi:

• Bạn cần đặt nhiều trường cùng một lúc (bao gồm cả lúc xây dựng)
• bạn biết những lĩnh vực nào bạn cần đặt tại thời điểm bạn viết mã và
• có nhiều kết hợp khác nhau cho các trường bạn muốn đặt.

Các lựa chọn thay thế cho phương pháp này có thể là:

1. Một hàm tạo lớn (nhược điểm: bạn có thể chuyển nhiều giá trị null hoặc giá trị mặc định và thật khó để biết giá trị nào tương ứng với giá trị nào)
2. Một số hàm tạo quá tải (nhược điểm: trở nên khó sử dụng khi bạn có nhiều hơn một vài)
3. Các phương thức nhà máy / tĩnh (nhược điểm: giống như các nhà xây dựng bị quá tải - trở nên khó sử dụng một khi có nhiều hơn một vài)

Nếu bạn chỉ thiết lập một vài thuộc tính tại một thời điểm tôi sẽ nói rằng không đáng để trả lại 'cái này'. Nó chắc chắn rơi xuống nếu sau đó bạn quyết định trả lại một cái gì đó khác, như một thông báo / chỉ báo trạng thái / thành công.

Đó không phải là thực hành xấu. Đó là một thực tế ngày càng phổ biến. Hầu hết các ngôn ngữ không yêu cầu bạn phải xử lý đối tượng được trả về nếu bạn không muốn nó không thay đổi cú pháp sử dụng setter "bình thường" nhưng cho phép bạn xâu chuỗi setters lại với nhau.

Điều này thường được gọi là mô hình xây dựng hoặc giao diện trôi chảy .

Nó cũng phổ biến trong API Java:

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

Để tóm tắt:

• nó được gọi là "giao diện trôi chảy" hay "chuỗi phương thức".
• đây không phải là Java "tiêu chuẩn", mặc dù ngày nay bạn thấy nó nhiều hơn (hoạt động rất tốt trong jQuery)
• nó vi phạm thông số JavaBean, do đó, nó sẽ phá vỡ các công cụ và thư viện khác nhau, đặc biệt là các trình xây dựng JSP và Spring.
• nó có thể ngăn chặn một số tối ưu hóa mà JVM thường làm
• Một số người nghĩ rằng nó làm sạch mã, những người khác nghĩ rằng nó "khủng khiếp"

Một vài điểm khác không được đề cập:

• Điều này vi phạm hiệu trưởng rằng mỗi chức năng nên làm một (và chỉ một) điều. Bạn có thể hoặc không thể tin vào điều này, nhưng trong Java tôi tin rằng nó hoạt động tốt.

• IDE sẽ không tạo ra chúng cho bạn (theo mặc định).

• Cuối cùng tôi, đây là một điểm dữ liệu trong thế giới thực. Tôi đã có vấn đề khi sử dụng một thư viện được xây dựng như thế này. Trình tạo truy vấn của Hibernate là một ví dụ về điều này trong một thư viện hiện có. Vì các phương thức set * của Query đang trả về các truy vấn, nên không thể biết chỉ bằng cách xem chữ ký cách sử dụng nó. Ví dụ:

  Query setWhatever(String what);

• Nó giới thiệu một sự mơ hồ: phương thức có sửa đổi đối tượng hiện tại (mẫu của bạn) hay, có lẽ Truy vấn thực sự bất biến (một mẫu rất phổ biến và có giá trị) và phương thức đang trả về một đối tượng mới. Nó chỉ làm cho thư viện khó sử dụng hơn và nhiều lập trình viên không khai thác tính năng này. Nếu setters là setters, nó sẽ rõ ràng hơn làm thế nào để sử dụng nó.

Tôi thích sử dụng các phương thức 'với' cho việc này:

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

Như vậy:

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

Cảnh báo : withXcú pháp này thường được sử dụng để cung cấp "setters" cho các đối tượng không thay đổi, vì vậy người gọi các phương thức này có thể mong đợi chúng tạo ra các đối tượng mới thay vì làm thay đổi thể hiện hiện tại. Có lẽ một từ ngữ hợp lý hơn sẽ là một cái gì đó như:

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

Với quy ước đặt tên chainsetXyz () hầu như mọi người đều nên vui mừng.

Nếu bạn không muốn quay lại 'this'từ setter nhưng không muốn sử dụng tùy chọn thứ hai, bạn có thể sử dụng cú pháp sau để đặt thuộc tính:

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

Như một bên tôi nghĩ rằng nó sạch hơn một chút trong C #:

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

Nó không chỉ phá vỡ quy ước của getters / setters, nó còn phá vỡ khung tham chiếu phương thức Java 8. MyClass::setMyValuelà một BiConsumer<MyClass,MyValue>, và myInstance::setMyValuelà mộtConsumer<MyValue> . Nếu bạn có trả về setter của mình this, thì nó không còn là một thể hiện hợp lệ của Consumer<MyValue>, mà là một Function<MyValue,MyClass>, và sẽ khiến mọi thứ sử dụng tham chiếu phương thức đến các setters đó (giả sử chúng là các phương thức void) bị phá vỡ.

Tôi không biết Java nhưng tôi đã làm điều này trong C ++. Những người khác đã nói rằng nó làm cho các dòng thực sự dài và rất khó đọc, nhưng tôi đã thực hiện nó như thế này rất nhiều lần:

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

Điều này thậm chí còn tốt hơn:

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

ít nhất, tôi nghĩ Nhưng bạn được chào đón để đánh giá thấp tôi và gọi cho tôi một lập trình viên khủng khiếp nếu bạn muốn. Và tôi không biết liệu bạn có được phép làm điều này trong Java không.

Lược đồ này (ý định chơi chữ), được gọi là 'giao diện lưu loát', hiện đang trở nên khá phổ biến. Nó chấp nhận được, nhưng nó không thực sự là tách trà của tôi.

Bởi vì nó không trả về void, nó không còn là trình thiết lập thuộc tính JavaBean hợp lệ. Điều đó có thể quan trọng nếu bạn là một trong bảy người trên thế giới sử dụng các công cụ "Bean Builder" trực quan hoặc một trong 17 người sử dụng các phần tử JSP-bean-setProperty.

Ít nhất là về lý thuyết , nó có thể làm hỏng các cơ chế tối ưu hóa của JVM bằng cách đặt các phụ thuộc sai giữa các cuộc gọi.

Nó được cho là đường cú pháp, nhưng trên thực tế có thể tạo ra các tác dụng phụ trong máy ảo Java 43 siêu thông minh.

Đó là lý do tại sao tôi bỏ phiếu không, không sử dụng nó.

Đó không phải là một thực hành xấu cả. Nhưng nó không tương thích với JavaBeans Spec .

Và có rất nhiều đặc điểm kỹ thuật phụ thuộc vào những người truy cập tiêu chuẩn.

Bạn luôn có thể làm cho chúng cùng tồn tại với nhau.

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

Bây giờ chúng ta có thể sử dụng chúng cùng nhau.

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

Ở đây có một phiên bản khác cho đối tượng bất biến.

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

Bây giờ chúng ta có thể làm điều này.

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

Nếu bạn sử dụng cùng một quy ước trong toàn bộ applicaiton thì có vẻ ổn.

Mặt khác, nếu phần hiện có trong ứng dụng của bạn sử dụng quy ước chuẩn, tôi sẽ sử dụng nó và thêm các trình xây dựng vào các lớp phức tạp hơn

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 cung cấp một cách khác để làm cho các setters của JavaBean thành thạo: định nghĩa một lớp trình tạo bên trong cho mỗi JavaBean. Nếu bạn đang sử dụng các công cụ bị thất bại bởi các setters trả về giá trị, mẫu của Paulo có thể giúp ích.

Tôi ủng hộ setters có lợi nhuận "này". Tôi không quan tâm nếu nó không tuân thủ đậu. Đối với tôi, nếu có biểu thức / câu lệnh "=" thì setters trả về giá trị là ổn.

Tôi đã từng thích cách tiếp cận này nhưng tôi đã quyết định chống lại nó.

Lý do:

• Dễ đọc. Nó làm cho mã dễ đọc hơn khi có mỗi setFoo () trên một dòng riêng biệt. Bạn thường đọc mã nhiều, nhiều lần so với lần duy nhất bạn viết nó.
• Tác dụng phụ: setFoo () chỉ nên đặt trường foo, không có gì khác. Trả lại đây là thêm một "CÁI GÌ".

Mẫu Builder mà tôi thấy không sử dụng quy ước setFoo (foo) .setBar (bar) mà nhiều foo (foo) .bar (bar). Có lẽ vì chính xác những lý do đó.

Đó là, như luôn luôn là một vấn đề của hương vị. Tôi chỉ thích cách tiếp cận "ít bất ngờ nhất".

Mẫu đặc biệt này được gọi là Phương thức Chaining. Liên kết Wikipedia , điều này có nhiều lời giải thích và ví dụ về cách nó được thực hiện trong các ngôn ngữ lập trình khác nhau.

PS: Chỉ cần nghĩ đến việc để nó ở đây, vì tôi đang tìm tên cụ thể.

Ngay từ cái nhìn đầu tiên: "Ghastly!".

Suy nghĩ thêm

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

thực sự ít bị lỗi hơn

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

Vì vậy, khá thú vị. Thêm ý tưởng vào túi công cụ ...

Vâng, tôi nghĩ đó là một ý tưởng tốt.

Nếu tôi có thể thêm một cái gì đó, thì vấn đề này là gì:

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

Điều này sẽ làm việc:

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

Điều này sẽ không được chấp nhận bởi Eclipse! :

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

Điều này là do setName () trả về một Người chứ không phải là Bạn bè và không có PeoplesetNickName.

Làm thế nào chúng ta có thể viết setters để trả về lớp TỰF thay vì tên của lớp?

Một cái gì đó như thế này sẽ ổn (nếu từ khóa TỰF tồn tại). Điều này có tồn tại không?

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

Nói chung, đó là một cách thực hành tốt, nhưng bạn có thể cần các hàm loại tập hợp sử dụng loại Boolean để xác định xem thao tác đã được hoàn thành thành công hay chưa, đó cũng là một cách. Nói chung, không có giáo điều để nói rằng điều này là tốt hay giường, nó xuất phát từ tình huống, tất nhiên.

Từ tuyên bố

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

tôi đang thấy hai điều

1) Tuyên bố vô nghĩa. 2) Thiếu khả năng đọc.

Điều này có thể dễ đọc hơn

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

hoặc cái này

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

Đây là cách dễ đọc hơn:

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

Tôi đã thực hiện setters của mình khá lâu và vấn đề thực sự duy nhất là với các thư viện gắn bó với getPropertyDescriptors nghiêm ngặt để có được trình truy cập bean reader / reader. Trong những trường hợp đó, java "bean" của bạn sẽ không có các trình soạn thảo mà bạn mong đợi.

Ví dụ, tôi đã không kiểm tra chắc chắn, nhưng tôi sẽ không ngạc nhiên khi Jackson sẽ không nhận ra chúng là setters khi tạo cho bạn các đối tượng java từ json / maps. Tôi hy vọng tôi đã sai về điều này (tôi sẽ kiểm tra nó sớm).

Trong thực tế, tôi đang phát triển một ORM trung tâm SQL nhẹ và tôi phải thêm một số mã beyong getPropertyDescriptors vào các setters được công nhận trả về điều này.

Lâu rồi mới trả lời, nhưng hai xu của tôi ... Không sao đâu. Tôi muốn giao diện lưu loát này được sử dụng thường xuyên hơn.

Lặp lại biến 'nhà máy' không thêm thông tin bên dưới:

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

Cái này sạch hơn, imho:

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

Tất nhiên, như một trong những câu trả lời đã được đề cập, API Java sẽ phải được điều chỉnh để thực hiện điều này một cách chính xác cho một số tình huống, như kế thừa và công cụ.

Tốt hơn là sử dụng các cấu trúc ngôn ngữ khác nếu có. Ví dụ: trong Kotlin, bạn sẽ sử dụng với , áp dụng hoặc cho phép . Nếu sử dụng phương pháp này, bạn sẽ không thực sự cần phải trả về một thể hiện từ setter của mình.

Cách tiếp cận này cho phép mã khách hàng của bạn là:

• Không quan tâm đến loại trả lại
• Dễ bảo trì hơn
• Tránh tác dụng phụ của trình biên dịch

Dưới đây là một số ví dụ.

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

Nếu tôi đang viết API, tôi sử dụng "return this" để đặt các giá trị sẽ chỉ được đặt một lần. Nếu tôi có bất kỳ giá trị nào khác mà người dùng sẽ có thể thay đổi, tôi sử dụng bộ set void tiêu chuẩn thay thế.

Tuy nhiên, theo tôi thì đó thực sự là một vấn đề ưu tiên và xâu chuỗi trông khá tuyệt vời.

Tôi đồng ý với tất cả các áp phích tuyên bố rằng điều này phá vỡ thông số JavaBeans. Có nhiều lý do để bảo tồn điều đó, nhưng tôi cũng cảm thấy rằng việc sử dụng Mẫu xây dựng này (đã được ám chỉ) có vị trí của nó; miễn là nó không được sử dụng ở mọi nơi, nó sẽ được chấp nhận. "Đó là nơi", đối với tôi, là điểm cuối là một cuộc gọi đến phương thức "build ()".

Tất nhiên có nhiều cách khác để thiết lập tất cả những điều này, nhưng ưu điểm ở đây là nó tránh được 1) các hàm tạo công cộng nhiều tham số và 2) các đối tượng được chỉ định một phần. Ở đây, bạn có trình xây dựng thu thập những gì cần thiết và sau đó gọi "build ()" của nó ở cuối, điều này có thể đảm bảo rằng một đối tượng được chỉ định một phần không được xây dựng, vì hoạt động đó có thể được hiển thị ít hơn công khai. Giải pháp thay thế sẽ là "các đối tượng tham số", nhưng IMHO chỉ đẩy vấn đề trở lại một cấp.

Tôi không thích các hàm tạo nhiều tham số vì chúng làm cho nhiều khả năng có nhiều đối số cùng loại được truyền vào, điều này có thể giúp dễ dàng chuyển các đối số sai sang tham số. Tôi không thích sử dụng nhiều setters vì đối tượng có thể được sử dụng trước khi nó được cấu hình đầy đủ. Hơn nữa, khái niệm có các giá trị mặc định dựa trên các lựa chọn trước đó được phục vụ tốt hơn với phương thức "build ()".

Tóm lại, tôi nghĩ rằng đó là một thực hành tốt, nếu được sử dụng đúng cách.

Thói quen xấu: setter set getter get

những gì về việc khai báo một phương thức rõ ràng, điều đó làm cho U

setPropertyFromParams(array $hashParamList) { ... }