ทางเลือกอื่นของ Singleton คืออะไร

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

หากไม่มีซิงเกิลตันเราต้องส่งอินสแตนซ์ไปทั่วทุกที่ในโค้ดของเรา มันยุ่งมากเราเลยเขียนเสื้อคลุมซิงเกิลตัน ตอนนี้เรากำลังย้ายรหัสเดียวกันไปยัง PHP และ. NET ฉันสงสัยว่ามีรูปแบบที่ดีกว่าที่เราสามารถใช้กับวัตถุกำหนดค่าได้หรือไม่

บล็อกทดสอบของ Googleมีชุดของรายการที่เกี่ยวกับการหลีกเลี่ยงโทน (เพื่อสร้างรหัสทดสอบ) สิ่งนี้อาจช่วยคุณได้:

• ใช้การฉีดแบบพึ่งพาเพื่อหลีกเลี่ยงเสื้อกล้าม
• Singletons เป็นคนโกหกทางพยาธิวิทยา
• ต้นตอของ Singletons
• Singletons ทั้งหมดหายไปไหนแล้ว?

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

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

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

จากนั้นวัตถุทั้งหมดของคุณจะมีข้อมูลที่เคยอาศัยอยู่ในซิงเกิลตัน ฉันไม่คิดว่าโดยรวมจะมีความแตกต่างกันมากนัก แต่มันทำให้โค้ดของคุณอ่านง่ายขึ้น

ฉันอาจจะระบุสิ่งที่ชัดเจนที่นี่ แต่มีเหตุผลที่คุณไม่สามารถใช้กรอบการพึ่งพาการฉีดเช่นSpringหรือGuice ได้หรือไม่? (ฉันเชื่อว่า Spring ก็มีให้บริการสำหรับ. NET แล้วเช่นกัน)

ด้วยวิธีนี้เฟรมเวิร์กสามารถเก็บสำเนาของวัตถุการกำหนดค่าได้เพียงชุดเดียวและถั่วของคุณ (บริการ DAO หรืออะไรก็ได้) ไม่ต้องกังวลกับการค้นหา

นี่คือแนวทางที่ฉันมักจะทำ!

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

คุณจะได้รับประโยชน์จากอินสแตนซ์เดียวโดยไม่มีการเชื่อมต่อของรูปแบบ Singleton

อีกทางเลือกหนึ่งคือการส่งผ่านสิ่งที่คุณต้องการแทนที่จะถามสิ่งต่างๆ

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

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

ลอง refactoring รหัสของคุณเพื่อหลีกเลี่ยงการร่วมกันทั่วโลกและใหญ่Configurationวัตถุ ส่งผ่านพารามิเตอร์ที่จำเป็นไปยังคลาสไคลเอนต์เท่านั้น:

class Server {

    int port;

    Server(Configuration config) {
        this.port = config.getServerPort();
    } 

}

ควรปรับโครงสร้างใหม่เป็น:

 class Server {

    public Server(int port) {
       this.port = port;
    }
 }

กรอบพึ่งพาการฉีดจะช่วยได้มากที่นี่ แต่มันไม่จำเป็นต้อง stricly

คุณสามารถทำพฤติกรรมเดียวกันของซิงเกิลตันได้โดยใช้วิธีการคงที่ สตีฟ Yegge อธิบายได้ดีมากในนี้โพสต์

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

ขึ้นอยู่กับว่ามีการใช้เครื่องมือ / เฟรมเวิร์กอะไรบ้าง ด้วยการพึ่งพาเครื่องมือ injection / ioc เรามักจะยังคงได้รับประสิทธิภาพ / การเพิ่มประสิทธิภาพแบบซิงเกิลตันโดยการให้คอนเทนเนอร์ di / ioc ใช้พฤติกรรมเดี่ยวสำหรับคลาสที่ต้องการ - (เช่นอินเทอร์เฟซ IConfigSettings) โดยสร้างเพียงอินสแตนซ์เดียวของคลาส สิ่งนี้ยังสามารถทดแทนการทดสอบได้

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

ตรวจสอบความเป็นไปได้ในการกำหนดค่าเป็นอินเทอร์เฟซการโทรกลับ ดังนั้นรหัสที่ละเอียดอ่อนในการกำหนดค่าของคุณจะมีลักษณะ:

MyReuseCode.Configure(IConfiguration)

รหัสเริ่มต้นระบบจะมีลักษณะ:

Library.init(MyIConfigurationImpl)

คุณสามารถใช้กรอบการพึ่งพาการฉีดเพื่อบรรเทาความเจ็บปวดในการส่งผ่านวัตถุการกำหนดค่า สิ่งที่ดีคือNinjectซึ่งมีข้อได้เปรียบของการใช้โค้ดมากกว่า xml

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

public static Singleton getInstance() {
    if(singleton != null)
        createSingleton();
        return singleton;
    }
}

คุณสามารถโทรcreateSingleton(Information info)ได้โดยตรงเมื่อเริ่มต้นแอปพลิเคชัน (และใน setUp-Methods ของการทดสอบหน่วย)

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

DI ที่ใช้ Spring เป็นต้นเป็นตัวเลือกที่ดีมาก แต่ไม่ใช่ตัวเลือกเดียว