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

รูปแบบการออกแบบเป็นโซลูชันที่ใช้ซ้ำได้ทั่วไปสำหรับปัญหาที่เกิดขึ้นทั่วไปในการออกแบบซอฟต์แวร์

9
คุณควรอธิบายถึงรูปแบบการออกแบบสำหรับคนที่อยู่นอก Software World อย่างไร
ฉันต้องการอธิบายรูปแบบการออกแบบให้หลานสาวของฉัน แต่มักจะพยายามทำเช่นนั้น ส่วนใหญ่เป็นเพราะการที่ฉันไม่เข้าใจรูปแบบการออกแบบที่ชัดเจน คุณแนะนำให้อธิบายรูปแบบเช่น MVC, Singleton, Factory, Repository และอื่น ๆ ในแง่ง่าย ๆ ที่แม้แต่เด็กอายุ 10 ขวบก็สามารถเข้าใจได้ ฉันกำลังมองหาตัวอย่างที่สามารถช่วยให้เข้าใจรูปแบบได้ง่ายขึ้น ตัวอย่างที่มีของเล่นภาพยนตร์เพลง ฯลฯ

1
ชั้นกาวหรือการจัดการทำอะไรมากเกินไปเมื่อไหร่?
ฉันมีแนวโน้มที่จะสร้างชั้นเรียนแบบรวมศูนย์ที่จัดการชั้นเรียนอื่น ๆ ในการออกแบบของฉัน มันไม่ได้เก็บข้อมูลทุกอย่าง แต่คำขอข้อมูลส่วนใหญ่จะไปที่ "ผู้จัดการ" ก่อน ในขณะที่ดูคำตอบสำหรับคำถามนี้ฉันสังเกตเห็นคำว่า "God Object" Wikipedia ระบุว่าเป็น antipattern เข้าใจได้ เส้นแบ่งระหว่างคลาสกาวที่ถูกต้องหรือโมดูลที่ส่งผ่านข้อมูลและข้อความจากที่หนึ่งไปยังอีกที่หนึ่งและคลาสที่ทำมากเกินไป

