คำถามติดแท็ก factory-method

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

10
มันเป็นรูปแบบการต่อต้านถ้าทรัพย์สินชั้นสร้างและส่งกลับตัวอย่างใหม่ของชั้นเรียนหรือไม่?
ฉันมีคลาสที่เรียกHeadingว่าทำสิ่งเล็ก ๆ น้อย ๆ แต่ก็ควรที่จะสามารถคืนค่าตรงกันข้ามกับค่าหัวเรื่องปัจจุบันซึ่งในที่สุดจะต้องใช้ผ่านการสร้างอินสแตนซ์ใหม่ของHeadingคลาสเอง ฉันสามารถมีคุณสมบัติแบบง่าย ๆ ที่เรียกว่าreciprocalให้ส่งคืนหัวเรื่องตรงข้ามของค่าปัจจุบันจากนั้นสร้างอินสแตนซ์ใหม่ของคลาสหัวเรื่องด้วยตนเองหรือฉันสามารถสร้างวิธีที่ต้องการcreateReciprocalHeading()สร้างอินสแตนซ์ใหม่ของคลาสหัวเรื่องโดยอัตโนมัติ ผู้ใช้งาน อย่างไรก็ตามหนึ่งในเพื่อนร่วมงานของฉันแนะนำให้ฉันเพียงแค่สร้างคุณสมบัติคลาสที่เรียกreciprocalว่าคืนค่าอินสแตนซ์ใหม่ของคลาสเองผ่านเมธอด getter คำถามของฉันคือ: มันเป็นรูปแบบต่อต้านหรือไม่สำหรับคุณสมบัติของคลาสที่จะทำเช่นนั้น? ฉันพบว่ามันใช้งานง่ายน้อยลงเพราะ: ในใจของฉันคุณสมบัติของคลาสไม่ควรส่งคืนอินสแตนซ์ใหม่ของคลาสและ ชื่อของคุณสมบัติซึ่งreciprocalไม่ได้ช่วยให้นักพัฒนาสามารถเข้าใจพฤติกรรมของมันได้อย่างสมบูรณ์โดยไม่ได้รับความช่วยเหลือจาก IDE หรือตรวจสอบลายเซ็นของ getter ฉันเข้มงวดเกินไปเกี่ยวกับคุณสมบัติของคลาสที่ควรทำหรือเป็นข้อกังวลที่ถูกต้อง? ฉันพยายามจัดการสถานะของคลาสผ่านฟิลด์และคุณสมบัติของมันตลอดจนพฤติกรรมของมันผ่านวิธีการของมันและฉันล้มเหลวในการดูว่าสิ่งนี้เหมาะกับนิยามของคลาสของคุณสมบัติอย่างไร

