การสร้างวัตถุขนาดใหญ่ที่ไม่เปลี่ยนรูปโดยไม่ใช้ตัวสร้างที่มีรายการพารามิเตอร์ยาว ๆ

ฉันมีวัตถุขนาดใหญ่ (มากกว่า 3 ช่อง) ที่สามารถและไม่เปลี่ยนรูปได้ ทุกครั้งที่ฉันเจอกรณีนั้นฉันมักจะสร้างสิ่งที่น่ารังเกียจของตัวสร้างที่มีรายการพารามิเตอร์ยาว ๆ

รู้สึกไม่ถูกต้องใช้ยากและความสามารถในการอ่านไม่เพียงพอ

จะยิ่งแย่ไปกว่านั้นถ้าฟิลด์นั้นเป็นประเภทคอลเลกชันบางประเภทเช่นรายการ วิธีง่ายๆaddSibling(S s)จะทำให้การสร้างวัตถุง่ายขึ้นมาก แต่ทำให้วัตถุไม่แน่นอน

พวกคุณใช้อะไรในกรณีเช่นนี้?

ฉันใช้ Scala และ Java แต่ฉันคิดว่าปัญหาคือภาษาไม่เชื่อเรื่องพระเจ้าตราบใดที่ภาษานั้นมุ่งเน้นไปที่วัตถุ

วิธีแก้ปัญหาที่ฉันคิดได้:

1. "สิ่งที่น่ารังเกียจของตัวสร้างที่มีรายการพารามิเตอร์ยาว"
2. รูปแบบตัวสร้าง

คุณต้องการให้ทั้งวัตถุที่อ่านง่ายขึ้นและไม่เปลี่ยนรูปเมื่อสร้างขึ้นแล้วหรือไม่?

ฉันคิดว่าอินเทอร์เฟซที่คล่องแคล่วทำได้อย่างถูกต้องจะช่วยคุณได้

จะมีลักษณะดังนี้ (ตัวอย่างที่สร้างขึ้นทั้งหมด):

final Foo immutable = FooFactory.create()
    .whereRangeConstraintsAre(100,300)
    .withColor(Color.BLUE)
    .withArea(234)
    .withInterspacing(12)
    .build();

ฉันเขียนว่า"ทำอย่างถูกต้อง" เป็นตัวหนาเนื่องจากโปรแกรมเมอร์ Java ส่วนใหญ่ใช้อินเทอร์เฟซที่ไม่ถูกต้องและทำให้วัตถุของพวกเขาสกปรกด้วยวิธีการที่จำเป็นในการสร้างวัตถุซึ่งแน่นอนว่าผิดอย่างสิ้นเชิง

เคล็ดลับคือมีเพียงวิธี build () เท่านั้นที่สร้าง Foo ได้จริง (ดังนั้นคุณ Foo จึงไม่สามารถเปลี่ยนรูปได้)

FooFactory.create ()โดยที่XXX (.. )และwithXXX (.. )ล้วนสร้าง "อย่างอื่น"

อย่างอื่นอาจเป็น FooFactory นี่เป็นวิธีหนึ่งที่จะทำได้ ....

คุณ FooFactory จะมีลักษณะดังนี้:

// Notice the private FooFactory constructor
private FooFactory() {
}

public static FooFactory create() {
    return new FooFactory();
}

public FooFactory withColor( final Color col ) {
    this.color = color;
    return this;
}

public Foo build() {
    return new FooImpl( color, and, all, the, other, parameters, go, here );
}

ใน Scala 2.8 คุณสามารถใช้พารามิเตอร์ที่ตั้งชื่อและดีฟอลต์ตลอดจนcopyวิธีการในคลาสเคส นี่คือตัวอย่างโค้ด:

case class Person(name: String, age: Int, children: List[Person] = List()) {
  def addChild(p: Person) = copy(children = p :: this.children)
}

val parent = Person(name = "Bob", age = 55)
  .addChild(Person("Lisa", 23))
  .addChild(Person("Peter", 16))

ลองพิจารณาสิ่งนี้กับ Scala 2.8:

case class Person(name: String, 
                  married: Boolean = false, 
                  espouse: Option[String] = None, 
                  children: Set[String] = Set.empty) {
  def marriedTo(whom: String) = this.copy(married = true, espouse = Some(whom))
  def addChild(whom: String) = this.copy(children = children + whom)
}

scala> Person("Joseph").marriedTo("Mary").addChild("Jesus")
res1: Person = Person(Joseph,true,Some(Mary),Set(Jesus))

สิ่งนี้มีส่วนแบ่งของปัญหาแน่นอน ตัวอย่างเช่นลองทำespouseและOption[Person]จากนั้นให้คนสองคนแต่งงานกัน ฉันคิดวิธีแก้ปัญหานั้นไม่ได้โดยไม่ต้องใช้ทั้ง a private varและ / หรือตัวprivateสร้างบวกกับโรงงาน

นี่คือตัวเลือกเพิ่มเติมสองสามตัวเลือก:

ตัวเลือกที่ 1

ทำให้การใช้งานไม่แน่นอน แต่แยกอินเทอร์เฟซที่เปิดเผยว่าไม่สามารถเปลี่ยนแปลงได้และไม่เปลี่ยนรูป สิ่งนี้นำมาจากการออกแบบห้องสมุด Swing

