มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะทำให้สุนัขเซทเทอร์กลับมา“ สิ่งนี้”?

เป็นความคิดที่ดีหรือไม่ดีที่จะทำให้ setters ใน java คืนค่า "this" หรือไม่?

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

รูปแบบนี้มีประโยชน์เพราะจากนั้นคุณสามารถโยงผู้ตั้งค่าเช่นนี้:

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

แทนสิ่งนี้:

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

... แต่มันขัดแย้งกับการประชุมมาตรฐาน ฉันคิดว่ามันอาจจะคุ้มค่าเพียงเพราะมันทำให้สุนัขตัวนั้นทำสิ่งอื่นที่มีประโยชน์ ฉันเคยเห็นรูปแบบนี้ใช้สถานที่บางแห่ง (เช่น JMock, JPA) แต่ดูเหมือนว่าผิดปกติและใช้โดยทั่วไปสำหรับ API ที่กำหนดไว้อย่างดีเท่านั้นซึ่งรูปแบบนี้มีการใช้ทุกที่

ปรับปรุง:

สิ่งที่ฉันอธิบายไว้นั้นถูกต้อง แต่สิ่งที่ฉันกำลังมองหาจริงๆคือความคิดบางอย่างว่านี่เป็นสิ่งที่ยอมรับได้หรือไม่และหากมีข้อผิดพลาดหรือวิธีปฏิบัติที่ดีที่สุดที่เกี่ยวข้อง ฉันรู้เกี่ยวกับรูปแบบของตัวสร้าง แต่มีส่วนเกี่ยวข้องกับสิ่งที่ฉันกำลังอธิบายอยู่เล็กน้อยเนื่องจาก Josh Bloch อธิบายว่ามีคลาสตัวสร้างสแตติกที่เชื่อมโยงสำหรับการสร้างวัตถุ

ฉันไม่คิดว่าจะมีอะไรผิดปกติกับมันเป็นเรื่องของสไตล์ มันมีประโยชน์เมื่อ:

• คุณต้องตั้งค่าหลายฟิลด์ในครั้งเดียว (รวมถึงที่การก่อสร้าง)
• คุณรู้ว่าต้องตั้งค่าฟิลด์ใดในเวลาที่คุณเขียนโค้ดและ
• มีชุดค่าผสมหลายชุดที่คุณต้องการตั้งค่าฟิลด์

ทางเลือกสำหรับวิธีนี้อาจเป็น:

1. ตัวสร้างเมกะหนึ่ง (ข้อเสีย: คุณอาจผ่านค่า null หรือค่าเริ่มต้นจำนวนมากและยากที่จะทราบว่าค่าใดสอดคล้องกับค่าใด)
2. คอนสตรัคเตอร์ที่โอเวอร์โหลดหลายตัว (ข้อเสีย: แย่ลงเมื่อคุณมีมากกว่าสองสาม)
3. วิธีการแบบโรงงาน / แบบคงที่ (ข้อเสีย: เช่นเดียวกับตัวสร้างที่มากเกินไป - จะเทอะทะเมื่อมีมากกว่าสองสามครั้ง)

หากคุณจะตั้งค่าคุณสมบัติเพียงไม่กี่ครั้งฉันจะบอกว่ามันไม่คุ้มค่าที่จะส่งคืน 'นี่' มันจะล้มลงอย่างแน่นอนหากคุณตัดสินใจที่จะคืนสิ่งอื่นในภายหลังเช่นสถานะ / ข้อความบ่งชี้ความสำเร็จ / ข้อความ

มันไม่ใช่การฝึกฝนที่ไม่ดี มันเป็นเรื่องธรรมดามากขึ้นเรื่อย ๆ ภาษาส่วนใหญ่ไม่ต้องการให้คุณจัดการกับวัตถุที่ส่งคืนหากคุณไม่ต้องการดังนั้นจึงไม่เปลี่ยนไวยากรณ์การใช้ตัวตั้งค่า "ปกติ" แต่อนุญาตให้คุณโยงผู้ตั้งค่าเข้าด้วยกัน

สิ่งนี้เรียกว่าลวดลายตัวสร้างหรือส่วนต่อประสานที่คล่องแคล่วอินเตอร์เฟซได้อย่างคล่องแคล่ว

เป็นเรื่องปกติใน Java API:

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

เพื่อสรุป:

• มันเรียกว่า "ส่วนต่อประสานที่คล่องแคล่ว" หรือ "วิธีผูกมัด"
• นี่ไม่ใช่ Java "มาตรฐาน" แม้ว่าคุณจะเห็นมากกว่านี้ในอีกหลายวัน (ใช้งานได้ดีใน jQuery)
• มันละเมิดข้อกำหนดของ JavaBean ดังนั้นมันจะแตกด้วยเครื่องมือและไลบรารีต่าง ๆ โดยเฉพาะอย่างยิ่งผู้สร้าง JSP และ Spring
• มันอาจป้องกันการเพิ่มประสิทธิภาพบางอย่างที่ JVM ปกติจะทำ
• บางคนคิดว่าทำความสะอาดรหัสขึ้นบางคนคิดว่ามัน "น่ากลัว"

อีกสองประเด็นที่ไม่ได้กล่าวถึง:

• นี่เป็นการละเมิดหลักการที่แต่ละฟังก์ชั่นควรทำอย่างใดอย่างหนึ่ง คุณอาจจะหรืออาจไม่เชื่อในเรื่องนี้ แต่ใน Java ฉันเชื่อว่ามันทำงานได้ดี

• IDE จะไม่สร้างสิ่งเหล่านี้ให้คุณ (โดยค่าเริ่มต้น)

• ในที่สุดฉันก็เป็นจุดข้อมูลจริง ฉันมีปัญหาในการใช้ห้องสมุดที่สร้างขึ้นเช่นนี้ ตัวสร้างแบบสอบถามของ Hibernate เป็นตัวอย่างของสิ่งนี้ในห้องสมุดที่มีอยู่ เนื่องจากเมธอด set * ของ Query ส่งคืนเคียวรีจึงเป็นไปไม่ได้ที่จะบอกเพียงแค่ดูที่ลายเซ็นวิธีใช้ ตัวอย่างเช่น:

  Query setWhatever(String what);

• มันแนะนำความกำกวม: วิธีการแก้ไขวัตถุปัจจุบัน (รูปแบบของคุณ) หรือบางทีแบบสอบถามอาจไม่เปลี่ยนรูปแบบ (รูปแบบที่นิยมและมีคุณค่ามาก) และวิธีการนี้จะคืนค่าวัตถุใหม่ มันทำให้ไลบรารีใช้งานได้ยากขึ้นและโปรแกรมเมอร์จำนวนมากไม่ใช้คุณลักษณะนี้ หากผู้ตั้งค่าเป็นผู้ตั้งค่ามันจะชัดเจนขึ้นว่าจะใช้มันอย่างไร

ฉันชอบใช้วิธี 'กับ' สำหรับสิ่งนี้:

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

ดังนั้น:

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

คำเตือน : withXไวยากรณ์นี้มักใช้เพื่อให้ "setters" สำหรับวัตถุที่ไม่เปลี่ยนรูปดังนั้นผู้โทรของวิธีการเหล่านี้อาจคาดหวังว่าพวกเขาจะสร้างวัตถุใหม่มากกว่าที่จะกลายพันธุ์ที่มีอยู่ บางทีถ้อยคำที่สมเหตุสมผลกว่านั้นก็อาจจะเป็น:

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

ด้วยอนุสัญญาการตั้งชื่อ chainsetXyz () ทุกคนควรมีความสุข

หากคุณไม่ต้องการกลับ'this'จาก setter แต่ไม่ต้องการใช้ตัวเลือกที่สองคุณสามารถใช้ไวยากรณ์ต่อไปนี้เพื่อตั้งค่าคุณสมบัติ:

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

นอกจากนี้ฉันคิดว่ามันสะอาดกว่าเล็กน้อยใน C #:

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

ไม่เพียง แต่ทำลายการประชุมของ getters / setters แต่ยังทำลายกรอบการอ้างอิงเมธอด Java 8 MyClass::setMyValueเป็นBiConsumer<MyClass,MyValue>และเป็นmyInstance::setMyValue Consumer<MyValue>หากคุณมี setter ของคุณกลับมาแสดงthisว่ามันไม่ใช่อินสแตนซ์ที่ถูกต้องอีกต่อไปConsumer<MyValue>แต่เป็น a Function<MyValue,MyClass>และจะทำให้ทุกสิ่งที่ใช้วิธีการอ้างอิงถึง setters เหล่านั้น

