ทำไมประเภทจะควบคู่ไปกับการสร้าง?

ฉันเพิ่งลบคำตอบjavaของฉันในการตรวจสอบรหัสที่เริ่มต้นเช่นนี้:

private Person(PersonBuilder builder) {

หยุด. ธงแดง PersonBuilder จะสร้างบุคคล มันรู้เกี่ยวกับบุคคล คลาส Person ไม่ควรรู้อะไรเกี่ยวกับ PersonBuilder - เป็นเพียงประเภทที่ไม่เปลี่ยนรูป คุณสร้างคัปปลิ้งแบบวงกลมตรงนี้โดยที่ A ขึ้นอยู่กับ B ซึ่งขึ้นอยู่กับ A

บุคคลนั้นควร จำกัด พารามิเตอร์ของตน ลูกค้าที่เต็มใจสร้างบุคคลโดยไม่สร้างมันควรจะสามารถทำเช่นนั้นได้

ฉันถูกตบด้วย downvote และบอกว่า (อ้างถึง) การตั้งค่าสถานะสีแดงทำไม? การใช้งานที่นี่มีรูปร่างเดียวกับที่ Joshua Bloch แสดงในหนังสือ "Effective Java" ของเขา (รายการ # 2)

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

private StreetMap(Builder builder) {
    // Required parameters
    origin      = builder.origin;
    destination = builder.destination;

    // Optional parameters
    waterColor         = builder.waterColor;
    landColor          = builder.landColor;
    highTrafficColor   = builder.highTrafficColor;
    mediumTrafficColor = builder.mediumTrafficColor;
    lowTrafficColor    = builder.lowTrafficColor;
}

_{^{https://en.wikipedia.org/wiki/Builder_pattern#Java_example}}

หน้า Wikipedia เดียวกันสำหรับรูปแบบ Builder เดียวกันนั้นมีการปรับใช้ (และยืดหยุ่นมากกว่า) สำหรับ C #:

//Represents a product created by the builder
public class Car
{
    public Car()
    {
    }

    public int Wheels { get; set; }

    public string Colour { get; set; }
}

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

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

ดังนั้นการจัดการคืออะไร? ทำไมต้องคิดหาวิธีแก้ปัญหาที่เกินความคาดหมายเพื่อแก้ปัญหาที่ไม่ควรมีอยู่ในตอนแรก? หากเราถอด Joshua Bloch ออกจากแท่นเป็นเวลาหนึ่งนาทีเราจะคิดหาเหตุผลที่ดีและเป็นเหตุผลเดียวสำหรับการเชื่อมต่อคอนกรีตสองประเภทและเรียกมันว่าเป็นแนวปฏิบัติที่ดีที่สุดหรือไม่?

ทั้งหมดนี้เป็นการเขียนโปรแกรมการขนส่งสินค้าทางศาสนาให้ฉัน

ฉันไม่เห็นด้วยกับการยืนยันของคุณว่ามันเป็นธงสีแดง ฉันยังไม่เห็นด้วยกับการเป็นตัวแทนของความแตกต่างของคุณว่ามีวิธีหนึ่งที่เหมาะสมในการเป็นตัวแทนของรูปแบบการสร้าง

สำหรับฉันมีคำถามหนึ่งข้อ: ตัวสร้างเป็นส่วนที่จำเป็นของ API ประเภทหรือไม่ นี่เป็น PersonBuilder เป็นส่วนที่จำเป็นของคน API?

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

หากเป็นกรณีที่จำเป็นต้องสร้างบุคคลผ่าน PersonBuilder ที่ให้มาซึ่งเป็นส่วนหนึ่งของการออกแบบ API ระดับแพ็กเกจเดียวการเชื่อมต่อแบบวงกลมนั้นทำได้ดีและไม่ได้รับการรับประกันธงสีแดงที่นี่ โดยเฉพาะอย่างยิ่งคุณระบุว่ามันเป็นความจริงที่ไม่สามารถเพิกถอนได้และไม่ใช่ความคิดเห็นหรือการออกแบบ API เพื่อให้อาจตอบสนองได้ไม่ดี ฉันจะไม่ได้ downvoted คุณ แต่ผมไม่โทษคนอื่นสำหรับการทำเช่นนั้นและฉันจะออกจากส่วนที่เหลือของการอภิปรายของ "สิ่งที่ใบสำคัญแสดงสิทธิ downvote" เพื่อที่ศูนย์ช่วยเหลือรหัสตรวจสอบและเมตา Downvotes เกิดขึ้น; มันไม่ใช่ "ตบ"

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

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

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

ต้องบอกว่าฉันคิดว่าหลักฐานของการโต้แย้งของคุณเหมือนกัน เราไม่ควรมีเพศสัมพันธ์สองประเภทที่เป็นรูปธรรมและเรียกมันว่าเป็นแนวปฏิบัติที่ดีที่สุดเพราะ ... มีคนพูดอย่างนั้นหรือ

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

Offhand ฉันพยายามดิ้นรนเพื่อดูว่าทั้งสองวิธีจะสร้างปัญหาได้อย่างไร ชั้นเรียนมีการเชื่อมโยงอย่างสมบูรณ์แน่นอน แต่ผู้สร้างอยู่เพียงเพื่อสร้างอินสแตนซ์ของชั้นเรียน อีกวิธีในการดูมันจะเป็นส่วนเสริมของตัวสร้าง

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

ทำไมการมีพารามิเตอร์จำนวนมากจึงบอกเป็นนัยว่าคุณควรใช้เครื่องมือสร้าง? การมีพารามิเตอร์จำนวนมากไม่ใช่เรื่องแปลกในโลกแห่งความเป็นจริงและไม่ละเมิดหลักการความรับผิดชอบเดียว นอกจากนี้ยัง sucks เมื่อคุณมีสิบพารามิเตอร์ String และพยายามที่จะจำสิ่งที่อยู่และไม่ว่าจะเป็นสตริงที่ห้าหรือหกที่ควรเป็นโมฆะ ผู้สร้างช่วยให้จัดการพารามิเตอร์ได้ง่ายขึ้นและยังสามารถทำสิ่งดีๆอื่น ๆ ที่คุณควรอ่านหนังสือเพื่อหาข้อมูล

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

ผลิตภัณฑ์ในรูปแบบที่สร้างสรรค์ไม่จำเป็นต้องรู้อะไรเกี่ยวกับสิ่งที่สร้างมันขึ้นมา

Personชั้นไม่ได้รู้ว่าสิ่งที่สร้างมัน มันมีเพียงนวกรรมิกที่มีพารามิเตอร์ดังนั้นอะไร ชื่อประเภทของพารามิเตอร์ลงท้ายด้วย... Builderซึ่งไม่ได้บังคับอะไรเลย มันเป็นเพียงชื่อหลังจากทั้งหมด

ตัวสร้างเป็นวัตถุการกำหนดค่าที่ได้รับเกียรติ¹ และวัตถุการกำหนดค่าเป็นเพียงการจัดกลุ่มคุณสมบัติเข้าด้วยกันที่เป็นของกันและกัน หากพวกเขาเป็นของกันและกันเพื่อจุดประสงค์ในการส่งผ่านไปยังผู้สร้างชั้นเรียนดังนั้นไม่ว่าจะเป็น! ทั้งสองoriginและdestinationของตัวอย่างเป็นประเภทStreetMap Pointเป็นไปได้ไหมที่จะส่งพิกัดแต่ละจุดของแต่ละจุดบนแผนที่ แน่นอนว่า แต่คุณสมบัติของสิ่งนั้นPointอยู่ด้วยกันรวมทั้งคุณสามารถมีวิธีการทุกอย่างที่ช่วยในการก่อสร้าง:

¹ความแตกต่างคือตัวสร้างไม่ได้เป็นเพียงวัตถุข้อมูลธรรมดา แต่อนุญาตให้มีการเรียกตัวตั้งค่าที่ถูกล่ามโซ่เหล่านี้ เป็นห่วงส่วนใหญ่กับวิธีการสร้างตัวเองBuilder

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

1. มันสรุปการกระทำ: เรียกวิธีการของชั้นเรียนอื่น
2. มันเก็บข้อมูลที่จำเป็นในการดำเนินการนั้น: ค่าสำหรับพารามิเตอร์ของวิธีการ

ส่วนพิเศษสำหรับผู้สร้างคือ:

1. วิธีการที่จะเรียกว่าเป็นตัวสร้างของชั้นเรียน ดีกว่าเรียกว่ารูปแบบ Creationalในขณะนี้
2. ค่าสำหรับพารามิเตอร์คือตัวสร้าง

สิ่งที่ถูกส่งไปยังตัวPersonสร้างสามารถสร้างได้ แต่ไม่จำเป็นต้องทำ มันอาจเป็นวัตถุการกำหนดค่าเก่าธรรมดาหรือตัวสร้าง

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