คลาสย่อยของตัวสร้างเท่านั้น: นี่เป็นรูปแบบการต่อต้านหรือไม่

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

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

ตัวอย่างเช่นลองพิจารณาชั้นเรียนชีวิตจริงนี้:

public class DataHelperBuilder
{
    public string DatabaseEngine { get; set; }
    public string ConnectionString { get; set; }

    public DataHelperBuilder(string databaseEngine, string connectionString)
    {
        DatabaseEngine = databaseEngine;
        ConnectionString = connectionString;
    }

    // Other optional "DataHelper" configuration settings omitted

    public DataHelper CreateDataHelper()
    {
        Type dataHelperType = DatabaseEngineTypeHelper.GetType(DatabaseEngine);
        DataHelper dh = (DataHelper)Activator.CreateInstance(dataHelperType);
        dh.SetConnectionString(ConnectionString);

        // Omitted some code that applies decorators to the returned object
        // based on omitted configuration settings

        return dh;
    }
}

การอ้างสิทธิ์ของเขาคือมันจะเหมาะสมอย่างยิ่งที่จะมีคลาสย่อยเช่นนี้:

public class SystemDataHelperBuilder
{
    public SystemDataHelperBuilder()
        : base(Configuration.GetSystemDatabaseEngine(),
               Configuration.GetSystemConnectionString())
    {
    }
 }

ดังนั้นคำถาม:

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

ฉันขอโทษถ้าสิ่งนี้กลายเป็นคำตอบที่ googleable ได้อย่างง่ายดาย การค้นหาของฉันบน google ส่วนใหญ่ส่งคืนข้อมูลเกี่ยวกับรูปแบบการต่อต้านการสร้างเหลื่อมและไม่ใช่สิ่งที่ฉันกำลังมองหา

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

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

ข้อใดต่อไปนี้ถูกต้อง?

เพื่อนร่วมงานของคุณถูกต้อง (สมมติว่าเป็นระบบประเภทมาตรฐาน)

ลองคิดดูว่าคลาสจะเป็นค่าทางกฎหมายที่เป็นไปได้หรือไม่ หากคลาสAมีหนึ่งฟิลด์Fคุณอาจมีแนวโน้มที่จะคิดว่าAมีค่าตามกฎหมาย 256 ตัว แต่ปรีชานั้นไม่ถูกต้อง Aกำลัง จำกัด "การเปลี่ยนแปลงค่าทุกครั้งที่เคย" ถึง "ต้องมีฟิลด์Fเป็น 0-255"

ถ้าคุณขยายAด้วยBซึ่งมีข้อมูลไบต์อีกFFนั่นคือการเพิ่มข้อ จำกัด แทนที่จะเป็น "value where Fis byte" คุณมี "value Fat byte && FFเป็น byte" เมื่อคุณรักษากฎเก่าทุกอย่างที่ทำงานให้กับ basetype จะยังคงใช้ได้กับประเภทย่อยของคุณ แต่เนื่องจากคุณกำลังเพิ่มกฎคุณจึงมีความเชี่ยวชาญนอกเหนือจาก "อาจเป็นอะไรก็ได้"

หรือจะคิดว่ามันอีกทางหนึ่งสมมติว่าAมีพวงของเชื้อ: การB, และC DตัวแปรชนิดAอาจเป็นชนิดย่อยใด ๆ ก็ได้ แต่ตัวแปรชนิดBนั้นมีความเฉพาะเจาะจงมากกว่า มัน (มากที่สุดในระบบการพิมพ์) ไม่สามารถเป็นหรือCD

นี่เป็นรูปแบบการต่อต้านหรือไม่

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

ฉันจะไม่พิจารณารูปแบบการต่อต้านนี้เนื่องจากมันไม่ได้ผิดอย่างชัดเจนและไม่ดีในทุกสถานการณ์

ไม่ไม่ใช่รูปแบบการต่อต้าน ฉันสามารถนึกถึงกรณีการใช้งานจริงจำนวนหนึ่งสำหรับสิ่งนี้:

