ซิงเกิล: ควรใช้อย่างไร

แก้ไข: จากคำถามอื่นฉันให้คำตอบที่มีลิงก์ไปยังคำถาม / คำตอบมากมายเกี่ยวกับซิงเกิล: ข้อมูลเพิ่มเติมเกี่ยวกับซิงเกิลที่นี่:

ดังนั้นฉันได้อ่านหัวข้อSingletons: การออกแบบที่ดีหรือไม้ยันรักแร้?
และการโต้เถียงยังคงโกรธ

ฉันเห็นว่า Singletons เป็นรูปแบบการออกแบบ (ดีและไม่ดี)

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

ดังนั้นคำถามหลักที่ต้องตอบคือ:

• เมื่อใดที่คุณควรใช้ซิงเกิลตัน
• คุณใช้งานซิงเกิลตันได้อย่างไร

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

เพื่อให้ลูกบอลกลิ้ง:
ฉันจะจับมือและพูดว่านี่คือสิ่งที่ฉันใช้ แต่อาจมีปัญหา
ฉันชอบ "Scott Myers" ในการจัดการเรื่องในหนังสือของเขา "Effective C ++"

สถานการณ์ที่ดีสำหรับการใช้ซิงเกิลตัน (ไม่มาก):

• กรอบการบันทึก
• เธรดพูลการรีไซเคิล

/*
 * C++ Singleton
 * Limitation: Single Threaded Design
 * See: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
 *      For problems associated with locking in multi threaded applications
 *
 * Limitation:
 * If you use this Singleton (A) within a destructor of another Singleton (B)
 * This Singleton (A) must be fully constructed before the constructor of (B)
 * is called.
 */
class MySingleton
{
    private:
        // Private Constructor
        MySingleton();
        // Stop the compiler generating methods of copy the object
        MySingleton(MySingleton const& copy);            // Not Implemented
        MySingleton& operator=(MySingleton const& copy); // Not Implemented

    public:
        static MySingleton& getInstance()
        {
            // The only instance
            // Guaranteed to be lazy initialized
            // Guaranteed that it will be destroyed correctly
            static MySingleton instance;
            return instance;
        }
};

ตกลง. ให้ได้คำวิจารณ์และการใช้งานอื่น ๆ ด้วยกัน
:-)

พวกคุณทุกคนผิด อ่านคำถาม ตอบ:

ใช้ Singleton ถ้า:

• คุณต้องมีวัตถุประเภทเดียวในระบบ

อย่าใช้ซิงเกิลตันหาก:

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

วิธีการสร้างซิงเกิลตันที่ดีที่สุด:

• ยิ่งเล็กยิ่งดี ฉันเป็นมินิมอล
• ตรวจสอบให้แน่ใจว่าเป็นเธรดที่ปลอดภัย
• ตรวจสอบให้แน่ใจว่ามันจะไม่เป็นโมฆะ
• ตรวจสอบให้แน่ใจว่ามันถูกสร้างขึ้นเพียงครั้งเดียว
• ขี้เกียจหรือการเริ่มต้นระบบ? ตามความต้องการของคุณ
• บางครั้งระบบปฏิบัติการหรือ JVM สร้างซิงเกิลตันให้คุณ (เช่นใน Java ทุกคำจำกัดความของคลาสเป็นซิงเกิล)
• จัดให้มี destructor หรือหาวิธีกำจัดทรัพยากร
• ใช้หน่วยความจำน้อย

ซิงเกิลให้ความสามารถในการรวมสองคุณลักษณะที่ไม่ดีในชั้นหนึ่ง มันผิดทุกอย่างเลย

ซิงเกิลให้คุณ:

1. การเข้าถึงวัตถุและ
2. การรับประกันว่าไม่สามารถสร้างวัตถุประเภทนี้ได้มากกว่าหนึ่งรายการ

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

หมายเลขสองอาจฟังดูสมเหตุสมผล แต่ลองคิดดู ครั้งสุดท้ายที่คุณ ** ตั้งใจสร้างวัตถุใหม่แทนที่จะอ้างอิงวัตถุที่มีอยู่เมื่อใด เนื่องจากนี่คือการติดแท็ก C ++ ลองใช้ตัวอย่างจากภาษานั้น คุณมักจะเขียนโดยไม่ตั้งใจ

std::ostream os;
os << "hello world\n";