3
โรงงานคงเทียบกับโรงงานเป็นซิงเกิล
ในบางรหัสของฉันฉันมีโรงงานแบบคงที่เช่นนี้: public class SomeFactory { // Static class private SomeFactory() {...} public static Foo createFoo() {...} public static Foo createFooerFoo() {...} } ในระหว่างการตรวจสอบรหัสมันก็เสนอว่าควรจะเป็นซิงเกิลตันและฉีด ดังนั้นควรมีลักษณะดังนี้: public class SomeFactory { public SomeFactory() {} public Foo createFoo() {...} public Foo createFooerFoo() {...} } บางสิ่งที่ควรเน้น: โรงงานทั้งสองไร้สัญชาติ ข้อแตกต่างระหว่างเมธอดคือขอบเขต (อินสแตนซ์ vs คงที่) การใช้งานเหมือนกัน Foo เป็นถั่วที่ไม่มีส่วนต่อประสาน ข้อโต้แย้งที่ฉันได้รับจากการคงที่คือ: …

2
ฉันควรใช้วิธีการจากโรงงานแทนที่จะเป็นตัวสร้าง ฉันสามารถเปลี่ยนสิ่งนั้นและยังเข้ากันได้แบบย้อนหลังได้หรือไม่
ปัญหา สมมติว่าฉันมีคลาสที่เรียกว่าDataSourceมีReadDataวิธี (และบางทีคนอื่น ๆ แต่ให้สิ่งที่ง่าย) เพื่ออ่านข้อมูลจาก.mdbไฟล์: var source = new DataSource("myFile.mdb"); var data = source.ReadData(); ไม่กี่ปีต่อมาฉันตัดสินใจว่าฉันต้องการให้สามารถรองรับ.xmlไฟล์เพิ่มเติมจาก.mdbไฟล์เป็นแหล่งข้อมูล การนำไปใช้สำหรับ "การอ่านข้อมูล" นั้นค่อนข้างแตกต่างกันสำหรับ.xmlและ.mdbไฟล์ ดังนั้นถ้าฉันจะออกแบบระบบตั้งแต่เริ่มต้นฉันจะนิยามมันดังนี้: abstract class DataSource { abstract Data ReadData(); static DataSource OpenDataSource(string fileName) { // return MdbDataSource or XmlDataSource, as appropriate } } class MdbDataSource : DataSource { override Data ReadData() { …

3
การสร้างหลาย ๆ การใช้งาน DI สิ้นหวังไหม ใช้บริการระบุตำแหน่งหรือไม่
สมมติว่าเรามีลูกค้า 1001 รายที่สร้างการพึ่งพาโดยตรงแทนที่จะยอมรับการฉีด Refactoring the 1001 ไม่ใช่ตัวเลือกตามที่เจ้านายของเรา จริงๆแล้วเราไม่ได้รับอนุญาตให้เข้าถึงแหล่งข้อมูลของพวกเขาเพียงแค่ไฟล์คลาส สิ่งที่เราควรจะทำคือ "ปรับปรุง" ระบบที่ลูกค้า 1001 เหล่านี้ผ่านให้ได้ เราสามารถ refactor ที่เราชอบ การพึ่งพาเป็นส่วนหนึ่งของระบบนั้น และการพึ่งพาเหล่านั้นบางอย่างเราควรเปลี่ยนไปใช้การติดตั้งใหม่ สิ่งที่เราต้องการจะทำคือมีความสามารถในการกำหนดค่าการใช้งานที่แตกต่างกันของการอ้างอิงเพื่อตอบสนองลูกค้าจำนวนมากนี้ น่าเสียดายที่ DI ไม่ได้ดูตัวเลือกเนื่องจากลูกค้าไม่ยอมรับการฉีดด้วยตัวสร้างหรือผู้ตั้งค่า ตัวเลือก: 1) Refactor การปรับใช้บริการที่ลูกค้าใช้เพื่อให้เป็นไปตามที่ลูกค้าต้องการ ปังเราเสร็จแล้ว ไม่ยืดหยุ่น ไม่ซับซ้อน 2) ปรับโครงสร้างการนำไปใช้ใหม่เพื่อให้ผู้รับมอบสิทธิ์สามารถทำงานให้กับการพึ่งพาอื่นที่ได้มาจากโรงงาน ตอนนี้เราสามารถควบคุมว่าการใช้งานแบบใดที่พวกเขาใช้โดยการปรับโครงสร้างโรงงานอีกครั้ง 3) ปรับโครงสร้างการนำไปใช้ใหม่เพื่อให้ผู้รับมอบสิทธิ์สามารถทำงานได้กับการพึ่งพาอื่นที่ได้รับผ่านตัวระบุบริการ ตอนนี้เราสามารถควบคุมได้ว่าการใช้งานใดที่พวกเขาใช้โดยการกำหนดค่าบริการตัวระบุตำแหน่งซึ่งอาจเป็นhashmapสตริงของวัตถุที่มีการแคสต์เล็กน้อย 4) บางสิ่งที่ฉันยังไม่ได้คิดเลย วัตถุประสงค์: ลดความเสียหายที่เกิดจากการออกแบบโดยการลากรหัสลูกค้าเก่าที่ออกแบบมาไม่ดีในอนาคตโดยไม่เพิ่มความซับซ้อนที่ไม่มีจุดหมาย ลูกค้าไม่ควรจะรู้หรือควบคุมการดำเนินงานของการอ้างอิงของพวกเขา newแต่พวกเขายืนยันในการสร้างพวกเขาด้วย เราไม่สามารถควบคุมได้newแต่เราควบคุมชั้นเรียนที่พวกเขากำลังสร้าง คำถามของฉัน: ฉันไม่ได้พิจารณาอะไร คำถามจาก Doc Brown คุณต้องการความเป็นไปได้ที่จะกำหนดค่าระหว่างการใช้งานที่แตกต่างกันหรือไม่? เพื่อจุดประสงค์อะไร? ความว่องไว …

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