1. หากคุณต้องการใช้การตรวจสอบเวลาการคอมไพล์เพื่อให้แน่ใจว่าการรวบรวมวัตถุเป็นไปตามคลาสย่อยหนึ่ง ๆ เท่านั้น ตัวอย่างเช่นถ้าคุณมีMySQLDaoและSqliteDaoในระบบของคุณ แต่ด้วยเหตุผลบางอย่างที่คุณต้องการตรวจสอบให้แน่ใจว่าการรวบรวมมีเพียงข้อมูลจากแหล่งเดียวหากคุณใช้คลาสย่อยตามที่คุณอธิบายคุณสามารถให้คอมไพเลอร์ตรวจสอบความถูกต้องนี้ ในทางตรงกันข้ามถ้าคุณเก็บแหล่งข้อมูลเป็นเขตข้อมูลสิ่งนี้จะกลายเป็นการตรวจสอบเวลาทำงาน
2. โปรแกรมปัจจุบันของฉันมีหนึ่งถึงความสัมพันธ์แบบหนึ่งระหว่างAlgorithmConfiguration+ และProductClass AlgorithmInstanceในคำอื่น ๆ ถ้าคุณกำหนดค่าFooAlgorithmสำหรับProductClassในไฟล์คุณสมบัติคุณสามารถจะได้รับหนึ่งFooAlgorithmสำหรับการเรียนผลิตภัณฑ์ที่ วิธีเดียวที่จะได้รับสองFooAlgorithmสำหรับรับคือการสร้างประเภทรองProductClass FooBarAlgorithmไม่เป็นไรเพราะมันทำให้ไฟล์คุณสมบัติใช้งานง่าย (ไม่จำเป็นต้องใช้ไวยากรณ์สำหรับการกำหนดค่าต่างๆในส่วนหนึ่งของไฟล์คุณสมบัติ) และหายากมากที่จะมีอินสแตนซ์มากกว่าหนึ่งรายการสำหรับคลาสผลิตภัณฑ์ที่กำหนด
3. คำตอบของ @ Telastyn เป็นอีกตัวอย่างที่ดี

บรรทัดล่าง: ไม่มีอันตรายใด ๆ ในการทำเช่นนี้ รูปแบบการต่อต้านถูกกำหนดให้เป็น:

anti-pattern (หรือ antipattern) เป็นการตอบสนองต่อปัญหาที่เกิดซ้ำซึ่งมักจะไม่ได้ผลและมีความเสี่ยงที่จะถูกต่อต้านอย่างมาก

ไม่มีความเสี่ยงในการต่อต้านอย่างมากที่นี่ดังนั้นจึงไม่ใช่รูปแบบการต่อต้าน

หากบางอย่างเป็นรูปแบบหรือ antipattern ขึ้นอยู่กับภาษาและสภาพแวดล้อมที่คุณกำลังเขียนอย่างมีนัยสำคัญตัวอย่างเช่นforลูปเป็นรูปแบบในแอสเซมบลี C และภาษาที่คล้ายกันและ anti-pattern ใน lisp

ให้ฉันเล่าเรื่องของโค้ดที่ฉันเขียนมานานแล้ว ...

มันเป็นภาษาที่เรียกว่าLPCและใช้กรอบสำหรับการร่ายคาถาในเกม คุณมีคาถา superclass ซึ่งมี subclass ของคาถาต่อสู้ที่จัดการเช็คบางส่วนและจากนั้น subclass สำหรับคาถาสร้างความเสียหายโดยตรงเป้าหมายเดียวซึ่งถูก subclassed ไปยังคาถาแต่ละอย่าง - ขีปนาวุธสายฟ้าและอื่น ๆ

ลักษณะของการทำงานของ LPC คือคุณมีออบเจ็กต์หลักที่เป็น Singleton ก่อนที่คุณจะไป 'eww Singleton' - มันเป็นและมันก็ไม่ใช่ "eww" เลย ไม่มีใครทำสำเนาของคาถา แต่เรียกวิธีการคงที่ (มีประสิทธิภาพ) ในคาถา รหัสสำหรับขีปนาวุธเวทมนตร์ดูเหมือนว่า:

inherit "spells/direct";

void init() {
  ::init();
  damage = 10;
  cost = 3;
  delay = 1.0;
  caster_message = "You cast a magic missile at ${target}";
  target_message = "You are hit with a magic missile cast by ${caster}";
}

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

การเรียงลำดับของรูปแบบนี้แปลสถานการณ์อื่น ๆ ที่คุณมีคลาสย่อยที่ขยายคลาสนามธรรมและตั้งค่าบางอย่างของตัวเอง แต่ฟังก์ชั่นทั้งหมดอยู่ในคลาสนามธรรมที่สืบทอด ลองดูที่StringBuilderใน Java สำหรับตัวอย่างนี้ - ไม่ใช่คอนสตรัคเตอร์เท่านั้น แต่ฉันกดเพื่อค้นหาตรรกะจำนวนมากในวิธีการด้วยตนเอง (ทุกอย่างอยู่ใน AbstractStringBuilder)