เมื่อคุณตั้งใจจะเขียน

std::cout << "hello world\n";

ไม่แน่นอน เราไม่ต้องการการป้องกันข้อผิดพลาดนี้เนื่องจากข้อผิดพลาดประเภทนั้นจะไม่เกิดขึ้น ถ้าเป็นเช่นนั้นคำตอบที่ถูกต้องคือกลับบ้านและนอนหลับเป็นเวลา 12-20 ชั่วโมงและหวังว่าคุณจะรู้สึกดีขึ้น

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

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

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

std::coutหากคุณต้องการเข้าถึงทั่วโลกไปยังวัตถุที่ทำให้มันเป็นโลกเช่น แต่อย่า จำกัด จำนวนอินสแตนซ์ที่สามารถสร้างได้

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

หากคุณต้องการทั้งสองลักษณะจากนั้น 1) กำหนดให้เป็นซิงเกิลและ 2) แจ้งให้เราทราบว่าคุณต้องการอะไรเพราะฉันมีปัญหาในการจินตนาการกรณีดังกล่าว

ปัญหาของซิงเกิลตันไม่ได้ถูกนำไปใช้ มันคือการที่พวกเขาทำให้เกิดความคิดที่แตกต่างกันสองแนวคิด

1) Singletons จัดเตรียมกลไกการเข้าถึงทั่วโลกให้กับวัตถุ แม้ว่าพวกมันอาจจะเป็นเธรดที่ปลอดภัยกว่าเล็กน้อยหรือน่าเชื่อถือมากกว่าเล็กน้อยในภาษาที่ไม่มีลำดับการกำหนดค่าเริ่มต้นที่ดีการใช้งานนี้ยังคงเทียบเท่ากับคุณธรรมของตัวแปรทั่วโลก มันเป็นตัวแปรระดับโลกที่แต่งขึ้นในรูปแบบที่น่าอึดอัดใจบางอย่าง (foo :: get_instance () แทนที่จะเป็น g_foo พูด) แต่มันให้บริการจุดประสงค์เดียวกันที่แน่นอน

2) ซิงเกิลตันป้องกันหลายอินสแตนซ์ของคลาส มันหายาก, IME, ว่าฟีเจอร์ประเภทนี้ควรถูกอบเข้าชั้นเรียน ปกติแล้วมันจะเป็นบริบทมากกว่า หลายสิ่งหลายอย่างที่ถือเป็นหนึ่งเดียวเท่านั้นจริงๆเกิดขึ้นเป็นเพียงคนเดียว IMO โซลูชันที่เหมาะสมกว่านั้นคือเพียงสร้างเพียงหนึ่งอินสแตนซ์จนกว่าคุณจะรู้ว่าคุณต้องการมากกว่าหนึ่งอินสแตนซ์

สิ่งหนึ่งที่มีรูปแบบ: ไม่ได้คุย พวกเขามีทุกกรณีเมื่อพวกเขามีประโยชน์และเมื่อพวกเขาล้มเหลว

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

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

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

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

Java โดยเฉพาะใช้ singletons แทนตัวแปรทั่วโลกเนื่องจากทุกอย่างจะต้องอยู่ในชั้นเรียน ตัวแปรที่ใกล้เคียงที่สุดกับตัวแปรโกลบอลคือตัวแปรสแตติกสาธารณะซึ่งอาจใช้ราวกับว่ามันเป็นโกลบอลimport static

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

ภาษาเช่น Python และ Ruby ใช้ singletons น้อยมากเพราะคุณสามารถใช้ตัวแปรโกลบอลภายในโมดูลแทน

ดังนั้นเมื่อไรดี / ไม่ดีในการใช้ซิงเกิล? ค่อนข้างดีเมื่อมันจะดี / ไม่ดีที่จะใช้ตัวแปรทั่วโลก

การออกแบบ C ++ ที่ทันสมัยโดย Alexandrescu มีซิงเกิล - เธรดทั่วไปที่ปลอดภัยและสืบทอดได้

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

• คุณใช้งานซิงเกิลตันได้อย่างไร