ฉันไม่รู้ Java แต่ฉันทำสิ่งนี้ใน C ++ คนอื่น ๆ บอกว่ามันทำให้สายยาวมากและอ่านยากจริงๆ แต่ฉันทำมันแบบนี้หลายครั้ง:

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

นี่จะดียิ่งขึ้น:

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

อย่างน้อยฉันก็คิดว่า แต่คุณยินดีที่จะ downvote ฉันและโทรหาฉันโปรแกรมเมอร์ที่น่ากลัวถ้าคุณต้องการ และฉันไม่รู้ว่าคุณได้รับอนุญาตให้ทำสิ่งนี้ใน Java หรือไม่

แบบแผนนี้ (ตั้งใจจะให้เล่น) เรียกว่า 'ส่วนต่อประสานที่คล่องแคล่ว' กำลังได้รับความนิยมอย่างมากในขณะนี้ เป็นที่ยอมรับ แต่มันไม่ใช่ถ้วยชาของฉัน

เนื่องจากมันไม่คืนค่าว่างเปล่าจึงไม่มีตัวตั้งค่าคุณสมบัติ JavaBean ที่ถูกต้องอีกต่อไป นั่นอาจสำคัญหากคุณเป็นหนึ่งในเจ็ดคนของโลกที่ใช้เครื่องมือ "Bean Builder" แบบภาพหรือหนึ่งใน 17 รายการที่ใช้องค์ประกอบ JSP-bean-setProperty

อย่างน้อย ในทางทฤษฎีมันสามารถสร้างความเสียหายกลไกการเพิ่มประสิทธิภาพของ JVM โดยการตั้งค่าการอ้างอิงเท็จระหว่างการโทร

มันควรจะเป็นน้ำตาล syntactic แต่ในความเป็นจริงสามารถสร้างผลข้างเคียงในเครื่องเสมือนอัจฉริยะสุดยอดของ Java 43

นั่นเป็นเหตุผลที่ฉันไม่ลงคะแนนอย่าใช้มัน

มันไม่ใช่การฝึกฝนที่ไม่ดีเลย แต่มันเข้ากันไม่ได้กับJavaBeans SpecSpec

และมีข้อกำหนดจำนวนมากขึ้นอยู่กับอุปกรณ์มาตรฐานเหล่านั้น

คุณสามารถทำให้พวกมันอยู่ร่วมกันได้ตลอดเวลา

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

ตอนนี้เราสามารถใช้พวกเขาร่วมกัน

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

นี่คืออีกเวอร์ชั่นสำหรับวัตถุที่ไม่เปลี่ยนรูปแบบ

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

ตอนนี้เราสามารถทำได้

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

ถ้าคุณใช้การประชุมเดียวกันในการสมัครทั้งหมดดูเหมือนว่าจะดี

ในทางตรงกันข้ามถ้าส่วนที่มีอยู่ของแอปพลิเคชันของคุณใช้การประชุมมาตรฐานฉันจะยึดมันและเพิ่มผู้สร้างให้กับคลาสที่ซับซ้อนมากขึ้น

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 คล่องแคล่ว: กำหนดคลาสตัวสร้างภายในสำหรับแต่ละ JavaBean หากคุณกำลังใช้เครื่องมือที่ทำให้ผู้ตั้งเครื่องไม่พอใจที่ส่งคืนค่ารูปแบบของเปาโลอาจช่วยได้

ฉันชอบเซ็ตเทอร์ที่มี "สิ่งนี้" ส่งคืน ฉันไม่สนใจว่ามันจะไม่สอดคล้องกับถั่วหรือไม่ สำหรับฉันถ้ามันไม่เป็นไรที่จะมี "=" การแสดงออก / คำสั่งแล้ว setters ที่กลับค่าเป็นเรื่องปกติ

ฉันเคยชอบวิธีการนี้ แต่ฉันได้ตัดสินใจต่อต้านมัน

เหตุผล:

• การอ่าน มันทำให้โค้ดอ่านง่ายขึ้นเพื่อให้แต่ละ setFoo () ในบรรทัดแยกต่างหาก คุณมักจะอ่านรหัสหลาย ๆ ครั้งมากกว่าครั้งเดียวที่คุณเขียน
• ผลข้างเคียง: setFoo () ควรตั้งค่าฟิลด์ foo เท่านั้นไม่มีอะไรอื่น การย้อนกลับมานี้เป็นสิ่งพิเศษ "อะไรคือสิ่งนั้น"