นี่ไม่ใช่สิ่งเลวร้ายและแน่นอนว่าไม่ใช่รูปแบบการต่อต้าน (และในบางภาษาอาจเป็นรูปแบบตัวเอง)

การใช้คลาสย่อยที่พบบ่อยที่สุดที่ฉันคิดได้คือลำดับชั้นยกเว้นแม้ว่าจะเป็นกรณีที่เลวลงซึ่งโดยทั่วไปแล้วเราจะไม่นิยามอะไรเลยในชั้นเรียนตราบใดที่ภาษาช่วยให้เราสามารถสร้างคอนสตรัคชันได้ เราใช้มรดกที่จะแสดงว่าReadErrorเป็นกรณีพิเศษIOErrorและอื่น ๆ แต่ไม่จำเป็นต้องแทนที่วิธีการใดReadError ๆIOError

เราทำเช่นนี้เพราะมีข้อยกเว้นเกิดขึ้นจากการตรวจสอบประเภทของพวกเขา ดังนั้นเราจำเป็นต้องเข้ารหัสความเชี่ยวชาญในประเภทเพื่อให้ใครบางคนสามารถจับได้ReadErrorโดยไม่ต้องจับทั้งหมดIOErrorพวกเขาควรจะต้องการ

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

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

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

อย่างไรก็ตามการใช้งานประเภทสำหรับกรณีพิเศษอาจทำให้เกิดความสับสนเนื่องจากหากImmutableRectangle(1,1)และมีImmutableSquare(1)พฤติกรรมที่แตกต่างไปในทางใดทางหนึ่งในที่สุดก็มีคนสงสัยว่าทำไมและอาจไม่ต้องการ ซึ่งแตกต่างจากลำดับชั้นยกเว้นคุณตรวจสอบไม่ว่าจะเป็นรูปสี่เหลี่ยมผืนผ้าเป็นตารางโดยการตรวจสอบว่าไม่ได้กับheight == width instanceofในตัวอย่างของคุณมีความแตกต่างระหว่าง a SystemDataHelperBuilderและที่DataHelperBuilderสร้างขึ้นด้วยอาร์กิวเมนต์เดียวกันที่แน่นอนและที่อาจเกิดปัญหา ดังนั้นฟังก์ชั่นในการส่งคืนวัตถุที่สร้างขึ้นด้วยอาร์กิวเมนต์ "ด้านขวา" นั้นโดยปกติแล้วฉันจะทำสิ่งที่ถูกต้อง: คลาสย่อยส่งผลให้เกิดการแสดงสองแบบที่แตกต่างกันของสิ่งที่ "เหมือนกัน" และมันจะช่วยถ้าคุณทำอะไรบางอย่าง ตามปกติจะพยายามไม่ทำ

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

คำจำกัดความเชิงวัตถุที่เข้มงวดที่สุดของความสัมพันธ์คลาสย่อยเรียกว่า "is-a" การใช้ตัวอย่างดั้งเดิมของสี่เหลี่ยมและสี่เหลี่ยมสี่เหลี่ยม« is-a »สี่เหลี่ยม

โดยสิ่งนี้คุณควรใช้คลาสย่อยสำหรับสถานการณ์ใด ๆ ที่คุณรู้สึกว่า« is-a »เป็นความสัมพันธ์ที่มีความหมายสำหรับรหัสของคุณ

ในกรณีเฉพาะของคลาสย่อยที่ไม่มีอะไรนอกจากคอนสตรัคเตอร์คุณควรวิเคราะห์มันจากมุมมอง« is-a » เป็นที่ชัดเจนว่า SystemDataHelperBuilder « is-a » DataHelperBuilder ดังนั้นการส่งผ่านครั้งแรกจึงเป็นการใช้งานที่ถูกต้อง

คำถามที่คุณควรตอบคือรหัสอื่นใดที่ใช้ประโยชน์จากความสัมพันธ์« is-a »นี้ รหัสอื่นใดพยายามแยกแยะ SystemDataHelperBuilders จากประชากรทั่วไปของ DataHelperBuilders หรือไม่? ถ้าเป็นเช่นนั้นความสัมพันธ์ค่อนข้างสมเหตุสมผลและคุณควรเก็บคลาสย่อย

