ถูกต้องตามกฎหมาย "งานจริง" ในตัวสร้างหรือไม่?

ฉันทำงานเกี่ยวกับการออกแบบ แต่กดปุ่มสิ่งกีดขวางบนถนนต่อไป ฉันมีคลาสเฉพาะ (ModelDef) ที่เป็นหลักเจ้าของต้นไม้โหนดซับซ้อนที่สร้างขึ้นโดยการแยก XML schema (คิด DOM) ฉันต้องการปฏิบัติตามหลักการออกแบบที่ดี (SOLID) และตรวจสอบให้แน่ใจว่าระบบผลลัพธ์นั้นสามารถทดสอบได้ง่าย ฉันมีความตั้งใจที่จะใช้ DI เพื่อส่งผ่านการพึ่งพาในตัวสร้างของ ModelDef (เพื่อให้สามารถสลับสิ่งเหล่านี้ได้อย่างง่ายดายถ้าจำเป็นระหว่างการทดสอบ)

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

แต่ฉันอ่านต่อไปว่าคอนสตรัคเตอร์ไม่ควรทำงานจริงใด ๆ (เช่นFlaw: Constructor ทำงานจริง ) นี่เป็นเหตุผลที่เหมาะสมสำหรับฉันหาก "งานจริง" หมายถึงการสร้างวัตถุที่ต้องอาศัยน้ำหนักมากซึ่งในภายหลังอาจต้องการเริ่มต้นการทดสอบ (สิ่งเหล่านั้นควรถูกส่งผ่านทาง DI)

แต่สิ่งที่เกี่ยวกับวัตถุค่าน้ำหนักเบาเช่นต้นไม้โหนดนี้ ต้องสร้างต้นไม้ที่ไหนสักแห่งใช่มั้ย ทำไมไม่สร้างผ่าน ModelDef (ใช้, พูด, buildNodeTree () วิธี)?

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

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

และนอกจากสิ่งที่ Ross Patterson แนะนำให้พิจารณาตำแหน่งนี้ซึ่งเป็นสิ่งที่ตรงกันข้าม:

1. ใช้ประโยชน์สูงสุดเช่น "เจ้าจะไม่ทำงานจริงใด ๆ ในสิ่งก่อสร้างของเจ้า" ด้วยเม็ดเกลือ

2. ตัวสร้างคือจริงๆไม่มีอะไรนอกจากวิธีการแบบคงที่ ดังนั้นโครงสร้างไม่มีความแตกต่างระหว่าง:

   a) ตัวสร้างอย่างง่ายและวิธีการคงที่ของโรงงานที่ซับซ้อนและ

   b) คอนสตรัคเตอร์ที่เรียบง่ายและกลุ่มคอนสตรัคเตอร์ที่ซับซ้อนมากขึ้น

ส่วนสำคัญของความรู้สึกด้านลบต่อการทำงานจริงใด ๆ ในคอนสตรัคเตอร์มาจากช่วงเวลาหนึ่งในประวัติศาสตร์ของซีพลัสพลัสเมื่อมีการถกเถียงกันอย่างชัดเจนว่าสถานะของวัตถุจะถูกทิ้งไว้ในข้อยกเว้นหรือไม่ destructor ควรถูกเรียกใช้ในเหตุการณ์ดังกล่าว ประวัติศาสตร์ส่วนหนึ่งของ C ++ นั้นจบลงแล้วและปัญหาได้รับการแก้ไขแล้วในขณะที่ในภาษาอย่าง Java ไม่เคยมีปัญหาแบบนี้มาก่อน

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

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

การแก้ไข

ฉันคิดว่าถ้าคุณมีวิธีการด้านนอกModelDefซึ่งสร้างModelDefจาก XML คุณจะต้องสร้างโครงสร้างข้อมูลต้นไม้แบบไดนามิกชั่วคราวขึ้นมาโดยแยกวิเคราะห์ XML ของคุณแล้วสร้างModelDefโครงสร้างใหม่ที่ส่งผ่านเป็นพารามิเตอร์คอนสตรัคเตอร์ ดังนั้นอาจคิดได้ว่าเป็นแอปพลิเคชันของรูปแบบ "ตัวสร้าง" มีการเปรียบเทียบที่ใกล้เคียงกันมากระหว่างสิ่งที่คุณต้องการทำกับString& StringBuilderคู่ แต่ฉันได้พบ Q & A นี้ซึ่งดูเหมือนว่าจะไม่เห็นด้วยสำหรับเหตุผลที่ไม่ชัดเจนกับผม: Stackoverflow - StringBuilder และสร้างรูปแบบ ดังนั้นเพื่อหลีกเลี่ยงการถกเถียงกันยาว ๆ ตรงนี้ไม่ว่าจะเป็นStringBuilderหรือไม่ใช้รูปแบบ "ผู้สร้าง" ฉันจะบอกว่ารู้สึกอิสระที่จะได้รับแรงบันดาลใจจากวิธีการStrungBuilder ทำงานในการหาวิธีแก้ปัญหาที่เหมาะสมกับความต้องการของคุณและเลื่อนการเรียกมันว่าเป็นแอพพลิเคชั่นของรูปแบบ "ตัวสร้าง" จนกว่ารายละเอียดเล็ก ๆ น้อย ๆ จะถูกตัดสิน

