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

รูปแบบการออกแบบบริดจ์แยกการใช้งานจากอินเตอร์เฟสของโปรแกรม ทำไมข้อได้เปรียบนี้?

18 design-patterns 

ฉันอ่านบทความการเขียนโปรแกรมและกล่าวถึงรูปแบบของมัณฑนากร ฉันเขียนโปรแกรมมาซักพัก แต่ไม่มีการศึกษาหรือการฝึกอบรมอย่างเป็นทางการ แต่ฉันพยายามเรียนรู้เกี่ยวกับรูปแบบมาตรฐานและเช่นนั้น ดังนั้นฉันจึงค้นหามัณฑนากรและพบบทความ Wikipediaอยู่ ตอนนี้ฉันเข้าใจแนวคิดของรูปแบบมัณฑนากร แต่ตอนนี้ฉันสับสนเล็กน้อย: ยกตัวอย่างเช่นพิจารณาหน้าต่างในระบบหน้าต่าง ในการอนุญาตให้เลื่อนเนื้อหาของหน้าต่างเราอาจต้องการเพิ่มแถบเลื่อนแนวนอนหรือแนวตั้งลงตามความเหมาะสม สมมติว่าหน้าต่างแสดงโดยอินสแตนซ์ของคลาสหน้าต่างและสมมติว่าคลาสนี้ไม่มีฟังก์ชันการทำงานสำหรับการเพิ่มแถบเลื่อน เราสามารถสร้างคลาสย่อย ScrollingWindow ที่จัดเตรียมไว้หรือเราสามารถสร้าง ScrollingWindowDecorator ที่เพิ่มฟังก์ชันนี้ให้กับวัตถุหน้าต่างที่มีอยู่ ณ จุดนี้การแก้ปัญหาอย่างใดอย่างหนึ่งจะดี ทีนี้สมมติว่าเราต้องการความสามารถในการเพิ่มเส้นขอบให้กับหน้าต่างของเราด้วย คลาส Window ดั้งเดิมของเราไม่สนับสนุน ขณะนี้คลาสย่อย ScrollingWindow มีปัญหาเนื่องจากได้สร้างหน้าต่างชนิดใหม่อย่างมีประสิทธิภาพ หากเราต้องการเพิ่มการรองรับชายแดนให้กับหน้าต่างทั้งหมดเราต้องสร้างคลาสย่อย WindowWithBorder และ ScrollingWindowWithBorder เห็นได้ชัดว่าปัญหานี้แย่ลงเมื่อมีการเพิ่มคุณสมบัติใหม่ทุกอย่าง สำหรับโซลูชันมัณฑนากรเราเพียงสร้าง BorderedWindowDecorator ใหม่ - ที่รันไทม์เราสามารถตกแต่งหน้าต่างที่มีอยู่ด้วย ScrollingWindowDecorator หรือ BorderedWindowDecorator หรือทั้งสองอย่างตามที่เราเห็นสมควร ตกลงเมื่อพวกเขาบอกว่าจะเพิ่มเส้นขอบให้กับหน้าต่างทั้งหมดทำไมไม่เพียงเพิ่มฟังก์ชันการทำงานลงในคลาสหน้าต่างดั้งเดิมเพื่ออนุญาตให้มีตัวเลือก วิธีที่ฉันเห็นคือ subclassing เป็นเพียงการเพิ่มฟังก์ชั่นเฉพาะให้กับคลาสหรือแทนที่เมธอดคลาส หากฉันต้องการเพิ่มฟังก์ชันการทำงานให้กับวัตถุที่มีอยู่ทั้งหมดเหตุใดฉันจึงไม่ปรับเปลี่ยน superclass ให้ทำเช่นนั้น มีอีกบรรทัดในบทความ: รูปแบบมัณฑนากรเป็นอีกทางเลือกหนึ่งของการทำคลาสย่อย การจัดคลาสย่อยเพิ่มลักษณะการทำงาน ณ …

18 programming-languages  object-oriented  design-patterns 

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

18 design-patterns 

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

18 design-patterns  dependency-injection  inversion-of-control  ioc-containers  evidence-based 

แม้ว่าในรหัสด้านล่างจะใช้การซื้อรายการเดียวอย่างง่ายในไซต์อีคอมเมิร์ซคำถามทั่วไปของฉันคือการอัปเดตข้อมูลสมาชิกทั้งหมดเพื่อให้ข้อมูลของวัตถุอยู่ในสถานะที่ถูกต้องตลอดเวลา ฉันพบว่า "ความสอดคล้อง" และ "สถานะเป็นสิ่งที่ชั่วร้าย" เป็นวลีที่เกี่ยวข้องซึ่งได้กล่าวถึงที่นี่: https://en.wikibooks.org/wiki/Object_Oriented_Programming#.22State.22_is_Evil.21 <?php class CartItem { private $price = 0; private $shipping = 5; // default private $tax = 0; private $taxPC = 5; // fixed private $totalCost = 0; /* private function to update all relevant data members */ private function updateAllDataMembers() { $this->tax …