public interface Foo {
  X getX();
  Y getY();
}

public interface MutableFoo extends Foo {
  void setX(X x);
  void setY(Y y);
}

public class FooImpl implements MutableFoo {...}

public SomeClassThatUsesFoo {
  public Foo makeFoo(...) {
    MutableFoo ret = new MutableFoo...
    ret.setX(...);
    ret.setY(...);
    return ret; // As Foo, not MutableFoo
  }
}

ทางเลือกที่ 2

หากแอปพลิเคชันของคุณมีชุดของวัตถุที่ไม่เปลี่ยนรูปขนาดใหญ่ แต่กำหนดไว้ล่วงหน้า (เช่นอ็อบเจ็กต์การกำหนดค่า) คุณอาจพิจารณาใช้Spring framework

มันจะช่วยให้จำได้ว่ามีความแตกต่างกันชนิดของการเปลี่ยนไม่ได้ สำหรับกรณีของคุณฉันคิดว่าการไม่เปลี่ยนรูปของ "ไอติม" จะใช้ได้ดีจริงๆ:

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

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

คุณยังสามารถทำให้อ็อบเจกต์ไม่เปลี่ยนรูปแสดงเมธอดที่ดูเหมือน mutators (เช่น addSibling) แต่ปล่อยให้มันส่งคืนอินสแตนซ์ใหม่ นั่นคือสิ่งที่คอลเลกชัน Scala ไม่เปลี่ยนรูปทำ

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

ตัวอย่างเช่นขอบกราฟที่ไม่มีปลายทาง แต่ไม่ใช่ขอบกราฟที่ถูกต้อง

พิจารณาความเป็นไปได้สี่ประการ:

new Immutable(one, fish, two, fish, red, fish, blue, fish); /*1 */

params = new ImmutableParameters(); /*2 */
params.setType("fowl");
new Immutable(params);

factory = new ImmutableFactory(); /*3 */
factory.setType("fish");
factory.getInstance();

Immutable boringImmutable = new Immutable(); /* 4 */
Immutable lessBoring = boringImmutable.setType("vegetable");

สำหรับฉันแต่ละ 2, 3 และ 4 ถูกปรับให้เข้ากับสถานการณ์ที่แตกต่างกัน คนแรกยากที่จะรักด้วยเหตุผลที่ OP อ้างถึงและโดยทั่วไปเป็นอาการของการออกแบบที่มีอาการคืบคลานและต้องการการปรับโครงสร้างใหม่

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

ในที่สุดคำตอบของคนอื่นกล่าวถึงตัวเลือก (4) ซึ่งคุณมีวัตถุที่ไม่เปลี่ยนรูปจำนวนมากและรูปแบบที่ดีกว่าคือการรับข่าวสารจากของเก่า

โปรดทราบว่าฉันไม่ใช่สมาชิกของ 'แพทเทิร์นแฟนคลับ' - แน่นอนว่าบางสิ่งก็ควรค่าแก่การเลียนแบบ แต่สำหรับฉันแล้วดูเหมือนว่าพวกเขาจะใช้ชีวิตแบบไร้ประโยชน์เมื่อมีคนตั้งชื่อและหมวกตลก ๆ ให้พวกเขา

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

ฉันใช้ C # และนี่คือแนวทางของฉัน พิจารณา:

class Foo
{
    // private fields only to be written inside a constructor
    private readonly int i;
    private readonly string s;
    private readonly Bar b;

    // public getter properties
    public int I { get { return i; } }
    // etc.
}

ตัวเลือกที่ 1. ตัวสร้างที่มีพารามิเตอร์เสริม

public Foo(int i = 0, string s = "bla", Bar b = null)
{
    this.i = i;
    this.s = s;
    this.b = b;
}

new Foo(5, b: new Bar(whatever))ใช้เป็นเช่น ไม่ใช่สำหรับ Java หรือ C # เวอร์ชันก่อน 4.0 แต่ก็ยังคุ้มค่าที่จะแสดงเนื่องจากเป็นตัวอย่างว่าโซลูชันทั้งหมดไม่ใช่ภาษาที่เข้าใจได้ง่าย

ตัวเลือกที่ 2 ตัวสร้างรับวัตถุพารามิเตอร์เดียว

public Foo(FooParameters parameters)
{
    this.i = parameters.I;
    // etc.
}

class FooParameters
{
    // public properties with automatically generated private backing fields
    public int I { get; set; }
    public string S { get; set; }
    public Bar B { get; set; }

    // All properties are public, so we don't need a full constructor.
    // For convenience, you could include some commonly used initialization
    // patterns as additional constructors.
    public FooParameters() { }
}

ตัวอย่างการใช้งาน:

FooParameters fp = new FooParameters();
fp.I = 5;
fp.S = "bla";
fp.B = new Bar();
Foo f = new Foo(fp);`

C # จาก 3.0 on ทำให้สิ่งนี้ดูหรูหรายิ่งขึ้นด้วยไวยากรณ์ของ object initializer (เทียบเท่าความหมายกับตัวอย่างก่อนหน้า):

FooParameters fp = new FooParameters { I = 5, S = "bla", B = new Bar() };
Foo f = new Foo(fp);

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