Tại sao chuỗi setters không thông thường?

Có chuỗi thực hiện trên đậu rất tiện dụng: không cần quá tải các nhà xây dựng, nhà xây dựng lớn, nhà máy và giúp bạn tăng khả năng đọc. Tôi không thể nghĩ ra bất kỳ nhược điểm nào, trừ khi bạn muốn đối tượng của mình là bất biến , trong trường hợp đó nó sẽ không có bất kỳ setters nào. Vì vậy, có lý do tại sao đây không phải là một quy ước OOP?

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");

Vì vậy, có lý do tại sao đây không phải là một quy ước OOP?

Dự đoán tốt nhất của tôi: bởi vì nó vi phạm CQS

Bạn đã có một lệnh (thay đổi trạng thái của đối tượng) và truy vấn (trả về một bản sao trạng thái - trong trường hợp này, chính đối tượng) trộn vào cùng một phương thức. Đó không hẳn là một vấn đề, nhưng nó vi phạm một số nguyên tắc cơ bản.

Chẳng hạn, trong C ++, std :: stack :: pop () là một lệnh trả về void và std :: stack :: top () là một truy vấn trả về một tham chiếu đến phần tử trên cùng trong ngăn xếp. Theo kinh điển, bạn muốn kết hợp cả hai, nhưng bạn không thể làm điều đó và ngoại lệ an toàn. (Không phải là vấn đề trong Java, vì toán tử gán trong Java không ném).

Nếu DTO là một loại giá trị, bạn có thể đạt được kết thúc tương tự với

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

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

Ngoài ra, các giá trị trả về chuỗi là một nỗi đau khổng lồ khi bạn đang đối phó với thừa kế. Xem "Mẫu định kỳ tò mò"

Cuối cùng, có một vấn đề là hàm tạo mặc định sẽ để lại cho bạn một đối tượng ở trạng thái hợp lệ. Nếu bạn phải chạy một loạt các lệnh để khôi phục đối tượng về trạng thái hợp lệ, một cái gì đó đã biến mất Rất sai.

1. Lưu một vài tổ hợp phím không hấp dẫn. Nó có thể tốt, nhưng các công ước OOP quan tâm nhiều hơn đến các khái niệm và cấu trúc, chứ không phải tổ hợp phím.

2. Giá trị trả về là vô nghĩa.

3. Thậm chí nhiều hơn là vô nghĩa, giá trị trả về là sai lệch, vì người dùng có thể mong đợi giá trị trả về có ý nghĩa. Họ có thể mong đợi rằng đó là một "setter bất biến"

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

   Trong thực tế, setter của bạn làm biến đổi đối tượng.

4. Nó không hoạt động tốt với thừa kế.

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

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

   tôi có thể viết

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

   nhưng không

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

Đối với tôi, # 1 đến # 3 là những người quan trọng. Mã được viết tốt không phải là về văn bản được sắp xếp một cách dễ chịu. Mã được viết tốt là về các khái niệm cơ bản, mối quan hệ và cấu trúc. Văn bản chỉ là sự phản ánh ra bên ngoài ý nghĩa thực sự của mã.

Tôi không nghĩ rằng đây là một quy ước OOP, nó liên quan nhiều hơn đến thiết kế ngôn ngữ và các quy ước của nó.

Có vẻ như bạn thích sử dụng Java. Java có một đặc tả JavaBeans chỉ định kiểu trả về của setter là void, nghĩa là nó mâu thuẫn với chuỗi setters. Thông số kỹ thuật này được chấp nhận rộng rãi và thực hiện trong một loạt các công cụ.

Tất nhiên bạn có thể hỏi, tại sao không phải là một phần của đặc tả. Tôi không biết câu trả lời, có thể mẫu này chưa được biết đến / phổ biến tại thời điểm đó.

Như những người khác đã nói, điều này thường được gọi là giao diện trôi chảy .

Thông thường setters là cuộc gọi chuyển qua các biến để đáp ứng với mã logic trong một ứng dụng; lớp DTO của bạn là một ví dụ về điều này. Mã thông thường khi setters không trả lại bất cứ điều gì là bình thường tốt nhất cho việc này. Các câu trả lời khác đã giải thích cách.

Tuy nhiên, có một vài trường hợp giao diện lưu loát có thể là một giải pháp tốt, chúng có điểm chung.

• Các hằng số hầu hết được truyền cho các setters
• Logic chương trình không thay đổi những gì được truyền cho setters.

Thiết lập cấu hình, ví dụ thông thạo-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");

Thiết lập dữ liệu thử nghiệm trong các thử nghiệm đơn vị, sử dụng TestDataBulderClass đặc biệt (Bà mẹ đối tượng)

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

Tuy nhiên, việc tạo giao diện lưu loát tốt là rất khó , vì vậy nó chỉ có giá trị khi bạn có nhiều cài đặt tĩnh tĩnh. Ngoài ra, giao diện lưu loát không nên được trộn lẫn với các lớp học bình thường của Cameron; do đó mẫu xây dựng thường được sử dụng.

Tôi nghĩ phần lớn lý do không phải là một quy ước để xâu chuỗi một setter này bởi vì trong những trường hợp đó, thông thường hơn là thấy một đối tượng tùy chọn hoặc tham số trong hàm tạo. C # có một cú pháp khởi tạo là tốt.

Thay vì:

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

Người ta có thể viết:

(trong JS)

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

(bằng C #)

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

(bằng Java)

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

setFoovà setBarsau đó không còn cần thiết cho việc khởi tạo, và có thể được sử dụng cho đột biến sau này.

Mặc dù khả năng tạo chuỗi rất hữu ích trong một số trường hợp, điều quan trọng là không cố gắng nhồi nhét mọi thứ trên một dòng chỉ vì mục đích giảm các ký tự dòng mới.

Ví dụ

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

làm cho nó khó đọc và hiểu những gì đang xảy ra Định dạng lại thành:

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

Dễ hiểu hơn nhiều và làm cho "lỗi" trong phiên bản đầu tiên trở nên rõ ràng hơn. Khi bạn đã tái cấu trúc mã theo định dạng đó, sẽ không có lợi thế thực sự nào:

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

Kỹ thuật đó thực sự được sử dụng trong mẫu Builder.

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

Tuy nhiên, nói chung là tránh vì nó mơ hồ. Không rõ liệu giá trị trả về là đối tượng (vì vậy bạn có thể gọi các setters khác) hoặc nếu đối tượng trả về là giá trị vừa được gán (cũng là một mẫu chung). Theo đó, Nguyên tắc bất ngờ tối thiểu cho thấy bạn không nên cố gắng giả sử người dùng muốn xem giải pháp này hay giải pháp khác, trừ khi nó là cơ bản cho thiết kế của đối tượng.

Đây là một nhận xét nhiều hơn là một câu trả lời, nhưng tôi không thể bình luận, vì vậy ...

chỉ muốn đề cập rằng câu hỏi này làm tôi ngạc nhiên vì tôi không thấy đây là điều hiếm gặp . Trên thực tế, trong môi trường làm việc của tôi (nhà phát triển web) là rất rất phổ biến.

Chẳng hạn, đây là cách học thuyết của Symfony: tạo: lệnh thực thể tự động tạo tất cả setters , theo mặc định .

jQuery kinda chuỗi hầu hết các phương thức của nó theo một cách rất giống nhau.