18 design-patterns  object-oriented  php  state 

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

17 design-patterns  anti-patterns  loops 

ไตรมาสที่ดีของศตวรรษที่ผ่านมาเมื่อฉันเรียนรู้ C ++ ฉันได้รับการสอนว่าอินเตอร์เฟสควรจะให้อภัยและเท่าที่เป็นไปได้ไม่สนใจเกี่ยวกับลำดับที่วิธีการนั้นถูกเรียกเนื่องจากผู้บริโภคอาจไม่สามารถเข้าถึงแหล่งข้อมูลหรือเอกสารแทน นี้. อย่างไรก็ตามเมื่อใดก็ตามที่ฉันให้คำปรึกษาผู้เขียนโปรแกรมรุ่นเยาว์และผู้พัฒนาระดับสูงจะได้ยินฉันพวกเขามีปฏิกิริยากับความประหลาดใจซึ่งทำให้ฉันสงสัยว่านี่เป็นเรื่องจริงหรือไม่ ชัดเจนเหมือนโคลน พิจารณาอินเทอร์เฟซด้วยวิธีการเหล่านี้ (สำหรับการสร้างไฟล์ข้อมูล): OpenFile SetHeaderString WriteDataLine SetTrailerString CloseFile ตอนนี้คุณสามารถแน่นอนเพียงไปถึงเหล่านี้ในการสั่งซื้อ แต่บอกว่าคุณไม่สนใจเกี่ยวกับชื่อไฟล์ (คิดว่าa.out) AddDataLineหรือสิ่งที่หัวและสตริงรถพ่วงถูกรวมคุณสามารถเพียงแค่โทร ตัวอย่างที่มีความรุนแรงน้อยกว่าอาจมองข้ามส่วนหัวและส่วนท้าย อาจมีอีกอย่างหนึ่งอาจตั้งค่าสตริงส่วนหัวและส่วนท้ายก่อนที่จะเปิดไฟล์ นี่เป็นหลักการของการออกแบบส่วนต่อประสานที่ได้รับการยอมรับหรือเป็นวิธี POLA ก่อนที่จะได้รับชื่อหรือไม่? NB ไม่จมลงในส่วนย่อยของอินเทอร์เฟซนี้มันเป็นเพียงตัวอย่างเพื่อประโยชน์ของคำถามนี้

17 design  design-patterns  interfaces 

อ้างอิงจากโรเบิร์ตซี. มาร์ติน SRP ระบุว่า: ไม่ควรมีเหตุผลมากกว่าหนึ่งข้อในการเปลี่ยนชั้นเรียน อย่างไรก็ตามในClean Codeในหนังสือของเขาบทที่ 3: ฟังก์ชั่นเขาแสดงบล็อคของรหัสต่อไปนี้: public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } } แล้วสหรัฐฯ: มีปัญหาหลายอย่างกับฟังก์ชั่นนี้ อย่างแรกคือมันมีขนาดใหญ่และเมื่อมีการเพิ่มประเภทพนักงานใหม่ก็จะเพิ่มขึ้น ประการที่สองมันชัดเจนมากกว่าสิ่งหนึ่ง ประการที่สามมีการละเมิด Single รับผิดชอบหลักการ (SRP) เพราะมีมากกว่าเหตุผลหนึ่งที่ทำให้มันมีการเปลี่ยนแปลง [เน้นเหมือง] ก่อนอื่นฉันคิดว่า SRP ถูกกำหนดไว้สำหรับคลาส …

17 design-patterns  single-responsibility 

