คำถามติดแท็ก singleton


11
จะเรียกว่า "ความกังวลข้ามตัด" เป็นข้อแก้ตัวที่ถูกต้องในการทำลาย SOLID / DI / IoC?
เพื่อนร่วมงานของฉันชอบพูดว่า "การบันทึก / การแคช / ฯลฯ เป็นข้อกังวลข้าม" จากนั้นดำเนินการใช้ซิงเกิลที่เกี่ยวข้องทุกที่ พวกเขารัก IoC และ DI มันเป็นข้อแก้ตัวที่ถูกต้องหรือไม่ที่จะทำลายหลักการของ SOLI D ?

9
ทางเลือกในรูปแบบซิงเกิล
ฉันได้อ่านความคิดเห็นที่แตกต่างกันเกี่ยวกับรูปแบบซิงเกิล บางคนยืนยันว่าควรหลีกเลี่ยงค่าใช้จ่ายและอื่น ๆ ที่สามารถเป็นประโยชน์ในบางสถานการณ์ สถานการณ์หนึ่งที่ฉันใช้ singletons คือเมื่อฉันต้องการโรงงาน (สมมติว่าวัตถุประเภท f) เพื่อสร้างวัตถุของคลาส A แน่นอนโรงงานถูกสร้างขึ้นครั้งเดียวโดยใช้พารามิเตอร์การกำหนดค่าบางอย่างจากนั้นจะใช้แต่ละครั้งที่วัตถุของ พิมพ์ A ถูกสร้างขึ้น ดังนั้นทุกส่วนของรหัสที่ต้องการอินสแตนซ์ A ดึงค่าซิงเกิลตันและสร้างอินสแตนซ์ใหม่เช่น F& f = F::instance(); boost::shared_ptr<A> a = f.createA(); ดังนั้นสถานการณ์ทั่วไปของฉันก็คือ ฉันต้องการอินสแตนซ์เดียวของคลาสอย่างใดอย่างหนึ่งด้วยเหตุผลการปรับให้เหมาะสม (ฉันไม่ต้องการวัตถุหลายโรงงาน) หรือสำหรับการแบ่งปันสถานะทั่วไป (เช่นโรงงานทราบจำนวนอินสแตนซ์ของ A ที่ยังคงสามารถสร้างได้) ฉันต้องการวิธีการเข้าถึง f ของอินสแตนซ์นี้ในสถานที่ต่าง ๆ ของรหัส ฉันไม่สนใจในการอภิปรายว่ารูปแบบนี้ดีหรือไม่ดี แต่สมมติว่าฉันต้องการหลีกเลี่ยงการใช้ซิงเกิลตันฉันสามารถใช้รูปแบบอื่นแบบใดได้บ้าง แนวคิดที่ฉันมีคือ (1) นำวัตถุของโรงงานออกจากรีจิสตรีหรือ (2) เพื่อสร้างโรงงานในบางช่วงระหว่างการเริ่มต้นโปรแกรมแล้วส่งโรงงานเป็นพารามิเตอร์ ในโซลูชัน (1) ตัวรีจิสตรีนั้นเป็นซิงเกิลดังนั้นฉันเพิ่งเปลี่ยนปัญหาการไม่ใช้ซิงเกิลตันจากโรงงานไปยังรีจิสตรี ในกรณี (2) …

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 เป็นถั่วที่ไม่มีส่วนต่อประสาน ข้อโต้แย้งที่ฉันได้รับจากการคงที่คือ: …

4
ฉีดพึ่งพาและ Singleton พวกเขาทั้งสองแนวคิดที่แตกต่างกันอย่างสิ้นเชิง?
ฉันเคยได้ยินเกี่ยวกับการใช้การฉีดขึ้นเหนือ Singleton สำหรับเพื่อนร่วมงานของฉัน ฉันยังไม่สามารถบอกได้ว่ามันเป็นสองรูปแบบมุมฉากซึ่งสามารถแทนที่ด้วยอีกรูปแบบหนึ่งได้หรือไม่? หรือ DI เป็นวิธีที่ทำให้รูปแบบซิงเกิลทดสอบได้หรือไม่? โปรดดูข้อมูลโค้ดต่อไปนี้ IMathFace obj = Singleton.Instance; SingletonConsumer singConsumer = new SingletonConsumer(obj); singConsumer.ConsumerAdd(10,20); ยอมรับพารามิเตอร์ของชนิดSingletonConsumer IMathFaceแทนที่จะเข้าถึงคลาส singleton ภายในSingletonConsumerจะได้รับอินสแตนซ์ singleton ที่ส่งโดยผู้เรียก นี่เป็นตัวอย่างที่ดีของการบริโภคคลาสซิงเกิลผ่านการฉีดแบบพึ่งพาหรือไม่

