โรงงานคงเทียบกับโรงงานเป็นซิงเกิล

ในบางรหัสของฉันฉันมีโรงงานแบบคงที่เช่นนี้:

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 เป็นถั่วที่ไม่มีส่วนต่อประสาน

ข้อโต้แย้งที่ฉันได้รับจากการคงที่คือ:

• คลาสไร้สัญชาติดังนั้นจึงไม่จำเป็นต้องมีการยกตัวอย่าง
• ดูเหมือนเป็นธรรมชาติมากขึ้นที่จะสามารถเรียกใช้วิธีการคงที่กว่าที่จะต้องยกตัวอย่างโรงงาน

ข้อโต้แย้งสำหรับโรงงานในฐานะซิงเกิลคือ:

• มันเป็นการดีที่จะฉีดทุกอย่าง
• แม้จะไร้สัญชาติของโรงงานการทดสอบก็ง่ายขึ้นด้วยการฉีด (ง่ายต่อการเยาะเย้ย)
• มันควรจะล้อเลียนเมื่อทดสอบผู้บริโภค

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

ชุมชนคิดอย่างไร ในขณะที่ฉันไม่ชอบวิธีการเดี่ยว แต่ฉันไม่ได้มีข้อโต้แย้งที่แข็งแกร่งมากกับมัน

ทำไมคุณต้องแยกโรงงานของคุณออกจากประเภทวัตถุที่สร้างขึ้น

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

นี่คือสิ่งที่ Joshua Bloch อธิบายไว้ในข้อ 1 ของเขาในหน้า 5 ของหนังสือ "Effective Java" Java นั้นเพียงพอแล้วโดยไม่ต้องเพิ่มคลาสพิเศษและซิงเกิลตันและอะไรอื่นอีก มีบางกรณีที่คลาสโรงงานแยกต่างหากเหมาะสม แต่มีอยู่ไม่มาก

ในการถอดความรายการที่ Joshua Bloch 1 ซึ่งต่างจากตัวสร้างวิธีการคงที่ของโรงงานสามารถ:

• มีชื่อที่สามารถอธิบายประเภทการสร้างวัตถุเฉพาะ (Bloch ใช้ probablePrime (int, int, Random) เป็นตัวอย่าง)
• ส่งคืนวัตถุที่มีอยู่ (คิดว่า: flyweight)
• ส่งคืนชนิดย่อยของคลาสดั้งเดิมหรืออินเทอร์เฟซที่ใช้
• ลดความฟุ่มเฟื่อย (จากการระบุพารามิเตอร์ประเภท - ดู Bloch ตัวอย่าง)

ข้อเสีย:

• คลาสที่ไม่มี public หรือ constructor ที่ได้รับการป้องกันไม่สามารถ subclassed (แต่คุณสามารถใช้ constructors ที่ได้รับการป้องกันและ / หรือรายการที่ 16: คอมโพสิตที่โปรดปรานมากกว่าการสืบทอด)
• วิธีการที่คงที่จากโรงงานไม่โดดเด่นจากวิธีการคงที่อื่น ๆ (ใช้ชื่อมาตรฐานเช่น () หรือ valueOf ())

จริง ๆ แล้วคุณควรนำหนังสือของ Bloch ไปให้ผู้ตรวจสอบรหัสของคุณและดูว่าคุณสองคนเห็นด้วยกับสไตล์ของ Bloch หรือไม่

เพียงแค่ด้านบนของหัวของฉันนี่คือปัญหาบางอย่างกับสถิตศาสตร์ใน Java:

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

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

• เขตข้อมูลสถิตค่อนข้างคล้ายกับกลม

คุณพูดถึง:

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

ซึ่งทำให้ฉันอยากถามคุณ:

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

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

ลองนึกภาพว่าแอปพลิเคชันของคุณวิวัฒนาการและตอนนี้ในบางกรณีคุณจำเป็นต้องสร้างFooBar(คลาสย่อยของ Foo) ตอนนี้คุณต้องไปผ่านทุกสถานที่ในรหัสของคุณที่รู้เกี่ยวกับคุณSomeFactoryและเขียนชนิดของตรรกะบางอย่างที่มีลักษณะที่someConditionและบริการโทรหรือSomeFactory SomeOtherFactoryที่จริงแล้วเมื่อดูที่โค้ดตัวอย่างของคุณมันแย่กว่านั้น คุณวางแผนที่จะเพิ่มเพียงวิธีหลังจากวิธีการสร้าง Foos ที่แตกต่างกันและรหัสลูกค้าทั้งหมดของคุณจะต้องตรวจสอบเงื่อนไขก่อนที่จะหาว่า Foo ตัวไหนจะทำ ซึ่งหมายความว่าลูกค้าทุกคนจำเป็นต้องมีความรู้ที่ลึกซึ้งเกี่ยวกับวิธีการทำงานของโรงงานของคุณและพวกเขาทั้งหมดต้องเปลี่ยนเมื่อใดก็ตามที่จำเป็นต้องมี Foo ใหม่ (หรือลบออก!)

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

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

คำถามสามารถนำเสนอในคำแนะนำหรือแบบฝึกหัด (ซึ่งทั้งคู่นำไปใช้IContentBlock) ดังนั้นแต่ละคำถามInstructionsFactoryหรือExerciseFactoryจะได้รับสำเนาของ QuestionFactoryMap จากนั้นจะมีการส่งคำแนะนำและโรงงานการออกกำลังกายต่างๆContentBlockBuilderซึ่งจะเป็นการแฮชที่จะใช้เมื่อใด และเมื่อโหลด XML แล้ว ContentBlockBuilder จะเรียกใช้แบบฝึกหัดหรือคำแนะนำจากโรงงานและขอให้ทำcreateContent()แล้วโรงงานจะมอบหมายการสร้างคำถามให้กับสิ่งที่มันดึงออกมาจากภายใน QuestionFactoryMap อยู่ในแต่ละโหนด XML เทียบกับแฮช น่าเสียดายที่สิ่งนั้นเป็นสิ่งBaseQuestionแทนIQuestionแต่นั่นก็แสดงให้เห็นว่าแม้ในขณะที่คุณระมัดระวังในการออกแบบคุณสามารถทำผิดพลาดที่สามารถหลอกหลอนคุณได้

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