คำถามติดแท็ก design-patterns

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

24 design-patterns  architecture  mvc 

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

24 design-patterns 

Builder Patternตัวอย่างมากมายทำให้Builderคลาสภายในของวัตถุที่สร้างขึ้น ทำให้รู้สึกบางอย่างเพราะมันบ่งบอกถึงสิ่งที่Builderสร้าง อย่างไรก็ตามในภาษาที่พิมพ์แบบคงที่เรารู้ว่าสิ่งที่Builderสร้าง ในทางตรงกันข้ามถ้าBuilderเป็นระดับชั้นที่คุณควรจะรู้ว่าสิ่งที่ชั้นสร้างโดยไม่ได้มองภายในของBuilderBuilder นอกจากนี้การมีตัวสร้างเป็นคลาสภายในจะลดจำนวนของการนำเข้าเนื่องจากสามารถอ้างอิงโดยคลาสภายนอก - หากคุณสนใจสิ่งนั้น แล้วมีตัวอย่างการปฏิบัติที่Builderอยู่ในแพคเกจเดียวกัน StringBuilderแต่ไม่ได้เป็นระดับชั้นเช่น คุณรู้ว่าBuilder ควรสร้างStringเพราะมันมีชื่อดังนั้น ที่ถูกกล่าวว่าเหตุผลที่ดีเท่านั้นที่ฉันสามารถคิดในการสร้างBuilderชั้นในคือคุณรู้ว่าสิ่งที่ชั้น ' Builderคือโดยไม่ทราบชื่อของมันหรืออาศัยการประชุมการตั้งชื่อ ตัวอย่างเช่นถ้าStringBuilderเป็นชั้นในของStringฉันอาจจะรู้ว่ามันมีอยู่เร็วกว่าที่ฉันทำ (เก็งกำไร) มีเหตุผลอื่นที่จะทำให้Builderชั้นในหรือไม่เพียงแค่ลงไปที่การตั้งค่าและพิธีกรรม?

24 java  design-patterns  object-oriented 

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

23 c#  design-patterns  object-oriented  methods 