3
ข้อเสียของการนำ singleton ไปใช้กับ enum ของ Java คืออะไร
ตามเนื้อผ้ามักจะใช้เป็นซิงเกิล public class Foo1 { private static final Foo1 INSTANCE = new Foo1(); public static Foo1 getInstance(){ return INSTANCE; } private Foo1(){} public void doo(){ ... } } ด้วย enum ของ Java เราสามารถใช้ singleton เป็น public enum Foo2 { INSTANCE; public void doo(){ ... } } น่ากลัวเหมือนรุ่นที่ 2 คือมีข้อเสียหรือไม่ (ฉันให้ความคิดกับฉันและฉันจะตอบคำถามของฉันเองหวังว่าคุณจะได้คำตอบที่ดีกว่า)
14 java  singleton  enum 

3
DAO ควรเป็นแบบเดี่ยวหรือไม่?
ฉันกำลังพัฒนา RESTful API และฉันคิดว่ามันสะดวกที่จะใช้ DAO สำหรับทรัพยากรของฉันเพราะแม้ว่าฉันจะใช้หน่วยความจำเพื่อเก็บไว้ แต่ฉันไม่ต้องการปิดประตูให้ใครก็ตามที่ใช้ห้องสมุดของฉันถ้าพวกเขาตัดสินใจที่จะใช้ การใช้ฐานข้อมูลสำหรับ DAO คำถามของฉันคือว่า DAO ควรเป็นซิงเกิลตันหรือไม่ หากไม่ใช่บริการจะมีตัวอย่างของ DAO และจะมีลักษณะเช่นนี้: @Path("eventscheduler") public class EventSchedulerService { private IEventSchedulerDao dao = new EventSchedulerDao(); // in case a different implementation is to be used public void setEventSchedulerDao(IEventSchedulerDao dao) { this.dao = dao; } @Path("{uniqueName}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament …

7
อะไรคือบทบาทของซิงเกิลตันคลาสนามธรรมและอินเตอร์เฟส
ฉันกำลังศึกษา OOP ใน C ++ และแม้ว่าฉันตระหนักถึงคำจำกัดความของแนวคิดทั้งสามนี้ฉันก็ไม่สามารถรู้ได้เลยว่าจะใช้เมื่อไหร่หรืออย่างไร ลองใช้คลาสนี้เป็นตัวอย่าง: class Person{ private: string name; int age; public: Person(string p1, int p2){this->name=p1; this->age=p2;} ~Person(){} void set_name (string parameter){this->name=parameter;} void set_age (int parameter){this->age=parameter;} string get_name (){return this->name;} int get_age (){return this->age;} }; 1. ซิงเกิล วิธีไม่ข้อ จำกัด ของการเรียนที่จะมีเพียงหนึ่งในการทำงานของวัตถุ? คุณสามารถออกแบบคลาสที่มีเพียง 2 อินสแตนซ์ได้หรือไม่ หรืออาจจะ 3? เมื่อใดที่แนะนำ / …

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

4
รูปแบบ“ ศูนย์การแจ้งเตือน” ส่งเสริมการออกแบบโปรแกรมที่ดีหรือไม่ดีหรือไม่?
บางครั้งฉันเจอ API สไตล์ฮับข้อความเช่น Cocoa NSNotificationCenter: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html โดยปกติแล้ว API เหล่านี้จะให้จุดเชื่อมต่อส่วนกลางที่คุณสมัครหรือเผยแพร่ข้อความ / กิจกรรม ฉันคิดว่านี่เป็นปัญหาเพราะมันสนับสนุนสถาปัตยกรรมโปรแกรมแบบแบนและไม่มีโครงสร้างซึ่งการพึ่งพาไม่ชัดเจนใน API แต่ซ่อนอยู่ในซอร์สโค้ด คุณไม่ได้ถูกบังคับให้คิดเกี่ยวกับการเป็นเจ้าของวัตถุและลำดับชั้น แต่สามารถทำให้วัตถุใด ๆ ในโปรแกรมของคุณส่งผลให้มีรหัสใด ๆ ที่ถูกเรียก แต่นี่อาจเป็นสิ่งที่ดี? โดยทั่วไปแล้วรูปแบบนี้ส่งเสริมการออกแบบโปรแกรมที่ดีหรือไม่ดีและทำไมถึงเป็นเช่นนั้น มันทำให้รหัสยากขึ้นหรือง่ายขึ้นในการทดสอบ? ยกโทษให้ฉันถ้าคำถามนี้คลุมเครือหรือกว้างเกินไป ฉันพยายามคาดไม่ถึงผลที่ตามมาจากการใช้ API อย่างกว้างขวางและวิธีต่างๆที่คุณสามารถใช้ได้ แก้ไข: ฉันเดาว่าปัญหาที่ใหญ่ที่สุดของฉันในรูปแบบนี้คือ API "โกหก" เกี่ยวกับการพึ่งพาและข้อต่อวัตถุและสามารถแสดงด้วยตัวอย่างนี้: myObj = new Foo(); myOtherObj = new Bar(); print myOtherObj.someValue; // prints 0 myObj.doSomething(); print myOtherObj.someValue; // prints …

4
ซิงเกิลตันที่ไม่เปลี่ยนรูป / ไร้สัญชาตินั้นแย่หรือไม่?
เมื่อเร็ว ๆ นี้มีการปฏิวัติต่อต้านซิงเกิลบ้าง แต่มีอะไรผิดปกติกับพวกเขาไหมถ้าพวกเขาไร้สัญชาติ? ฉันรู้ว่าการพูดคุยที่มากเกินไปและทั้งหมด ... สิ่งนี้ใช้ได้กับทุกสิ่งที่ไม่ใช่แค่ซิงเกิลตัน

2
จะหลีกเลี่ยงอินเทอร์เฟซที่บ้าคลั่งใน UI ด้วยการฉีดแบบพึ่งพาได้อย่างไร
ปัญหา ฉันเพิ่งอ่านมากเกี่ยวกับ Singletons ไม่ดีและวิธีการฉีดพึ่งพา (ซึ่งฉันเข้าใจว่าเป็น "ใช้อินเตอร์เฟส") ดีกว่า เมื่อฉันใช้ส่วนนี้กับ callbacks / interfaces / DI และปฏิบัติตามหลักการแยกส่วนติดต่อฉันสิ้นสุดค่อนข้างยุ่งเหยิง การพึ่งพาของพาเรนต์ UI ที่โดยทั่วไปแล้วพวกเด็ก ๆ ทั้งหมดรวมกันดังนั้นยิ่งลำดับชั้นขององค์ประกอบ UI มากขึ้นเท่าใดคอนสตรัคเตอร์ก็ยิ่งบวมมากขึ้นเท่านั้น ทางด้านบนของลำดับชั้น UI นั้นเป็นคลาสแอปพลิเคชันเก็บข้อมูลเกี่ยวกับการเลือกปัจจุบันและการอ้างอิงถึงโมเดล 3 มิติที่ต้องการสะท้อนการเปลี่ยนแปลง แอปพลิเคชั่นคลาสใช้งานอินเทอร์เฟซ 8 ตัวและนี่เป็นเพียงหนึ่งในห้าของผลิตภัณฑ์ (/ อินเตอร์เฟส) ที่จะเกิดขึ้น! ฉันทำงานกับ singleton ที่ถือการเลือกปัจจุบันและองค์ประกอบ UI ที่มีฟังก์ชั่นเพื่อปรับปรุงตัวเอง ฟังก์ชั่นนี้จะแยกส่วนทรี UI และองค์ประกอบ UI จากนั้นเข้าถึงซิงเกิลที่เลือกปัจจุบันตามต้องการ รหัสดูเหมือนจะสะอาดกว่าสำหรับฉันด้วยวิธีนี้ คำถาม โครงการนี้น่าจะเหมาะสำหรับโครงการนี้หรือไม่ ถ้าไม่มีข้อบกพร่องพื้นฐานในการคิดและ / หรือการนำ DI มาใช้ซึ่งทำให้ยุ่งยาก …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.