รูปแบบตัวสร้างที่ฉันเห็นไม่ใช้ setFoo (foo) .setBar (bar) แบบแผน แต่มี foo (foo) .bar (bar) มากกว่า บางทีด้วยเหตุผลเหล่านั้น

มันเป็นเรื่องของรสชาติเสมอ ฉันชอบวิธีการที่ "เซอร์ไพรส์น้อยที่สุด"

รูปแบบเฉพาะนี้เรียกว่าวิธีการผูกมัด ลิงก์ Wikipediaนี้มีคำอธิบายเพิ่มเติมและตัวอย่างของการใช้ภาษาโปรแกรมต่างๆ

PS: แค่คิดถึงที่จะออกจากที่นี่เพราะฉันกำลังมองหาชื่อที่เฉพาะเจาะจง

ตั้งแต่แรกเห็น: "น่ากลัว!"

เมื่อคิดต่อไป

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

มีข้อผิดพลาดน้อยกว่าแนวโน้ม

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

ค่อนข้างน่าสนใจ กำลังเพิ่มแนวคิดลงใน toolbag ...

ใช่ฉันคิดว่ามันเป็นความคิดที่ดี

หากฉันสามารถเพิ่มบางสิ่งได้สิ่งที่เกี่ยวกับปัญหานี้:

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

สิ่งนี้จะได้ผล:

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

Eclipse จะไม่ได้รับการยอมรับ! :

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

นี่เป็นเพราะ setName () ส่งคืน People และไม่ใช่เพื่อนและไม่มี PeoplesetNickName

เราจะเขียน setters เพื่อส่งคืนคลาส SELF แทนชื่อคลาสได้อย่างไร?

สิ่งนี้จะเป็นเรื่องปกติ (ถ้ามีคำหลัก SELF อยู่) สิ่งนี้มีอยู่แล้วหรือไม่?

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

โดยทั่วไปแล้วมันเป็นแนวปฏิบัติที่ดี แต่คุณอาจจำเป็นต้องใช้ฟังก์ชั่น set-type ใช้ประเภทบูลีนเพื่อพิจารณาว่าการดำเนินการเสร็จสมบูรณ์หรือไม่นั่นเป็นวิธีหนึ่งเช่นกัน โดยทั่วไปไม่มีความเชื่อที่จะพูดว่านี่เป็นสิ่งที่ดีหรือเตียงมันมาจากสถานการณ์แน่นอน

จากคำสั่ง

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

ฉันเห็นสองสิ่ง

1) คำสั่งที่ไม่มีความหมาย 2) ขาดความสามารถในการอ่าน

สิ่งนี้อาจอ่านได้น้อย

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

หรือสิ่งนี้

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

วิธีนี้อ่านได้ง่ายกว่า:

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

ฉันได้สร้าง setters ของฉันมาระยะหนึ่งแล้วและปัญหาที่แท้จริงเพียงอย่างเดียวก็คือกับห้องสมุดที่ติดกับ getPropertyDescriptors ที่เข้มงวดเพื่อรับ bean access / ถั่วนักเขียนถั่ว ในกรณีเหล่านั้นจาวา "bean" ของคุณจะไม่มีนักเขียนที่คุณคาดหวัง

ตัวอย่างเช่นฉันยังไม่ได้ทดสอบอย่างแน่นอน แต่ฉันจะไม่แปลกใจเลยที่แจ็คสันจะไม่จดจำสิ่งเหล่านั้นว่าเป็นตัวตั้งค่าเมื่อสร้างวัตถุ java ของคุณจาก json / maps ฉันหวังว่าฉันผิดในนี้ (ฉันจะทดสอบในไม่ช้า)

ในความเป็นจริงฉันกำลังพัฒนา ORM ที่มีน้ำหนักเบาของ SQL และฉันต้องเพิ่มโค้ด beyong getPropertyDescriptors ให้กับ setters ที่รู้จักซึ่งส่งคืนสิ่งนี้

นานมาแล้วที่คำตอบ แต่ฉันทั้งสองเซ็นต์ ... มันดี ฉันหวังว่าอินเทอร์เฟซที่คล่องแคล่วนี้ใช้บ่อยขึ้น

การทำซ้ำตัวแปร 'factory' จะไม่เพิ่มข้อมูลเพิ่มเติมด้านล่าง:

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