ลองพิจารณาตัวอย่างด้านล่าง การเปลี่ยนแปลงใด ๆ กับ ColorChoice enum จะส่งผลกระทบต่อคลาสย่อย IWindowColor ทั้งหมด enums มีแนวโน้มที่จะทำให้เกิดการเชื่อมต่อที่เปราะหรือไม่? มีอะไรดีไปกว่า Enum ที่จะยอมให้มีความยืดหยุ่นแบบ polymorphic มากขึ้นหรือไม่? enum class ColorChoice { Blue = 0, Red = 1 }; class IWindowColor { public: ColorChoice getColor() const=0; void setColor( const ColorChoice value )=0; }; แก้ไข: ขออภัยที่ใช้สีเป็นตัวอย่างของฉันนั่นไม่ใช่สิ่งที่เป็นคำถาม นี่คือตัวอย่างอื่นที่หลีกเลี่ยงปลาเฮอริ่งแดงและให้ข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่ฉันหมายถึงโดยความยืดหยุ่น enum class CharacterType { orc = …

17 design-patterns  c++  interfaces  enum  abstract-class 

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

17 design-patterns 

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

17 design-patterns  dependency-injection 

ภาพนี้นำมาจากการใช้การออกแบบและรูปแบบที่ใช้โดเมนขับเคลื่อน: พร้อมตัวอย่างใน C # และ. NET นี่คือแผนภาพคลาสสำหรับรูปแบบสถานะที่ a SalesOrderสามารถมีสถานะต่างกันในช่วงเวลาของชีวิต อนุญาตให้ช่วงการเปลี่ยนภาพบางอย่างระหว่างรัฐที่แตกต่างกัน ตอนนี้OrderStateคลาสเป็นabstractคลาสและวิธีการทั้งหมดได้รับการสืบทอดไปยังคลาสย่อย หากเราพิจารณาคลาสย่อยCancelledซึ่งเป็นสถานะสุดท้ายที่ไม่อนุญาตให้มีการเปลี่ยนสถานะเป็นสถานะอื่นเราจะต้องoverrideใช้วิธีการทั้งหมดในคลาสนี้เพื่อโยนข้อยกเว้น ตอนนี้ไม่ได้เป็นการละเมิดหลักการทดแทนของ Liskov เนื่องจาก sublcass ไม่ควรเปลี่ยนพฤติกรรมของผู้ปกครองหรือไม่ การเปลี่ยนคลาสนามธรรมเป็นอินเตอร์เฟสแก้ไขสิ่งนี้หรือไม่? จะแก้ไขได้อย่างไร?

17 java  c#  design-patterns  object-oriented-design  liskov-substitution 

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

17 design-patterns  design-principles  liskov-substitution 

ฉันจะใช้พื้นที่เก็บข้อมูลและฉันต้องการใช้รูปแบบ UOW เนื่องจากผู้บริโภคของที่เก็บสามารถดำเนินการหลายอย่างและฉันต้องการที่จะยอมรับพวกเขาในครั้งเดียว หลังจากอ่านบทความต่าง ๆ เกี่ยวกับเรื่องนี้แล้วฉันยังไม่เข้าใจวิธีการเชื่อมโยงองค์ประกอบทั้งสองนี้ขึ้นอยู่กับบทความที่กำลังทำในลักษณะอื่น ๆ บางครั้ง UOW เป็นสิ่งที่อยู่ภายในที่เก็บ: public class Repository { UnitOfWork _uow; public Repository() { _uow = IoC.Get<UnitOfWork>(); } public void Save(Entity e) { _uow.Track(e); } public void SubmittChanges() { SaveInStorage(_uow.GetChanges()); } } และบางครั้งก็เป็นภายนอก: public class Repository { public void Save(Entity e, UnitOfWork uow) { uow.Track(e); …

17 design-patterns  architecture  unit-of-work  repository-pattern 

ดังนั้นสถานการณ์ที่ฉันพบเจอบ่อยพอสมควรคือสถานการณ์ที่แบบจำลองของฉันเริ่มต้นด้วย: เติบโตเป็นสัตว์ประหลาดด้วยวิธีตันและตัน หรือ อนุญาตให้คุณส่งชิ้นส่วนของ SQL ไปยังพวกเขาเพื่อให้พวกเขามีความยืดหยุ่นเพียงพอที่จะไม่ต้องใช้วิธีการที่แตกต่างกันนับล้าน ตัวอย่างเช่นสมมติว่าเรามีโมเดล "วิดเจ็ต" เราเริ่มต้นด้วยวิธีการพื้นฐานบางอย่าง: ได้รับ ($ ID) แทรก ($ บันทึก) อัปเดต ($ id, $ บันทึก) ลบ ($ ID) getList () // รับรายการวิดเจ็ต ทั้งหมดนี้เป็นเรื่องที่ดีและสวยงาม แต่จากนั้นเราต้องการรายงาน รายการสร้างระหว่าง ($ start_date, $ end_date) รายการซื้อระหว่าง ($ start_date, $ end_date) listOfPending () จากนั้นการรายงานเริ่มซับซ้อนขึ้น: listPendingCreatedBetween ($ start_date, $ end_date) listForCustomer ($ CUSTOMER_ID) …

17 design-patterns  mvc