อะไรคือสิ่งที่ไม่ดีเกี่ยวกับซิงเกิลตัน? [ปิด]

รูปแบบเดี่ยวเป็นสมาชิกชำระเต็มของGoF 's หนังสือรูปแบบแต่มันดูเหมือนว่าเมื่อเร็ว ๆ นี้ค่อนข้างกำพร้าโลกนักพัฒนา ฉันยังคงใช้ singletons ค่อนข้างมากโดยเฉพาะอย่างยิ่งสำหรับคลาสโรงงานและในขณะที่คุณต้องระวังเล็กน้อยเกี่ยวกับปัญหามัลติเธรด

Stack Overflow โดยเฉพาะดูเหมือนว่าจะถือว่าทุกคนยอมรับว่าซิงเกิลตันนั้นชั่วร้าย ทำไม?

โปรดสนับสนุนคำตอบของคุณด้วย " ข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญเฉพาะด้าน "

ถอดความจากปุ่ม Brian:

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

2. พวกเขาละเมิดหลักการความรับผิดชอบเดียว : โดยอาศัยอำนาจตามความจริงที่ว่าพวกเขาควบคุมการสร้างและวงจรชีวิตของตัวเอง

3. พวกเขาโดยเนื้อแท้ทำให้เกิดรหัสที่จะแน่นคู่ สิ่งนี้ทำให้การแกล้งพวกเขาออกไปทดสอบค่อนข้างยากในหลายกรณี

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

Singletons แก้ปัญหาหนึ่ง (และเพียงหนึ่ง)

การช่วงชิงทรัพยากร

หากคุณมีทรัพยากรบางอย่างที่

( 1 ) มีได้เพียงครั้งเดียวเท่านั้นและ

( 2 ) คุณต้องจัดการอินสแตนซ์เดียวนั้น

คุณจำเป็นต้องมีเดี่ยว

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

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

เมื่อคุณคิดว่าคุณต้องการโลกคุณอาจจะทำผิดพลาดอย่างมากในการออกแบบ

Snobs ที่เข้ารหัสบางคนมองดูพวกเขาในฐานะที่เป็นเพียงผู้มีชื่อเสียงระดับโลก ในลักษณะเดียวกับที่หลาย ๆ คนเกลียดข้ามคำสั่งมีคนอื่น ๆ ที่เกลียดชังความคิดของที่เคยใช้ที่ทั่วโลก ฉันได้เห็นนักพัฒนาหลายคนไปที่ความยาวพิเศษเพื่อหลีกเลี่ยงระดับโลกเพราะพวกเขาพิจารณาใช้เป็นข้อผิดพลาด แปลก แต่จริง

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

Misko Hevery จาก Google มีบทความที่น่าสนใจในหัวข้อนี้ ...

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

Singletons ไม่มีอะไรมากไปกว่ารัฐโลก สถานะโกลบอลสร้างขึ้นเพื่อให้วัตถุของคุณสามารถซ่อนสิ่งที่ไม่ได้ประกาศไว้ใน API ของพวกเขาและเป็นผลให้ Singletons ทำให้ API ของคุณกลายเป็นคนโกหกทางพยาธิวิทยา

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

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

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

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

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

ดังนั้นโดยทั่วไป:

public MyConstructor(Singleton singleton) {
    this.singleton = singleton;
}

ค่อนข้างมากกว่า:

public MyConstructor() {
    this.singleton = Singleton.getInstance();
}

ฉันเชื่อว่ารูปแบบนี้เรียกว่าการฉีดแบบพึ่งพาและโดยทั่วไปถือว่าดี

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

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

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

ในสภาพแวดล้อมที่เก็บขยะ singletons สามารถกลายเป็นปัญหาเกี่ยวกับการจัดการหน่วยความจำได้อย่างรวดเร็ว

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

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

Singletons นอกจากนี้ยังมีที่ไม่ดีเมื่อมันมาถึงการจัดกลุ่ม เพราะตอนนี้คุณไม่มี "ใบเดียวอย่างเดียว" ในใบสมัครของคุณอีกต่อไป

พิจารณาสถานการณ์ต่อไปนี้: ในฐานะนักพัฒนาคุณต้องสร้างเว็บแอปพลิเคชันที่เข้าถึงฐานข้อมูล เพื่อให้แน่ใจว่าการเรียกฐานข้อมูลพร้อมกันไม่ขัดแย้งกันคุณสร้าง thread-save SingletonDao:

public class SingletonDao {
    // songleton's static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

SingletonDaoดังนั้นคุณจะแน่ใจว่ามีเพียงหนึ่งเดี่ยวในใบสมัครของคุณอยู่และฐานข้อมูลทั้งหมดไปผ่านคนนี้และมีเพียง สภาพแวดล้อมการผลิตของคุณตอนนี้มีลักษณะดังนี้:

ทุกอย่างเรียบร้อยดี

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

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

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

1. มันใช้งานง่าย (ab) เป็นตัวแปรทั่วโลก
2. คลาสที่ขึ้นอยู่กับ singletons นั้นค่อนข้างยากในการทดสอบแบบแยกหน่วย

การผูกขาดเป็นปีศาจและซิงเกิลที่มีสถานะที่ไม่สามารถอ่านได้ / ไม่แน่นอนเป็นปัญหาที่เกิดขึ้นจริง ...

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

โลกไม่ดีเพราะ:

• มันทำให้เกิดความขัดแย้ง namespace
• ข มันเผยให้เห็นรัฐในแบบที่ไม่รับประกัน

เมื่อพูดถึง Singletons

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

ในคำสั่งสุดท้ายเขาอ้างถึงแนวคิดของบล็อกของ 'ซิงเกิลตันเป็นคนโกหก'

สิ่งนี้นำไปใช้กับการผูกขาดได้อย่างไร

ในการเริ่มเกมผูกขาด:

• เราสร้างกฎก่อนเพื่อให้ทุกคนอยู่ในหน้าเดียวกัน
• ทุกคนได้รับการเริ่มต้นที่เท่าเทียมกันตั้งแต่เริ่มเกม
• มีการนำเสนอกฎชุดเดียวเท่านั้นเพื่อหลีกเลี่ยงความสับสน
• กฎไม่ได้รับอนุญาตให้เปลี่ยนตลอดทั้งเกม

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

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

ตอนนี้เกมเริ่มต้นจากการทอยลูกเต๋าอย่างเป็นมิตรกับธุรกิจที่จริงจัง บ๊อบเป็นตัวอย่างของความล้มเหลวและโจและเอ็ดไม่ต้องการที่จะจบลงเช่น 'ผู้ชายคนนั้น' ดังนั้นการเป็นผู้เล่นชั้นนำของคุณในทันทีกลายเป็นศัตรู Joe และ Ed เริ่มฝึกฝนการเทรดภายใต้โต๊ะหลังการอัดฉีดเงินการแลกเปลี่ยนบ้านโดยไม่คำนึงถึงคุณค่าและโดยทั่วไปทุกอย่างจะทำให้คุณอ่อนแอในฐานะผู้เล่นจนกว่าจะมีผู้เล่นคนใดคนหนึ่งขึ้นไปด้านบน

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

ดังนั้นหากกฎของเกมแสดงถึงซิงเกิลตันอย่างถูกต้องกฎการผูกขาดจะเป็นตัวอย่างของการละเมิด

สิ่งนี้นำไปใช้กับการเขียนโปรแกรมได้อย่างไร

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

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

Singleton เป็นเพียงตัวเลือกหากคุณต้องการสิ่งที่ Singleton มอบให้ อินสแตนซ์อ่านอย่างเดียวแบบเขียนของวัตถุ กฎเดียวกันนั้นควรเรียงซ้อนกับคุณสมบัติ / สมาชิกของวัตถุเช่นกัน

ซิงเกิลไม่ได้เกี่ยวกับอินสแตนซ์เดียว!

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

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

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

อย่างที่ฉันบอกไว้ในหัวข้อซิงเกิลนั้นไม่เกี่ยวกับอินสแตนซ์เดียว

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

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

สกรูใหญ่สองอันที่ฉันเห็นคือการปฏิบัติเหมือนโลกและไม่สามารถกำหนดการปิดแบบซิงเกิลได้

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

บริบทของซิงเกิลก็สำคัญเช่นกัน ลักษณะการกำหนดของ Singleton คือมี "เพียงหนึ่งเดียว" แต่ความจริงก็คือ "เพียงหนึ่งเดียว" ในบริบท / เนมสเปซบางชนิด พวกเขามักจะเป็นหนึ่งใน: หนึ่งต่อเธรดกระบวนการที่อยู่ IP หรือคลัสเตอร์ แต่ยังสามารถเป็นหนึ่งต่อหน่วยประมวลผล, เครื่อง, ภาษา namespace / class loader / อะไรก็ตาม, subnet, อินเทอร์เน็ต, ฯลฯ

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

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

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

ดู Wikipedia Singleton_pattern

มันก็ถือว่าเป็นรูปแบบการต่อต้านโดยบางคนที่รู้สึกว่ามันใช้มากเกินไปแนะนำข้อ จำกัด ที่ไม่จำเป็นในสถานการณ์ที่อินสแตนซ์เดียวของชั้นเรียนไม่จำเป็นจริง ๆ แล้ว [1] [2] [3] [4]

การอ้างอิง (การอ้างอิงที่เกี่ยวข้องเท่านั้นจากบทความ)

1. ^ Alex Miller รูปแบบที่ฉันเกลียด # 1: ซิงเกิลตัน , กรกฎาคม 2550
2. ^ Scott Densmore เหตุใดซิงเกิลจึงชั่วร้ายพฤษภาคม 2004
3. ^ Steve Yegge Singletons ถือว่าโง่กันยายน 2004
4. ^ JB Rainsberger, IBM ใช้ซิงเกิลตันของคุณอย่างฉลาดกรกฎาคม 2544

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

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

1. ตรวจสอบให้แน่ใจว่าคลาสที่จะใช้เป็น singleton ใช้อินเทอร์เฟซ สิ่งนี้อนุญาตให้สตับหรือ mocks ใช้งานได้โดยใช้อินเตอร์เฟสเดียวกัน

2. ตรวจสอบให้แน่ใจว่า Singleton ปลอดภัยต่อเธรด นั่นคือที่ได้รับ

3. ซิงเกิลควรเรียบง่ายในธรรมชาติและไม่ซับซ้อนเกินไป

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

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

เราได้ใช้ Singletons ในการแก้ปัญหาของเราด้วยความสำเร็จอย่างมากที่สามารถทดสอบได้เพื่อให้มั่นใจว่าพฤติกรรมที่กำหนดไว้ในการทดสอบกระแสขนาน

ฉันต้องการพูดถึง 4 คะแนนในคำตอบที่ได้รับการยอมรับหวังว่าบางคนสามารถอธิบายได้ว่าทำไมฉันถึงผิด

1. ทำไมการซ่อนรหัสอ้างอิงของคุณจึงไม่ดี มีการอ้างอิงที่ซ่อนอยู่หลายสิบรายการ (การโทรแบบรันไทม์ C, การโทรแบบ OS API, การเรียกใช้ทั่วโลก) และการอ้างอิงแบบซิงเกิลหาง่าย (ค้นหาตัวอย่าง ())