อุปกรณ์เสริมและตัวดัดแปลง (aka setters and getters) มีประโยชน์ด้วยเหตุผลสามประการ: พวกเขา จำกัด การเข้าถึงตัวแปร ตัวอย่างเช่นตัวแปรสามารถเข้าถึงได้ แต่ไม่สามารถแก้ไขได้ พวกเขาตรวจสอบพารามิเตอร์ พวกเขาอาจทำให้เกิดผลข้างเคียง มหาวิทยาลัยหลักสูตรออนไลน์บทช่วยสอนบทความในบล็อกและตัวอย่างโค้ดบนเว็บล้วนเน้นหนักเกี่ยวกับความสำคัญของผู้เข้าถึงและผู้ดัดแปลงพวกเขาเกือบรู้สึกว่า "ต้องมี" สำหรับรหัสในปัจจุบัน ดังนั้นเราสามารถค้นหาได้แม้ว่าพวกเขาจะไม่ให้ค่าเพิ่มเติมใด ๆ เช่นรหัสด้านล่าง public class Cat { private int age; public int getAge() { return this.age; } public void setAge(int age) { this.age = age; } } ดังที่ได้กล่าวมามันเป็นเรื่องธรรมดามากที่จะหาตัวดัดแปลงที่มีประโยชน์มากกว่าซึ่งตัวตรวจสอบความถูกต้องของพารามิเตอร์และส่งข้อยกเว้นหรือส่งคืนบูลีนหากมีการป้อนข้อมูลที่ไม่ถูกต้อง /** * Sets the age for …

23 design-patterns  constructors  access-modifiers 

ฉันทำงานเกี่ยวกับการออกแบบ แต่กดปุ่มสิ่งกีดขวางบนถนนต่อไป ฉันมีคลาสเฉพาะ (ModelDef) ที่เป็นหลักเจ้าของต้นไม้โหนดซับซ้อนที่สร้างขึ้นโดยการแยก XML schema (คิด DOM) ฉันต้องการปฏิบัติตามหลักการออกแบบที่ดี (SOLID) และตรวจสอบให้แน่ใจว่าระบบผลลัพธ์นั้นสามารถทดสอบได้ง่าย ฉันมีความตั้งใจที่จะใช้ DI เพื่อส่งผ่านการพึ่งพาในตัวสร้างของ ModelDef (เพื่อให้สามารถสลับสิ่งเหล่านี้ได้อย่างง่ายดายถ้าจำเป็นระหว่างการทดสอบ) แม้ว่าสิ่งที่ฉันกำลังดิ้นรนคือการสร้างทรีโหนด ต้นไม้นี้จะถูกสร้างขึ้นด้วยวัตถุ "ค่า" อย่างง่ายซึ่งไม่จำเป็นต้องทำการทดสอบอย่างอิสระ (อย่างไรก็ตามฉันยังอาจส่ง Abstract Factory ไปยัง ModelDef เพื่อช่วยในการสร้างวัตถุเหล่านี้) แต่ฉันอ่านต่อไปว่าคอนสตรัคเตอร์ไม่ควรทำงานจริงใด ๆ (เช่นFlaw: Constructor ทำงานจริง ) นี่เป็นเหตุผลที่เหมาะสมสำหรับฉันหาก "งานจริง" หมายถึงการสร้างวัตถุที่ต้องอาศัยน้ำหนักมากซึ่งในภายหลังอาจต้องการเริ่มต้นการทดสอบ (สิ่งเหล่านั้นควรถูกส่งผ่านทาง DI) แต่สิ่งที่เกี่ยวกับวัตถุค่าน้ำหนักเบาเช่นต้นไม้โหนดนี้ ต้องสร้างต้นไม้ที่ไหนสักแห่งใช่มั้ย ทำไมไม่สร้างผ่าน ModelDef (ใช้, พูด, buildNodeTree () วิธี)? ฉันไม่ต้องการสร้างทรีโหนดด้านนอกของ ModelDef แล้วผ่านมันใน …

23 java  design  design-patterns  dependency-injection  constructors 

ฉันมีเว็บแอพ Spring สามชั้น: dao, บริการและผู้ควบคุม คอนโทรลเลอร์ไม่เคยเรียก dao โดยตรงมันทำผ่านเลเยอร์บริการ ตอนนี้เวลาส่วนใหญ่หากมีข้อยกเว้น dao (รันไทม์) ที่ไม่ได้จัดการมันจะถูกจับโดย JSP แสดงข้อความข้อผิดพลาดให้กับผู้ใช้ ชั้นบริการควรตรวจจับข้อยกเว้น dao ทั้งหมดและตัดเป็นข้อยกเว้นบริการหรือไม่ try { daoInstance.someDaoMethod(); } catch(DataAccessException dae) { throw new ServiceException("message", dae); } สมมติว่า ServiceException นั้นเป็น runtime เช่นกัน มีความแตกต่างใด ๆ เพียงแค่โยน DataAccessException แทนที่จะเป็น ServiceException หรือไม่ ฉันแค่คิดว่าเลเยอร์การนำเสนอไม่ควรทราบเกี่ยวกับข้อยกเว้นการเข้าถึงข้อมูล แต่ฉันไม่เห็นจุดที่จับข้อยกเว้นที่ไม่สามารถกู้คืนได้เพื่อห่อไว้

23 design-patterns  exception-handling  spring  dao 

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

23 design-patterns 

ฉันเห็นรูปแบบทั่วไปสองแบบสำหรับบล็อกใน Objective-C หนึ่งคือคู่ของความสำเร็จ: / ความล้มเหลว: บล็อกอื่น ๆ คือความสมบูรณ์เดียว: บล็อก ตัวอย่างเช่นสมมติว่าฉันมีงานที่จะส่งคืนวัตถุแบบอะซิงโครนัสและงานนั้นอาจล้มเหลว -taskWithSuccess:(void (^)(id object))success failure:(void (^)(NSError *error))failureรูปแบบแรกคือ -taskWithCompletion:(void (^)(id object, NSError *error))completionรูปแบบที่สองคือ ความสำเร็จ: / ความล้มเหลว: [target taskWithSuccess:^(id object) { // W00t! I've got my object } failure:^(NSError *error) { // Oh noes! report the failure. }]; เสร็จ: [target taskWithCompletion:^(id object, NSError …

23 design-patterns  objective-c 

ฉันทำงานเป็นเวลาสองปีในวาณิชธนกิจที่ยิ่งใหญ่ ฉันทำโครงการด้านเทคนิคบางอย่างด้วยความปรารถนาที่จะสร้างโค้ดที่มีประสิทธิภาพสูงสุดโดยคำนึงถึงรูปแบบการออกแบบที่ดีที่ปรับได้หลักการ SOLID กฎหมายของ demeter และหลีกเลี่ยงรหัสที่ซ้ำกันทุกประเภท ... เมื่อส่งมอบในการผลิต => ศูนย์ข้อบกพร่องทั้งหมดเกิดขึ้นตามที่คาดไว้ แต่นักพัฒนาส่วนใหญ่มาหาฉันเพื่อที่จะแม่นยำว่ารหัสของฉันทั้งหมดนั้นซับซ้อนเกินไปสำหรับการอ่านเพื่อความเข้าใจ ฉันฟังตัวอย่างเช่น: "ทำบางอย่างถ้าและอินสแตนซ์ของลืมความหลากหลายเพื่อที่จะแก้ไขข้อบกพร่องการผลิตฉุกเฉินได้อย่างง่ายดาย" ฉันไม่ชอบตอบ ...... การรู้ว่านักพัฒนาเหล่านี้ไม่อยากรู้อยากเห็นเลยปฏิเสธความพยายามที่จะเข้าใจการออกแบบที่ดี (ตัวอย่างเช่น 90% ของผู้พัฒนาไม่รู้ว่าอะไรคือรูปแบบกลยุทธ์และสร้างรหัสขั้นตอนและไม่เคยออกแบบเพราะพวกเขาต้องการ ) ผู้จัดการโครงการของฉันบอกว่าฉันผิดจริง ๆ และเป็นนักอุดมคติในโลกของธนาคาร คุณจะแนะนำอะไรให้ฉัน ฉันควรรักษาความปรารถนาของรหัสที่ดีจริง ๆ หรือปรับให้ฉันเป็นนักพัฒนาส่วนใหญ่ที่ฉันทำซ้ำไม่น่าสนใจจริงๆโดยการออกแบบรหัสตามที่ฉันความงามทั้งหมดของงานนักพัฒนาของเรา หรือในทางตรงกันข้ามพวกเขาควรเรียนรู้หลักการ OO ขั้นพื้นฐานและแนวปฏิบัติที่ดีที่สุดเพื่อปรับตัวให้เข้ากับรหัสของฉันหรือไม่?

23 java  design  design-patterns  solid 

พิจารณาวิธีการเหล่านี้: public List<Employee> GetAllEmployees() { using (Entities entities = new Entities()) { return entities.Employees.ToList(); } } public List<Job> GetAllJobs() { using (Entities entities = new Entities()) { return entities.Jobs.ToList(); } } public List<Task> GetAllTasksOfTheJob(Job job) { using (Entities entities = new Entities()) { return entities.Tasks.Where(t => t.JobId == job.Id).ToList(); } …

23 c#  design-patterns  dry 

รูปแบบโรงงาน (หรืออย่างน้อยใช้FactoryFactory..) เป็นก้นของตลกจำนวนมากเช่นที่นี่ นอกเหนือจากการมี verbose และชื่อ "สร้างสรรค์" เช่น RequestProcessorFactoryFactory.RequestProcessorFactoryแล้วมีอะไรผิดปกติกับรูปแบบของโรงงานถ้าคุณต้องโปรแกรมใน Java / C ++ และมี usecase สำหรับAbstract_factory_pattern ? ภาษายอดนิยมอื่นจะทำอย่างไร (เช่นRubyหรือScala ) จะหลีกเลี่ยงการใช้ภาษาในขณะที่จัดการความซับซ้อนที่คล้ายกันได้อย่างไร เหตุผลที่ฉันถามคือฉันเห็นคำวิจารณ์ส่วนใหญ่ของโรงงานที่กล่าวถึงในบริบทของระบบนิเวศJava / Java EEแต่พวกเขาไม่เคยอธิบายว่าภาษา / กรอบอื่น ๆ แก้ปัญหาได้อย่างไร

23 java  design-patterns 

codebase ของเรานั้นเก่าและโปรแกรมเมอร์ใหม่อย่างฉันเรียนรู้ที่จะทำอย่างที่มันทำเพื่อความสม่ำเสมอ เมื่อคิดว่าเราจะต้องเริ่มต้นที่ไหนสักแห่งฉันก็เลยทำมันเองเพื่อสร้างคลาสของตัวยึดข้อมูลอีกครั้ง: ลบเมธอด setter และสร้างฟิลด์ทั้งหมดfinal(ฉันใช้ " finalดี" ตามหลักการ) ตัวตั้งค่าถูกใช้เฉพาะในตัวสร้างเมื่อมันปรากฏออกดังนั้นสิ่งนี้จึงไม่มีผลข้างเคียง แนะนำคลาส Builder คลาส Builder นั้นจำเป็นเนื่องจากตัวสร้าง (ซึ่งเป็นสิ่งที่ให้การรีแฟคเตอร์ใหม่ในตอนแรก) ครอบคลุมโค้ดประมาณ 3 บรรทัด แต่ก็มีจำนวนมากของพารามิเตอร์ โชคดีที่มีมันเพื่อนร่วมทีมของฉันกำลังทำงานในโมดูลอื่นและเกิดขึ้นเพื่อต้องการผู้ตั้งค่าเนื่องจากค่าที่เขาต้องการนั้นมีอยู่ในจุดต่าง ๆ ในการไหล ดังนั้นรหัสดูเหมือนว่านี้: public void foo(Bar bar){ //do stuff bar.setA(stuff); //do more stuff bar.setB(moreStuff); } ฉันเป็นที่ถกเถียงกันอยู่ว่าเขาควรจะใช้ผู้สร้างแทนเพราะการกำจัด setters ทำให้ทุ่งนาไม่สามารถเปลี่ยนแปลงได้ (พวกเขาเคยได้ยินว่าฉันโกรธมากเกี่ยวกับความไม่สามารถเปลี่ยนแปลงได้ก่อนหน้านี้) และเพราะผู้สร้างอนุญาตให้สร้างวัตถุ ฉันร่างรหัสเทียมต่อไปนี้: public void foo(Bar bar){ try{ bar.setA(a); //enter exception-throwing …

22 design-patterns  teamwork  builder-pattern 

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

22 design  design-patterns  object-oriented 

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

21 design-patterns  unit-testing  functional-programming  dependency-injection