นี่สะอาดกว่า imho:

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

แน่นอนว่าเป็นหนึ่งในคำตอบที่กล่าวถึงแล้ว Java API จะต้องได้รับการปรับแต่งให้ทำอย่างถูกต้องในบางสถานการณ์เช่นการสืบทอดและเครื่องมือ

มันจะดีกว่าที่จะใช้โครงสร้างภาษาอื่นถ้ามี ยกตัวอย่างเช่นใน Kotlin คุณจะใช้กับ , ใช้หรือปล่อยให้ หากใช้วิธีนี้คุณไม่จำเป็นต้องส่งคืนอินสแตนซ์จาก setter ของคุณ

วิธีนี้ช่วยให้รหัสลูกค้าของคุณเป็น:

• ไม่สนใจประเภทการส่งคืน
• บำรุงรักษาง่ายกว่า
• หลีกเลี่ยงผลข้างเคียงของคอมไพเลอร์

นี่คือตัวอย่างบางส่วน.

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

หากฉันกำลังเขียน API ฉันจะใช้ "return this" เพื่อตั้งค่าที่จะถูกตั้งเพียงครั้งเดียว หากฉันมีค่าอื่น ๆ ที่ผู้ใช้ควรจะสามารถเปลี่ยนแปลงได้ฉันจะใช้ setter void มาตรฐานแทน

อย่างไรก็ตามมันเป็นเรื่องของการตั้งค่าและ setters ลูกโซ่จะดูค่อนข้างเย็นในความคิดของฉัน

ฉันเห็นด้วยกับผู้โพสต์ทั้งหมดที่อ้างถึงการแบ่งข้อกำหนด JavaBeans มีเหตุผลที่จะเก็บรักษาไว้ แต่ฉันก็รู้สึกว่าการใช้รูปแบบตัวสร้างนี้ (ที่กล่าวถึง) นั้นมีอยู่ ตราบใดที่มันไม่ได้ใช้ทุกที่ก็ควรจะยอมรับได้ "สถานที่" สำหรับฉันคือที่ที่จุดสิ้นสุดคือการเรียกใช้วิธีการ "build ()"

มีวิธีอื่นในการตั้งค่าสิ่งเหล่านี้ทั้งหมดแน่นอน แต่ข้อดีที่นี่คือมันหลีกเลี่ยง 1) ตัวสร้างสาธารณะที่มีพารามิเตอร์หลายตัวและ 2) วัตถุที่ระบุบางส่วน ที่นี่คุณมีตัวสร้างรวบรวมสิ่งที่ต้องการแล้วเรียกว่า "build ()" ในตอนท้ายซึ่งสามารถมั่นใจได้ว่าวัตถุที่ระบุบางส่วนไม่ได้ถูกสร้างขึ้นเนื่องจากการดำเนินการนั้นสามารถมองเห็นได้น้อยกว่าที่สาธารณะ ทางเลือกจะเป็น "อ็อบเจกต์พารามิเตอร์" แต่ IMHO จะผลักปัญหากลับไปหนึ่งระดับ

ฉันไม่ชอบคอนสตรัคเตอร์พารามิเตอร์จำนวนมากเพราะพวกมันทำให้มีโอกาสมากขึ้นที่อาร์กิวเมนต์ประเภทเดียวกันจำนวนมากจะถูกส่งผ่านซึ่งจะทำให้ง่ายต่อการส่งอาร์กิวเมนต์ที่ไม่ถูกต้องไปยังพารามิเตอร์ ฉันไม่ชอบการใช้ setters มากมายเพราะสามารถใช้วัตถุก่อนที่จะถูกกำหนดค่าอย่างสมบูรณ์ นอกจากนี้แนวคิดของการมีค่าเริ่มต้นตามตัวเลือกก่อนหน้านี้จะให้บริการที่ดีขึ้นด้วยวิธีการ "สร้าง ()"

ในระยะสั้นฉันคิดว่ามันเป็นการปฏิบัติที่ดีถ้าใช้อย่างถูกต้อง

นิสัยที่ไม่ดี: สุนัขเซทเทอร์ตั้งตัวให้ทะเยอทะยาน

สิ่งที่เกี่ยวกับการประกาศวิธีการที่ชัดเจนสำหรับ U

setPropertyFromParams(array $hashParamList) { ... }