อย่างไรก็ตามหากไม่มีรหัสอื่นให้ทำสิ่งนี้สิ่งที่คุณมีคือ Relationshp ที่อาจเป็นความสัมพันธ์« is-a »หรือสามารถนำไปใช้กับโรงงานได้ ในกรณีนี้คุณสามารถไปทางใดทางหนึ่ง แต่ฉันอยากจะแนะนำโรงงานมากกว่าความสัมพันธ์« is-a » เมื่อวิเคราะห์รหัสเชิงวัตถุที่เขียนโดยบุคคลอื่นลำดับชั้นของชั้นเรียนเป็นแหล่งข้อมูลที่สำคัญ มันให้ความสัมพันธ์« is-a »ที่พวกเขาจะต้องทำความเข้าใจเกี่ยวกับโค้ด ดังนั้นการวางพฤติกรรมนี้ลงในคลาสย่อยส่งเสริมพฤติกรรมจาก "สิ่งที่บางคนจะพบถ้าพวกเขาขุดเข้าไปในวิธีการของซูเปอร์คลาส" เป็น "สิ่งที่ทุกคนจะมองผ่านก่อนที่พวกเขาจะเริ่มดำน้ำในรหัส" การอ้างอิง Guido van Rossum "รหัสถูกอ่านบ่อยกว่าที่เขียนไว้" ดังนั้นการลดความสามารถในการอ่านรหัสของคุณสำหรับนักพัฒนาซอฟต์แวร์ที่กำลังจะมาถึงคือราคาที่ต้องจ่าย ฉันจะเลือกที่จะไม่จ่ายเงินถ้าฉันสามารถใช้โรงงานแทน

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

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

ฉันคิดว่ากุญแจสำคัญในการตอบคำถามนี้คือการดูที่สถานการณ์การใช้งานเฉพาะนี้

การสืบทอดใช้เพื่อบังคับใช้ตัวเลือกการกำหนดค่าฐานข้อมูลเช่นสตริงการเชื่อมต่อ

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

ฉันใช้คลาสย่อยของนวกรรมิกคอนสตรัคเตอร์อย่างสม่ำเสมอเพื่อแสดงแนวคิดที่แตกต่าง

ตัวอย่างเช่นพิจารณาคลาสต่อไปนี้:

public class Outputter
{
    private readonly IOutputMethod outputMethod;
    private readonly IDataMassager dataMassager;

    public Outputter(IOutputMethod outputMethod, IDataMassager dataMassager)
    {
        this.outputMethod = outputMethod;
        this.dataMassager = dataMassager;
    }

    public MassageDataAndOutput(string data)
    {
        this.outputMethod.Output(this.dataMassager.Massage(data));
    }
}

จากนั้นเราสามารถสร้างคลาสย่อย:

public class CapitalizeAndPrintOutputter : Outputter
{
    public CapitalizeAndPrintOutputter()
        : base(new PrintOutputMethod(), new Capitalizer())
    {
    }
}

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

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

ให้ฉันทราบก่อนว่าเป็นรหัสที่ถูกเขียน, sub-class ไม่เฉพาะเจาะจงมากขึ้นที่ผู้ปกครองเป็น, ขณะที่ทั้งสองฟิลด์เริ่มต้นได้ทั้งคู่ตั้งโดยรหัสลูกค้า.

อินสแตนซ์ของคลาสย่อยสามารถแยกความแตกต่างได้โดยใช้ downcast

ตอนนี้ถ้าคุณมีการออกแบบที่subclass DatabaseEngineและConnectionStringคุณสมบัติถูกนำมาใช้ใหม่ซึ่งเข้าถึงได้Configurationคุณก็มีข้อ จำกัด ที่ทำให้รู้สึกว่ามี subclass มากขึ้น

ต้องบอกว่า "การต่อต้านลวดลาย" นั้นแรงเกินไปสำหรับรสนิยมของฉัน ไม่มีอะไรผิดปกติที่นี่

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

โดยทั่วไปถ้าลูกค้าของ datahelperbuilder คือการได้รับ systemdatahelperbuilder ไม่มีอะไรจะทำลาย ตัวเลือกอื่นจะต้องมี systemdatahelperbuilder เป็นอินสแตนซ์แบบคงที่ของคลาส datahelperbuilder