3
หลีกเลี่ยงการก่อสร้างที่มีข้อโต้แย้งมากมาย
ดังนั้นฉันจึงมีโรงงานที่สร้างวัตถุของคลาสที่แตกต่างกัน คลาสที่เป็นไปได้ทั้งหมดมาจากบรรพบุรุษที่เป็นนามธรรม โรงงานมีไฟล์กำหนดค่า (ไวยากรณ์ JSON) และตัดสินใจว่าจะสร้างคลาสใดขึ้นอยู่กับการกำหนดค่าของผู้ใช้ เพื่อให้บรรลุสิ่งนี้โรงงานใช้ boost :: property_tree สำหรับ JSON-parsing เขาเดินผ่านต้นไม้ต้นทรีและตัดสินใจเลือกวัตถุที่เป็นรูปธรรมเพื่อสร้าง อย่างไรก็ตามผลิตภัณฑ์วัตถุมีหลายฟิลด์ (คุณลักษณะ) วัตถุมีคุณสมบัติประมาณ 5-10 ตัวในอนาคตอาจมีมากกว่านี้ขึ้นอยู่กับคลาสที่เป็นรูปธรรม ดังนั้นฉันไม่แน่ใจว่าตัวสร้างของวัตถุควรมีลักษณะอย่างไร ฉันสามารถคิดถึงวิธีแก้ปัญหาสองข้อ: 1) ตัวสร้างของผลิตภัณฑ์คาดว่าทุกแอตทริบิวต์เป็นพารามิเตอร์ดังนั้นตัวสร้างจะลงท้ายด้วยพารามิเตอร์ 10+ สิ่งนี้จะน่าเกลียดและนำไปสู่บรรทัดโค้ดที่ยาวและอ่านไม่ได้ อย่างไรก็ตามข้อดีคือโรงงานสามารถแยกวิเคราะห์ JSON และเรียกใช้ตัวสร้างด้วยพารามิเตอร์ที่ถูกต้อง คลาสผลิตภัณฑ์ไม่จำเป็นต้องรู้ว่าถูกสร้างขึ้นเนื่องจากการกำหนดค่า JSON ไม่จำเป็นต้องรู้ว่ามี JSON หรือการกำหนดค่าที่เกี่ยวข้องเลย 2) คอนสตรัคเตอร์ของผลิตภัณฑ์คาดว่าจะมีอาร์กิวเมนต์เดียวคือออบเจ็กต์ property_tree จากนั้นมันก็สามารถแยกวิเคราะห์ข้อมูลที่จำเป็น หากข้อมูลในการกำหนดค่าขาดหายไปหรือไม่อยู่ในขอบเขตของแต่ละคลาสผลิตภัณฑ์สามารถตอบสนองได้อย่างถูกต้อง โรงงานไม่จำเป็นต้องทราบว่าผลิตภัณฑ์หลายตัวต้องการข้อโต้แย้งใด โรงงานยังไม่จำเป็นต้องรู้วิธีการตอบสนองในกรณีที่มีการกำหนดค่าผิดพลาด และอินเทอร์เฟซตัวสร้างเป็นปึกแผ่นและเล็ก แต่ในฐานะที่เป็นข้อเสียผลิตภัณฑ์จำเป็นต้องดึงข้อมูลที่ต้องการจาก JSON ดังนั้นจึงรู้ได้ว่ามันถูกสร้างขึ้นอย่างไร ฉันมักจะชอบโซลูชัน 2) อย่างไรก็ตามฉันไม่แน่ใจว่านี่เป็นรูปแบบโรงงานที่ดีหรือไม่ รู้สึกผิดอย่างใดอย่างหนึ่งที่ทำให้ผลิตภัณฑ์ทราบว่าสร้างขึ้นด้วยการกำหนดค่า JSON ในอีกด้านหนึ่งผลิตภัณฑ์ใหม่สามารถแนะนำง่ายมาก ความคิดเห็นใด …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.