ดูคำถามใหม่ล่าสุดนี้: โปรแกรมเมอร์ SE:“ StringBuilder” เป็นแอพพลิเคชั่นของ Builder Design Pattern หรือไม่?

คุณได้ให้เหตุผลที่ดีที่สุดแล้วที่จะไม่ทำงานนี้ในModelDefConstructor:

1. ไม่มี "น้ำหนักเบา" เกี่ยวกับการแยกวิเคราะห์เอกสาร XML ลงในทรีของโหนด
2. ไม่มีอะไรที่ชัดเจนเกี่ยวกับModelDefที่ระบุว่าสามารถสร้างได้จากเอกสาร XML เท่านั้น

มันเสียงเหมือนชั้นเรียนของคุณควรมีความหลากหลายของวิธีการแบบคงเหมือนModelDef.FromXmlString(string xmlDocument), ModelDef.FromXmlDoc(XmlDoc parsedNodeTree), ฯลฯ

ฉันเคยได้ยินว่า "กฎ" ก่อน จากประสบการณ์ของฉันมันเป็นทั้งจริงและเท็จ

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

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

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

ดังนั้นใครถูก

ไม่มีใครจริงๆ โรงเรียนแห่งความคิดทั้งสองแห่งมีข้อดี ในปัจจุบัน SOLID คือความโกรธเกรี้ยวและทุกคนกำลังพูดถึง SRP และ Open / Closed และแจ๊สทั้งหมดนั้น แต่เนื่องจากสิ่งที่เป็นที่นิยมไม่ได้หมายความว่ามันเป็นตัวเลือกการออกแบบที่ถูกต้องสำหรับทุกแอปพลิเคชัน ดังนั้นมันขึ้นอยู่กับ หากคุณกำลังทำงานในฐานรหัสที่เป็นไปตามหลักการของ SOLID อย่างมากใช่แล้วงานจริงในตัวสร้างอาจเป็นความคิดที่ไม่ดี แต่อย่างอื่นดูสถานการณ์และพยายามใช้วิจารณญาณของคุณ ออบเจ็กต์ของคุณมีคุณสมบัติใดที่จะได้รับจากการทำงานใน Constructor คุณสมบัติใดที่มันจะสูญเสีย ? มันเหมาะสมกับสถาปัตยกรรมโดยรวมของแอปพลิเคชันของคุณดีแค่ไหน?

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

มีปัญหาพื้นฐานกับกฎนี้และนี่คือสิ่งที่ถือว่า "งานจริง"?

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

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

วัตถุไม่ได้เริ่มต้นอย่างเต็มที่หลังจากที่เสร็จสิ้นการสร้าง นี่เป็นกฎที่ดี แต่ก็ขัดแย้งกับกฎอื่น ๆ ที่กล่าวถึงในบทความนั้น ตัวอย่างที่ดีของวิธีการที่ขัดแย้งกับคนอื่น ๆ ถูกกล่าวถึงคำถามที่นำฉันมาที่นี่ ในคำถามนั้นมีคนกังวลเกี่ยวกับการใช้sortวิธีการในนวกรรมิกในสิ่งที่ดูเหมือนจะเป็น JavaScript เพราะหลักการนี้ ในตัวอย่างนี้บุคคลกำลังสร้างวัตถุที่แสดงรายการเรียงลำดับของวัตถุอื่น ๆ เพื่อจุดประสงค์ในการสนทนาให้จินตนาการว่าเรามีรายการวัตถุที่ไม่เรียงลำดับและเราต้องการวัตถุใหม่เพื่อแสดงรายการที่เรียงลำดับ เราต้องการวัตถุใหม่นี้เพราะบางส่วนของซอฟต์แวร์ของเราคาดว่าจะเรียงลำดับรายการและให้เรียกวัตถุนี้SortedList. วัตถุใหม่นี้ยอมรับรายการที่ไม่เรียงลำดับและวัตถุที่เป็นผลลัพธ์ควรแสดงรายการวัตถุที่เรียงลำดับแล้ว ถ้าเราต้องทำตามกฎอื่น ๆ ที่กล่าวถึงใน doc นั่นคือไม่มีการเรียกเมธอดแบบสแตติกไม่มีโครงสร้างโฟลว์การควบคุมไม่มีอะไรมากไปกว่าการมอบหมายดังนั้นวัตถุที่เป็นผลลัพธ์จะไม่ถูกสร้างขึ้นในสถานะที่ถูกต้อง หลังจากตัวสร้างเสร็จสิ้น ในการแก้ไขปัญหานี้เราจะต้องทำงานพื้นฐานบางอย่างเพื่อสร้างรายการที่ไม่เรียงลำดับซึ่งจัดเรียงไว้ในตัวสร้าง การทำเช่นนี้จะทำให้เสียกฎ 3 ข้อทำให้กฎอื่น ๆ ไม่เกี่ยวข้อง

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

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