มีปัญหาหนึ่งที่ฉันไม่เคยเห็นมาก่อนมีอะไรบางอย่างที่ฉันพบเจอในงานก่อนหน้านี้ เรามี C ++ singletons ที่ใช้ร่วมกันระหว่าง DLL และกลไกปกติของการสร้างความมั่นใจว่าอินสแตนซ์เดียวของคลาสไม่ทำงาน ปัญหาคือว่าแต่ละ DLL ได้รับชุดตัวแปรคงที่ของตัวเองพร้อมกับ EXE หากฟังก์ชัน get_instance ของคุณเป็นแบบอินไลน์หรือเป็นส่วนหนึ่งของห้องสมุดแบบคงที่ DLL แต่ละอันจะปิดท้ายด้วยสำเนา "singleton" ของตัวเอง

วิธีแก้ไขคือตรวจสอบให้แน่ใจว่ามีการกำหนดรหัสซิงเกิลตันใน DLL หรือ EXE เดียวเท่านั้นหรือสร้างตัวจัดการแบบซิงเกิลที่มีคุณสมบัติเหล่านั้นเพื่อแยกอินสแตนซ์ออก

ตัวอย่างแรกไม่ได้เป็นเธรดที่ปลอดภัย - ถ้าสองเธรดเรียกใช้ getInstance ในเวลาเดียวกันสแตติกนั้นจะเป็น PITA Mutex บางรูปแบบจะช่วยได้

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

แง่มุมที่มีประโยชน์ของ singletons:

1. ขี้เกียจหรือการเริ่มต้นล่วงหน้า
2. มีประโยชน์สำหรับวัตถุที่ต้องมีการตั้งค่าและ / หรือสถานะ

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

ในที่สุดโรงงานก็ปล่อยให้เทคโนโลยีการฉีดพึ่งพาเช่นสปริงเป็นต้น

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

หากคุณทำสิ่งนี้ทุกครั้งประสิทธิภาพจะลดลงมาก เมื่อใช้ในซิงเกิลคุณจะต้องกดปุ่มนั้นหนึ่งครั้งจากนั้นการโทรที่ตามมาทั้งหมดไม่จำเป็น

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

ดังนั้นแม้แต่ตัวอย่างของตัวบันทึกหรือเธรดพูลนั้นไม่ถูกต้องและควรถูกแทนที่ด้วยกลยุทธ์

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

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

แต่เมื่อฉันต้องการอะไรแบบซิงเกิลฉันมักจะจบด้วยการใช้Schwarz Counterเพื่อยกตัวอย่าง

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

#include<iostream>
#include<mutex>

using namespace std;
std::mutex mtx;

class MySingleton{
private:
    static MySingleton * singletonInstance;
    MySingleton();
    ~MySingleton();
public:
    static MySingleton* GetInstance();
    MySingleton(const MySingleton&) = delete;
    const MySingleton& operator=(const MySingleton&) = delete;
    MySingleton(MySingleton&& other) noexcept = delete;
    MySingleton& operator=(MySingleton&& other) noexcept = delete;
};

MySingleton* MySingleton::singletonInstance = nullptr;
MySingleton::MySingleton(){ };
MySingleton::~MySingleton(){
    delete singletonInstance;
};

MySingleton* MySingleton::GetInstance(){
    if (singletonInstance == NULL){
        std::lock_guard<std::mutex> lock(mtx);
        if (singletonInstance == NULL)
            singletonInstance = new MySingleton();
    }
    return singletonInstance;
}

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

ฉันใช้ซิงเกิลตันเป็นแบบทดสอบการสัมภาษณ์

เมื่อฉันขอให้ผู้พัฒนาตั้งชื่อรูปแบบการออกแบบบางอย่างหากพวกเขาสามารถตั้งชื่อได้ว่าเป็นซิงเกิลพวกเขาจะไม่ได้รับการว่าจ้าง

ต่อต้านการใช้งาน:

ปัญหาสำคัญอย่างหนึ่งที่มีการใช้งานซิงเกิลมากเกินไปคือรูปแบบนั้นป้องกันการขยายและสลับการใช้งานอื่น ชื่อคลาสนั้นใช้รหัสอย่างหนักในทุกที่ที่ใช้ซิงเกิล

ฉันคิดว่านี่เป็นรุ่นที่แข็งแกร่งที่สุดสำหรับ C #:

using System;
using System.Collections;
using System.Threading;

namespace DoFactory.GangOfFour.Singleton.RealWorld
{

  // MainApp test application

  class MainApp
  {
    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Same instance?
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 server requests
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // "Singleton"