4
การสร้างใหม่ในการออกแบบโดเมนขับเคลื่อน [ปิด]
ปิด คำถามนี้ต้องการรายละเอียดหรือความคมชัด ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ เพิ่มรายละเอียดและชี้แจงปัญหาโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันเพิ่งเริ่มทำงานในโครงการและเรากำลังใช้การออกแบบที่ขับเคลื่อนด้วยโดเมน (ตามที่กำหนดโดย Eric Evans ในการออกแบบที่ขับเคลื่อนด้วยโดเมน: การแก้ปัญหาความซับซ้อนในหัวใจของซอฟต์แวร์ฉันเชื่อว่าโครงการของเราเป็นผู้สมัครสำหรับการออกแบบนี้ แบบที่อีแวนส์อธิบายไว้ในหนังสือของเขา ฉันกำลังดิ้นรนกับความคิดในการปรับโครงสร้างใหม่อย่างต่อเนื่อง ฉันรู้ว่าการปรับโครงสร้างเป็นสิ่งจำเป็นในโครงการใด ๆ และจะเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้เมื่อมีการเปลี่ยนแปลงซอฟต์แวร์ อย่างไรก็ตามจากประสบการณ์ของฉันการเปลี่ยนโครงสร้างเกิดขึ้นเมื่อความต้องการของทีมพัฒนาเปลี่ยนไปไม่ใช่ความเข้าใจในการเปลี่ยนแปลงโดเมน ("การปรับโครงสร้างใหม่เป็นความเข้าใจที่ลึกซึ้งยิ่งขึ้น" ตามที่ Evans เรียกว่า) ฉันกังวลมากที่สุดกับความก้าวหน้าในการทำความเข้าใจโมเดลโดเมน ฉันเข้าใจว่าทำการเปลี่ยนแปลงเล็กน้อย แต่จะเกิดอะไรขึ้นถ้าจำเป็นต้องเปลี่ยนแปลงโมเดลเป็นอย่างมาก เป็นวิธีที่มีประสิทธิภาพในการโน้มน้าวตัวเอง (และอื่น ๆ ) คุณควร refactor หลังจากที่คุณได้รับรูปแบบโดเมนที่ชัดเจนคืออะไร? ท้ายที่สุดการปรับโครงสร้างองค์กรเพื่อปรับปรุงโค้ดหรือประสิทธิภาพอาจแตกต่างอย่างสิ้นเชิงจากวิธีการแสดงออกในแง่ของรหัสภาษาที่แพร่หลาย บางครั้งดูเหมือนว่าไม่มีเวลาพอที่จะสร้างใหม่ โชคดีที่ SCRUM ปล่อยให้ตนเองฟื้นฟู ลักษณะซ้ำของ SCRUM ทำให้ง่ายต่อการสร้างชิ้นเล็ก ๆ และเปลี่ยนแปลงและมัน แต่เมื่อเวลาผ่านไปชิ้นส่วนนั้นจะใหญ่ขึ้นและจะเกิดอะไรขึ้นถ้าคุณมีความก้าวหน้าหลังจากชิ้นส่วนนั้นใหญ่มากจนยากที่จะเปลี่ยน มีใครทำงานในโครงการที่ใช้การออกแบบโดยใช้โดเมนหรือไม่ ถ้าเป็นเช่นนั้นจะเป็นการดีหากได้รับข้อมูลเชิงลึกเกี่ยวกับสิ่งนี้ ฉันต้องการได้ยินเรื่องราวความสำเร็จเป็นพิเศษเนื่องจาก DDD ดูเหมือนจะยากมาก ขอบคุณ!

2
ฟังก์ชั่นโปรแกรมมิงจัดการสถานการณ์ที่วัตถุเดียวกันถูกอ้างอิงจากหลาย ๆ ที่ได้อย่างไร?
ฉันกำลังอ่านและได้ยินว่าผู้คน (บนเว็บไซต์นี้) ชื่นชมกระบวนทัศน์การเขียนโปรแกรมการทำงานเป็นประจำโดยเน้นว่าการมีทุกสิ่งที่ไม่เปลี่ยนรูปนั้นดีเพียงใด ผู้คนเสนอวิธีการนี้แม้ในภาษา OO ที่จำเป็นแบบดั้งเดิมเช่น C #, Java หรือ C ++ ไม่เพียง แต่ในภาษาที่ใช้งานได้จริงเท่านั้นเช่น Haskell ที่บังคับใช้โปรแกรมนี้ ฉันพบว่ามันยากที่จะเข้าใจเพราะฉันพบว่าความไม่แน่นอนและผลข้างเคียง ... สะดวก อย่างไรก็ตามเมื่อพิจารณาว่าผู้คนในขณะนี้ประณามผลข้างเคียงและพิจารณาว่าเป็นวิธีปฏิบัติที่ดีในการกำจัดพวกเขาทุกที่ที่เป็นไปได้ฉันเชื่อว่าถ้าฉันต้องการเป็นโปรแกรมเมอร์ที่มีความสามารถฉันจะต้องเริ่มต้น ดังนั้นคำถามของฉัน ที่เดียวเมื่อฉันพบปัญหากับกระบวนทัศน์การทำงานคือเมื่อวัตถุถูกอ้างอิงโดยธรรมชาติจากหลาย ๆ ที่ ผมขออธิบายสองตัวอย่าง ตัวอย่างแรกจะเป็นของฉัน# เกม C ฉันพยายามที่จะทำในเวลาว่างของฉัน มันเป็นเกมบนเว็บแบบเปิดที่ผู้เล่นทั้งสองมีทีมจาก 4 มอนสเตอร์และสามารถส่งมอนสเตอร์จากทีมของพวกเขาไปยังสนามรบซึ่งมันจะเผชิญหน้ากับสัตว์ประหลาดที่ถูกส่งโดยผู้เล่นฝ่ายตรงข้าม ผู้เล่นสามารถจำสัตว์ประหลาดจากสนามรบและแทนที่พวกมันด้วยสัตว์ประหลาดอีกตัวจากทีมของพวกเขา (คล้ายกับโปเกมอน) ในการตั้งค่านี้มอนสเตอร์ตัวเดียวสามารถอ้างอิงได้อย่างเป็นธรรมชาติจากสถานที่อย่างน้อย 2 แห่ง: ทีมของผู้เล่นและสนามรบซึ่งอ้างอิงมอนสเตอร์ที่ "คล่องแคล่ว" สองตัว ทีนี้ลองพิจารณาสถานการณ์ตอนที่มอนสเตอร์ตัวใดตัวหนึ่งถูกโจมตีและเสียพลังชีวิต 20 แต้ม ภายในวงเล็บของกระบวนทัศน์ที่จำเป็นฉันปรับเปลี่ยนhealthฟิลด์ของมอนสเตอร์นี้เพื่อสะท้อนการเปลี่ยนแปลงนี้ - และนี่คือสิ่งที่ฉันกำลังทำอยู่ตอนนี้ อย่างไรก็ตามสิ่งนี้ทำให้Monsterคลาสไม่แน่นอนและฟังก์ชั่นที่เกี่ยวข้อง (เมธอด) ไม่บริสุทธิ์ซึ่งฉันคิดว่าเป็นวิธีปฏิบัติที่ไม่ดี ณ …

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

3
คุณสมบัตินามธรรมในคลาสฐานเพื่อบังคับให้โปรแกรมเมอร์กำหนดมัน
ฉันกำลังเขียนโค้ดด้วยรูปแบบสถานะสำหรับอุปกรณ์ฝังตัว ฉันมีคลาสฐาน / นามธรรมที่เรียกว่าสถานะและจากนั้นแต่ละสถานะแยก (คอนกรีต) แยกชั้นใช้ระดับรัฐนามธรรม ในระดับรัฐฉันมีวิธีนามธรรมหลายอย่าง ถ้าฉันไม่ใช้วิธีนามธรรมในคลาส discrete (คอนกรีต), Visual Studio จะให้ข้อผิดพลาดดังนี้: ... ข้อผิดพลาด 1 'myConcreteState' ไม่ได้ใช้สมาชิกนามธรรมที่สืบทอด 'myAbstractState' ตอนนี้: ฉันกำลังพยายามสร้างคุณสมบัติสตริงสำหรับแต่ละรัฐชื่อ StateName เมื่อใดก็ตามที่ฉันสร้างคลาสคอนกรีตใหม่ฉันต้องกำหนด StateName ฉันต้องการให้ VS ส่งข้อผิดพลาดหากฉันไม่ได้ใช้ มีวิธีง่าย ๆ ในการทำเช่นนี้? ฉันได้ลองในชั้นนามธรรม / ฐาน: public abstract string StateName { get; set; } แต่ฉันไม่จำเป็นต้องใช้วิธีการรับและตั้งค่าในแต่ละรัฐ คำถามที่มีการแก้ไข: ในสถานการณ์ที่เหมาะสมอุดมคติแต่ละระดับของรัฐจะต้องกำหนดให้ StateName กำหนดและสืบทอดมาจากคลาสฐานนามธรรม StateName = "MyState1"; //or …

1
แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ MVVM และ MVC ใน delphi Pascal
ฉันเป็นโปรแกรมเมอร์ Pascal ของ Delphi ฉันใช้ Embarcadero delphi XE ล่าสุดและฉันต้องการใช้ประโยชน์จากรูปแบบการออกแบบเช่นตัวควบคุมมุมมอง Model และ Model view view model อย่างไรก็ตามดูเหมือนว่าจะไม่มีอะไรมากบนเว็บเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดสำหรับการทำสิ่งนี้ในภาษาปาสกาล ตัวอย่างส่วนใหญ่ที่ฉันพบมีในภาษา C # และคุณสมบัติภาษาบางอย่างไม่มีอยู่ในภาษาปาสกาลซึ่งหมายความว่าฉันอาจต้องหาวิธีในการใช้คุณสมบัติเหล่านั้น ฉันกำลังพยายามปรับรหัสจากบทความนี้ที่นี่ ฉันจะระบุปัญหาที่ฉันเผชิญ ประเภทที่ทำให้เป็นโมฆะ ปาสคาลไม่มีประเภท nullable เช่น C # ดังนั้นฉันได้สร้างของตัวเอง TNullable<T> = record strict private fHasValue : boolean; fValue : T; function GetValue:T; procedure SetValue(newValue : T); public property HasValue : …

2
ไปยังที่เก็บหรือไม่ไปยังที่เก็บ
เมื่อครั้งแรกที่ฉันได้เรียนรู้เกี่ยวกับการออกแบบการขับเคลื่อนด้วยโดเมนฉันยังได้รับการแนะนำให้รู้จักกับที่เก็บและรูปแบบการทำงานที่ครั้งหนึ่งดูเหมือนจะเป็นอันดับต้น ๆ สำหรับเด็กสุดเท่ห์ที่ทำให้แบบสอบถาม SQL เช่น cavemans เทียบกับฐานข้อมูล ยิ่งฉันเข้าสู่หัวข้อนั้นมากเท่าไหร่ฉันก็ยิ่งรู้ว่าพวกเขาไม่จำเป็นอีกต่อไปเพราะORMsเช่นEFและNHibernateที่ใช้ทั้งสองหน่วยงานและพื้นที่เก็บข้อมูลไว้ใน API เดียวที่เรียกว่าเซสชันหรือบริบท ตอนนี้ฉันไม่แน่ใจว่าจะทำอย่างไร เพื่อเก็บหรือไม่ไปยังที่เก็บ ผมเข้าใจโต้แย้งว่าแนวคิดดังกล่าวรั่วเพียงสิ่งที่มากกว่าซับซ้อนขณะที่การเพิ่มอะไรอย่างที่อาจลดความซับซ้อนของการเข้าถึงข้อมูล แต่ก็ไม่ได้รู้สึกขวาคู่ทุกด้านที่เป็นไปได้ของการประยุกต์ใช้ของฉันไปเช่นEntity Framework โดยปกติฉันทำตามคำแนะนำง่ายๆ: เลเยอร์โดเมนคือหัวใจของระบบที่มีเอนทิตี, บริการ, ที่เก็บ ... ชั้นโครงสร้างพื้นฐานให้การใช้งานของส่วนต่อประสานโดเมนที่เกี่ยวข้องกับโครงสร้างพื้นฐานเช่นไฟล์ฐานข้อมูลโปรโตคอล ชั้นแอพลิเคชันเป็นเจ้าภาพรากองค์ประกอบที่เชื่อมโยงสิ่งต่างๆและประสานทุกอย่าง โซลูชันของฉันมักจะมีลักษณะเช่นนี้: Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. ฉันรักษาเลเยอร์โดเมนของฉันให้สะอาดโดยใช้สิ่งIRepository<'T>ที่เป็นข้อกังวลเกี่ยวกับโดเมนไม่ขึ้นอยู่กับสิ่งอื่นใดที่บอกวิธีเข้าถึงข้อมูล เมื่อตอนนี้ฉันจะทำให้การใช้งานที่เป็นรูปธรรมของIModule2Serviceที่ต้องการเข้าถึงข้อมูลฉันจะต้องฉีดDbContextและโดยสิ่งนี้เชื่อมต่อโดยตรงกับชั้นโครงสร้างพื้นฐาน ( มาที่โครงการ Visual Studio สิ่งนี้อาจทำให้ยุ่งยากเพราะการอ้างอิงแบบวงกลม! ) นอกจากนี้สิ่งที่สามารถเป็นทางเลือกให้กับศูนย์รับฝากและงานfucktons ? CQRS? …

2
การสืบทอดบริบทเป็นเช่นที่แสดงโดยตัวอย่างเป็ดของ Head First Design Patterns ซึ่งไม่เกี่ยวข้องกับรูปแบบกลยุทธ์หรือไม่
ในHead First Design Patternsมันสอนรูปแบบกลยุทธ์โดยใช้ตัวอย่าง Duck ที่ subclasses ที่แตกต่างกันของ Duck สามารถกำหนดพฤติกรรมเฉพาะที่รันไทม์ จากความเข้าใจของฉันจุดประสงค์ของรูปแบบกลยุทธ์คือการเปลี่ยนพฤติกรรมของวัตถุเดี่ยวที่รันไทม์ แต่พวกเขากำลังใช้การสืบทอดของ Duck เพื่อเปลี่ยนพฤติกรรมของ Duck ชนิดต่างๆ ความสัมพันธ์กัน? การสืบทอดบริบทของเป็ดนั้นไม่เกี่ยวข้องกับรูปแบบกลยุทธ์หรือการเปลี่ยนแปลงประเภทเป็ดและการเปลี่ยนแปลงพฤติกรรมของพวกเขาเป็นเหตุผลที่ดีที่จะใช้รูปแบบกลยุทธ์หรือไม่ สถานการณ์ที่คุณต้องการเปลี่ยนแปลงทั้งสองอย่างนั้นเป็นเหตุผลที่ดีที่จะใช้รูปแบบกลยุทธ์หรือไม่ เหตุใดพวกเขาจึงรวมสิ่งนี้เป็นตัวอย่างรูปแบบกลยุทธ์? ตัวอย่างที่เรียบง่าย ฉันสามารถทำให้ตัวอย่างนี้ง่ายขึ้นโดยแค่มีคลาส Duck (ไม่มีคลาสที่ได้รับ) หรือไม่ จากนั้นเมื่อนำวัตถุเป็ดหนึ่งชิ้นมาใช้จะสามารถกำหนดพฤติกรรมที่แตกต่างกันตามสถานการณ์บางอย่างที่ไม่ได้ขึ้นอยู่กับประเภทวัตถุของตัวเอง ตัวอย่างเช่นการเปลี่ยนแปลง FlyBehavior ตามสภาพอากาศหรือการเปลี่ยนแปลง QuackBehavior ตามช่วงเวลาของวันหรือว่าเป็ดหิวแค่ไหน ฉันรู้ว่านี่จะเป็นการแก้ปัญหาที่แตกต่างจากในหนังสือ แต่สิ่งที่ฉันกำลังมองหาคือตัวอย่างรูปแบบกลยุทธ์ที่เกี่ยวข้องเพื่อถอยกลับ ตัวอย่างด้านบนของฉันจะเป็นรูปแบบกลยุทธ์ด้วยหรือไม่ แก้ไข: ผมเป็นคนที่ประสบความสำเร็จในการหาง่าย 2 ตัวอย่างรูปแบบกลยุทธ์ที่ปฏิบัติตามอย่างเคร่งครัดมากขึ้นที่จะเป็นรูปแบบเพียงกลยุทธ์โดยไม่ต้องมรดกบริบท: Hunter.javaและsolver.py

4
รูปแบบการออกแบบสำหรับพฤติกรรม polymorphic ในขณะที่อนุญาตให้แยกไลบรารี
สมมติว่าผมมีลำดับชั้นของชั้นเรียน:Item Rectangle, Circle, Triangleฉันต้องการที่จะสามารถวาดพวกเขาดังนั้นความเป็นไปได้ครั้งแรกของฉันคือการเพิ่มDraw()วิธีเสมือนในแต่ละ: class Item { public: virtual ~Item(); virtual void Draw() =0; }; อย่างไรก็ตามฉันต้องการแยกฟังก์ชั่นการวาดภาพเป็นห้องสมุดวาดแยกในขณะที่ห้องสมุด Core มีเพียงการแสดงขั้นพื้นฐาน มีความเป็นไปได้สองอย่างที่ฉันคิดได้: 1 - A DrawManagerที่รับรายการItems และต้องใช้dynamic_cast<>เพื่อระบุสิ่งที่ต้องทำ: class DrawManager { void draw(ItemList& items) { FOREACH(Item* item, items) { if (dynamic_cast<Rectangle*>(item)) { drawRectangle(); } else if (dynamic_cast<Circle*>(item)) { drawCircle(); } .... } } }; …

3
ฉันจะฝึกรูปแบบการออกแบบและการปรับโครงสร้างใหม่ด้วยวิธีที่รอบคอบได้อย่างไร [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ฉันกำลังอ่านหนังสือRefactoring เกี่ยวกับรูปแบบและสงสัยว่าฉันจะมีโอกาสฝึกฝนทักษะได้อย่างไรเพราะหากไม่มีการฝึกฝนอย่างรอบคอบเกี่ยวกับวิธีการใหม่ในการสร้างและใช้รูปแบบทักษะของฉันจะไม่ดีขึ้น แต่งานในสำนักงานกำหนดให้ฉันต้องทำภารกิจให้เสร็จโดยเร็วที่สุด ส่วนใหญ่การออกแบบและสถาปัตยกรรมของโครงการไม่ได้ถูกควบคุมโดยฉันฉันสามารถทำตามสไตล์ที่คล้ายกันเป็นรหัสที่มีอยู่เท่านั้น บางครั้งมีโครงการที่มีการออกแบบไม่ดี แต่ก็มีนักพัฒนาอีกคนหนึ่งที่มีทักษะการออกแบบดีกว่าฉันและเขามีแผนทั้งหมดในการปรับโครงสร้างโครงการอีกครั้งดังนั้นฉันจึงเพิ่งทำตามแผนของเขา ฉันจะมีโอกาสฝึกฝนได้อย่างไร

5
แนวปฏิบัติที่ดีที่สุด - การห่อถ้ารอบ ๆ การเรียกใช้ฟังก์ชัน vs การเพิ่มการออกก่อนหน้าถ้าการป้องกันในการทำงาน
ฉันรู้ว่านี่สามารถใช้เฉพาะกรณีได้ แต่ฉันพบว่าตัวเองสงสัยว่าสิ่งนี้บ่อยเกินไป มีไวยากรณ์ที่ต้องการโดยทั่วไปหรือไม่ ฉันไม่ได้ถามว่าอะไรคือวิธีที่ดีที่สุดเมื่ออยู่ในฟังก์ชั่นฉันกำลังถามว่าฉันควรออกจากเร็วหรือควรจะไม่เรียกฟังก์ชั่นนี้ Wrap ถ้าเรียกฟังก์ชันรอบ if (shouldThisRun) { runFunction(); } มีฟังก์ชั่นif ( guard ) runFunction() { if (!shouldThisRun) return; } ตัวเลือกหลังมีความเป็นไปได้ที่จะลดความซ้ำซ้อนของรหัสหากฟังก์ชั่นนี้เรียกว่าหลายครั้ง แต่บางครั้งมันก็รู้สึกผิดที่จะเพิ่มเข้าไปที่นี่แล้วคุณอาจสูญเสียความรับผิดชอบเดียวของฟังก์ชั่น นี่เป็นตัวอย่าง ถ้าฉันมีฟังก์ชั่น updateStatus () ที่จะอัพเดทสถานะของบางสิ่ง ฉันต้องการเฉพาะสถานะที่อัปเดตหากมีการเปลี่ยนแปลงสถานะ ฉันรู้ว่าสถานที่ในรหัสของฉันที่สถานะมีศักยภาพในการเปลี่ยนแปลงและฉันรู้ว่าสถานที่อื่น ๆ ที่มีการเปลี่ยนแปลงท้าทาย ฉันไม่แน่ใจว่ามันเป็นแค่ฉันหรือเปล่า แต่มันก็ค่อนข้างสกปรกที่จะตรวจสอบฟังก์ชั่นภายในเพราะฉันต้องการให้ฟังก์ชั่นนี้บริสุทธิ์ที่สุดเท่าที่จะเป็นไปได้ - ถ้าฉันเรียกมันว่าฉันคาดว่าสถานะจะได้รับการอัพเดต แต่ฉันไม่สามารถบอกได้ว่าจะดีกว่าที่จะวางสายในสถานที่ไม่กี่แห่งที่ฉันรู้ว่ามีศักยภาพที่จะไม่เปลี่ยนแปลง

2
รูปแบบพื้นที่เก็บข้อมูลกับการสร้างวัตถุ DAL
เท่าที่ผมได้เรียนรู้ที่ควรมีIRepository CRUDจากนั้นเราจะสืบทอดสิ่งนี้IRepositoryในอินเทอร์เฟซอื่นของเราที่ชอบIProductและใช้IProductคลาสที่เป็นรูปธรรมProductRepositoryด้วยวิธีการเช่นGetAllProducts(), Top5Products(). เราสามารถทำเช่นเดียวกันกับสถาปัตยกรรมระดับ n เช่นการสร้างDAL Class Libraryและในนั้นกำหนดชั้นเรียนProductด้วยวิธีการเช่น,GetAllProducts()Top5Products() ทั้งในDAL.ProductและRepo.ProductRepositoryชั้นเรียนที่เราเริ่มต้นDB ContextของEntity Frameworkและสอบถามข้อมูลที่เกี่ยวข้องของเรา การโทรคล้ายกันทั้งในRepo.ProductRepositoryหรือDAL.ProductจากวิธีการBLL ในมุมมองของความคล้ายคลึงกันเหล่านี้คำถามของฉัน Repos มีประโยชน์อย่างไร? ฉันสามารถทำเช่นเดียวกันกับความสะดวกมากโดยใช้สถาปัตยกรรม n ชั้นด้วย ( Controller, BLL Class Library, DAL Class Library)

3
มีเหตุผลที่จะไม่แก้ไขค่าของพารามิเตอร์ที่ส่งผ่านโดยค่าหรือไม่?
มีข้อโต้แย้งวิศวกรรมซอฟต์แวร์ที่สนับสนุนหรือต่อต้านการแก้ไขค่าของพารามิเตอร์ค่าในร่างกายของฟังก์ชันหรือไม่? การทะเลาะวิวาทกันที่เกิดขึ้นซ้ำ ๆ (ส่วนใหญ่สนุกดี) ในทีมของฉันคือควรแก้ไขพารามิเตอร์ที่ส่งผ่านค่าหรือไม่ สมาชิกสองคนของทีมยืนกรานว่าไม่ควรกำหนดพารามิเตอร์เพื่อให้ค่าที่ส่งผ่านไปยังฟังก์ชันสามารถสอบปากคำได้เสมอ ฉันไม่เห็นด้วยและถือว่าพารามิเตอร์ไม่มีอะไรมากไปกว่าตัวแปรท้องถิ่นที่เริ่มต้นด้วยไวยากรณ์ของการเรียกใช้เมธอด หากค่าดั้งเดิมของพารามิเตอร์ by-value มีความสำคัญกว่าตัวแปรท้องถิ่นสามารถประกาศเพื่อเก็บค่านี้ไว้อย่างชัดเจน ฉันไม่มั่นใจว่าเราสองคนได้รับการสนับสนุนที่ดีสำหรับตำแหน่งของเรา นี่เป็นความขัดแย้งทางศาสนาที่ไม่สามารถแก้ไขได้หรือมีเหตุผลทางวิศวกรรมซอฟต์แวร์ที่ดีทั้งในทิศทางใดทิศทางหนึ่งหรือไม่? หมายเหตุ: คำถามของหลักการยังคงอยู่โดยไม่คำนึงถึงรายละเอียดการใช้งานของภาษานั้น ๆ ใน JavaScript เช่นที่รายการอาร์กิวเมนต์เป็นไดนามิกเสมอพารามิเตอร์สามารถถือได้ว่าเป็นน้ำตาล syntactic สำหรับการเริ่มต้นตัวแปรท้องถิ่นจากargumentsวัตถุ ถึงกระนั้นใคร ๆ ก็สามารถปฏิบัติต่อตัวระบุพารามิเตอร์ที่ประกาศว่าเป็น "พิเศษ" เพราะพวกเขายังคงจับภาพการส่งผ่านข้อมูลจากผู้โทรไปยังผู้รับ

1
รูปแบบไม่ใช่แบบบล็อกดังนั้นฉันไม่ควรสร้างแอปในรูปแบบ MVC / MVP?
ฉันได้อ่านหน้านี้เกี่ยวกับรูปแบบการออกแบบและวิธีที่คุณควรปฏิบัติต่อพวกเขาเมื่อเขียนรหัสของคุณ จากความเข้าใจของฉันเป็นชื่อในรัฐลิงค์: รูปแบบไม่ใช่การสร้างบล็อก ถ้าฉันเข้าใจถูกต้องนี่หมายความว่าไม่ใช้รูปแบบการออกแบบจนกว่าจะเหมาะสมใช่ไหม? อย่าเริ่มต้นโดยบอกว่าคุณจะใช้รูปแบบกลยุทธ์รอจนกว่าคุณจะเขียนโค้ดและถ้าใช้รูปแบบกลยุทธ์นั้นเหมาะสมกับการออกแบบของคุณแล้วใช้มัน ฉันปฏิบัติต่อรูปแบบMCV / MVPเช่นเดียวกับเมื่อฉันสร้างแอปพลิเคชัน GUI หรือไม่ จากลิงก์ที่เกี่ยวข้องมันบอกว่ามันเป็นรูปแบบสถาปัตยกรรม สมมติว่าถ้าฉันสร้างแอปพลิเคชัน GUI และฉันไม่ได้ใช้รูปแบบ MCV / MVP แต่รหัสของฉันสะอาดอ่านได้และบำรุงรักษาได้หรือไม่มันยังคงเป็นกลิ่นรหัส / การออกแบบที่ไม่ดีที่ฉันไม่ได้ใช้รูปแบบ MCV / MVP ?

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.