   "การสร้างบางสิ่งที่ทั่วโลกเพื่อหลีกเลี่ยงการส่งผ่านเป็นกลิ่นรหัส" ทำไมไม่ผ่านบางสิ่งบางอย่างเพื่อหลีกเลี่ยงการทำให้เป็นกลิ่นรหัสเดียว?

   หากคุณกำลังส่งวัตถุผ่าน 10 ฟังก์ชั่นใน call stack เพียงเพื่อหลีกเลี่ยงซิงเกิลตันมันยอดเยี่ยมมากเหรอ?

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

3. เหตุใดการส่งวัตถุไปยังคลาสทำให้คู่นั้นแน่นกว่าการใช้วัตถุนั้นเป็นซิงเกิลจากภายในคลาส?

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

เกี่ยวกับการทดสอบหน่วย:

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

Vince Hustonมีเกณฑ์เหล่านี้ซึ่งดูสมเหตุสมผลสำหรับฉัน:

ควรพิจารณาซิงเกิลตันเฉพาะเมื่อตรงตามเกณฑ์ทั้งสามข้อต่อไปนี้:

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

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

Singletons ไม่ดีจากมุมมองของคนเจ้าระเบียบ

จากจุด pratical ในมุมมองของเดี่ยวคือการปิดการพัฒนาเวลา VS ซับซ้อน

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

Singletons บางครั้งยังซับซ้อนทดสอบหน่วย

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

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

ฉันจะไม่แสดงความคิดเห็นในการโต้แย้งที่ดี / ชั่วร้าย แต่ฉันไม่ได้ใช้พวกเขาตั้งแต่ฤดูใบไม้ผลิมาพร้อม การใช้การฉีดแบบพึ่งพานั้นได้ลบความต้องการของฉันไปแล้วสำหรับ singleton, servicelocators และโรงงาน ฉันพบว่าสภาพแวดล้อมที่มีประสิทธิภาพและสะอาดกว่านี้อย่างน้อยสำหรับประเภทของงานที่ฉันทำ (เว็บแอปพลิเคชันบน Java)

Singleton เป็นรูปแบบและสามารถใช้หรือใช้ในทางที่ผิดเหมือนกับเครื่องมืออื่น ๆ

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

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

Singletons ทำให้มันยากมากที่จะย้ายจากพวกเขาไปยังวัตถุปกติ

นอกจากนี้มันง่ายเกินไปที่จะเขียนซิงเกิลที่ไม่ปลอดภัยต่อเธรด

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

void some_class::some_function(parameters, service_provider& srv)
{
    srv.get<error_logger>().log("Hi there!");
    this->another_function(some_other_parameters, srv);
}

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

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

FWIW ถ้าเป็น PIA เมื่อคุณลองทดสอบหน่วยมันจะไปที่ PIA เมื่อคุณพยายามที่จะทำการดีบักแก้ไขข้อผิดพลาดหรือปรับปรุง

บทความล่าสุดในเรื่องนี้โดยคริส Reath ที่เข้ารหัสโดยไม่มีความคิดเห็น

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

http://geekswithblogs.net/AngelEyes/archive/2013/09/08/singleton-i-love-you-but-youre-bringing-me-down-re-uploaded.aspx

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

อย่างไรก็ตามมี "บริการขอบเขตแอปพลิเคชัน" (คิดเกี่ยวกับระบบการส่งข้อความที่ทำให้องค์ประกอบมีการโต้ตอบ) - CALLS นี้สำหรับซิงเกิลตัน "MessageQueue" - คลาสที่มีเมธอด "SendMessage (... )"

จากนั้นคุณสามารถทำสิ่งต่อไปนี้จากทั่วทุกที่:

MessageQueue.Current.SendMessage (ใหม่ MailArrivedMessage (... ));

และแน่นอนทำ:

MessageQueue.Current.RegisterReceiver (นี้);

ในคลาสที่ใช้ IMessageReceiver

มีคนจำนวนมากใส่วัตถุที่ไม่ปลอดภัยในรูปแบบด้ายเดี่ยว ฉันได้เห็นตัวอย่างของ DataContext ( LINQ to SQL ) ที่ทำในรูปแบบซิงเกิลแม้ว่าข้อเท็จจริงที่ว่า DataContext จะไม่ปลอดภัยและเป็นวัตถุหน่วยของงาน

นี่เป็นอีกเรื่องเกี่ยวกับซิงเกิลตันที่ยังไม่มีใครพูด

ในกรณีส่วนใหญ่ "singletonity" เป็นรายละเอียดของการใช้งานสำหรับบางคลาสมากกว่าลักษณะของอินเทอร์เฟซ การผกผันของคอนโทรลคอนเทนเนอร์อาจซ่อนคุณสมบัตินี้จากผู้ใช้คลาส คุณเพียงแค่ต้องทำเครื่องหมายชั้นเรียนของคุณเป็นซิงเกิลตัน (พร้อม@Singletonคำอธิบายประกอบใน Java) และนั่นคือ; IoCC จะทำส่วนที่เหลือ คุณไม่จำเป็นต้องให้สิทธิ์การเข้าถึงทั่วโลกสำหรับอินสแตนซ์ซิงเกิลของคุณเนื่องจากการเข้าถึงนั้นได้รับการจัดการโดย IoCC แล้ว ดังนั้นจึงไม่มีอะไรผิดปกติกับ IoC Singletons

GoF Singletons ตรงข้ามกับ IoC Singletons ควรจะเปิดเผย "singletonity" ในอินเตอร์เฟสผ่านเมธอด getInstance () และเพื่อให้พวกเขาประสบทุกสิ่งที่กล่าวมาข้างต้น

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

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

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

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

ปัญหาที่เกิดจากการทดสอบแบบซิงเกิลเป็นอาการของกรณีการใช้งาน / สภาพแวดล้อมการใช้งานรหัสเดียวฮาร์ด ชุดการทดสอบและการทดสอบจำนวนมากนั้นแยกจากกันและแยกสิ่งที่ไม่เข้ากันกับการเข้ารหัสแบบซิงเกิล

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