  class LoadBalancer
  {
    private static LoadBalancer instance;
    private ArrayList servers = new ArrayList();

    private Random random = new Random();

    // Lock synchronization object
    private static object syncLock = new object();

    // Constructor (protected)
    protected LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      // Support multithreaded applications through
      // 'Double checked locking' pattern which (once
      // the instance exists) avoids locking each
      // time the method is invoked
      if (instance == null)
      {
        lock (syncLock)
        {
          if (instance == null)
          {
            instance = new LoadBalancer();
          }
        }
      }

      return instance;
    }

    // Simple, but effective random load balancer

    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

นี่คือ. NET เวอร์ชั่นที่ดีที่สุด :

using System;
using System.Collections;

namespace DoFactory.GangOfFour.Singleton.NETOptimized
{

  // MainApp test application

  class MainApp
  {

    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Confirm these are the same instance
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 requests for a server
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // Singleton

  sealed class LoadBalancer
  {
    // Static members are lazily initialized.
    // .NET guarantees thread safety for static initialization
    private static readonly LoadBalancer instance =
      new LoadBalancer();

    private ArrayList servers = new ArrayList();
    private Random random = new Random();

    // Note: constructor is private.
    private LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      return instance;
    }

    // Simple, but effective load balancer
    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

คุณสามารถหารูปแบบนี้ที่dotfactory.com

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

ซิงเกิลตันเป็นการใช้งานสำหรับออบเจ็กต์ที่สามารถเข้าถึงได้ทั่วโลก (GAO นับจากนี้เป็นต้นไป) แม้ว่า GAO ทั้งหมดจะไม่ใช่ซิงเกิลตัน

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

การประเมิน Lazy-loading / lazy เป็นแนวคิดที่แตกต่างและซิงเกิลตันก็มักจะนำไปใช้เช่นกัน มันมาพร้อมกับปัญหาของตัวเองมากมายโดยเฉพาะอย่างยิ่งเธรดความปลอดภัยและปัญหาถ้ามันล้มเหลวโดยมีข้อยกเว้นเช่นว่าสิ่งที่ดูเหมือนความคิดที่ดีในเวลานั้นกลับกลายเป็นว่าไม่ดีนัก (บิตเช่นการใช้งาน COW ในสตริง)

โดยที่ในใจ GOAs สามารถเริ่มต้นได้เช่นนี้:

namespace {

T1 * pt1 = NULL;
T2 * pt2 = NULL;
T3 * pt3 = NULL;
T4 * pt4 = NULL;

}

int main( int argc, char* argv[])
{
   T1 t1(args1);
   T2 t2(args2);
   T3 t3(args3);
   T4 t4(args4);

   pt1 = &t1;
   pt2 = &t2;
   pt3 = &t3;
   pt4 = &t4;

   dostuff();

}

T1& getT1()
{
   return *pt1;
}

T2& getT2()
{
   return *pt2;
}

T3& getT3()
{
  return *pt3;
}

T4& getT4()
{
  return *pt4;
}

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

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

ฉันยังไม่เข้าใจว่าทำไมจึงต้องเป็นซิงเกิลในระดับโลก

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

ฉันไม่เห็นว่าทำไมฟังก์ชั่นนี้จึงไม่ดี

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

ฉันแน่ใจว่ามีวิธีแก้ไขปัญหาอื่น ๆ แต่ฉันพบว่ามีประโยชน์และง่ายต่อการใช้งาน

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

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

ในแอพเดสก์ท็อป (ฉันรู้ว่ามี แต่ไดโนเสาร์ของเราเท่านั้นที่เขียนสิ่งเหล่านี้อีกต่อไป!) พวกมันจำเป็นสำหรับการตั้งค่าแอพพลิเคชั่นระดับโลกที่ไม่เปลี่ยนแปลง - ภาษาผู้ใช้เส้นทางที่จะช่วยเหลือไฟล์ .

แก้ไข - แน่นอนว่าสิ่งเหล่านี้ควรเป็นแบบอ่านอย่างเดียว!

การดำเนินการอื่น

class Singleton
{
public:
    static Singleton& Instance()
    {
        // lazy initialize
        if (instance_ == NULL) instance_ = new Singleton();

        return *instance_;
    }

private:
    Singleton() {};

    static Singleton *instance_;
};