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

คำถามเกี่ยวกับการแก้ปัญหาและการวางแผนแก้ปัญหาผ่านการออกแบบซอฟต์แวร์

6
เปลี่ยนโลกของลูกค้า - เราจะจัดการสิ่งนี้ได้อย่างไร
เมื่อไม่นานมานี้เราได้รับมอบหมายให้โครงการเข้ามาแทนที่ระบบเมนเฟรมเก่าของลูกค้าด้วยโซลูชัน ASP.NET อินทราเน็ตใหม่โดยใช้ SQL Server เป็นส่วนหลัง ส่วนหนึ่งของสิ่งนี้คือการปรับโครงสร้างของธุรกิจเช่นกัน - โดยพื้นฐานแล้วเมื่อเราเปลี่ยนระบบเราต้องคิดว่าเราจะทำธุรกิจได้ดีขึ้นอย่างไร ดังนั้นงานแรกคือการเข้ามาและทำแบบจำลองทางตรรกะและข้อมูลทางกายภาพ ลูกค้าอยู่ใน dicussions เหล่านี้และได้ลงชื่อออกอย่างสมบูรณ์ ขั้นตอนต่อไปคือการออกแบบและสร้างของแต่ละโมดูล เพื่อให้เนื้อเรื่องสั้นสั้นการเขียนโปรแกรมก็เสร็จสิ้นและตอนนี้เรากำลังทำการทดสอบระบบแบบขนาน สิ่งที่กำลังจะยอดเยี่ยมสำหรับส่วนใหญ่ของโมดูลจนถึง - ยกเว้นหนึ่ง เรามีระบบเดียวที่ - หากคุณต้องการให้ผู้ใช้ทางธุรกิจเห็นแอปพลิเคชันและรายงานทั้งหมดจะดี ทำงานร่วมกับเวิร์กโฟลว์แบบรวมใหม่และดำเนินกระบวนการแบบแมนนวลโดยอัตโนมัติก่อนหน้านี้และทำงานได้อย่างยอดเยี่ยมตามข้อกำหนด การทดสอบแบบขนานได้เปิดเผยปัญหาบางอย่างด้วยข้อมูลการย้ายข้อมูลแบบเดิม ผู้สร้างระบบเดิมกำลังทำความเข้าใจกับ schema และกระบวนการทางธุรกิจใหม่อย่างหนักดังนั้นพวกเขาจึงมีเวลาที่ยากลำบากมากในการทำความเข้าใจวิธีการใช้ข้อมูลดั้งเดิมและนำมาไว้ในสคีมาใหม่ ด้วยเหตุนี้พวกเขาจึงเรียกประชุมผู้ใช้ทางธุรกิจและผู้มีส่วนได้ส่วนเสียและบอกพวกเขาว่าระบบใหม่ไม่ได้ให้ข้อมูลที่ระบบเก่าทำ (เมื่อเป็นจริง) - ทำให้ระบบใหม่ดูไม่ดี นี่มันน่าหงุดหงิดที่จะพูดน้อยที่สุด ระบบใหม่ใช้งานได้ดีและให้ทุกสิ่งที่พวกเขาต้องการและต้องการและหากไม่ใช่เพราะเจ้าหน้าที่ไอทีไม่สามารถกรอกข้อมูลลงในตารางใหม่ด้วยข้อมูลเก่าผู้ใช้ทางธุรกิจจะพึงพอใจกับคุณสมบัติและฟังก์ชั่นใหม่ ฉันขอคำแนะนำเกี่ยวกับวิธีจัดการกับสิ่งนี้ เนื่องจากการเคลื่อนไหวทางการเมืองบางอย่าง "สถาปนิก" ใหม่จึงไม่ทราบว่าระบบทำงานอย่างไรและไม่สามารถเข้าใจถึงการเปลี่ยนแปลงที่เจ้าหน้าที่ไอทีร้องขอได้อย่างเต็มที่ เจ้าหน้าที่ไอทีต้องการเปลี่ยนแปลงระบบพื้นฐานซึ่งไม่จำเป็นโดยพื้นฐานและเป็นการออกแบบที่ไม่ดี แต่เป็นลูกค้า ความคิดใด ๆ

2
ประเภทข้อมูลความรับผิดชอบเดี่ยวและกำหนดเอง
ในช่วงหลายเดือนที่ผ่านมาฉันขอคนที่นี่ทางทิศตะวันออกเฉียงใต้และในเว็บไซต์อื่น ๆ เสนอคำวิจารณ์ที่สร้างสรรค์เกี่ยวกับรหัสของฉัน มีสิ่งหนึ่งที่โผล่ออกมาเกือบทุกครั้งและฉันก็ยังไม่เห็นด้วยกับคำแนะนำนั้น : P ฉันต้องการที่จะพูดคุยที่นี่และบางทีสิ่งต่าง ๆ จะชัดเจนสำหรับฉัน มันเกี่ยวกับหลักการความรับผิดชอบเดี่ยว (SRP) โดยทั่วไปฉันมีคลาสข้อมูลFontที่ไม่เพียง แต่มีฟังก์ชั่นสำหรับจัดการข้อมูล แต่ยังสำหรับการโหลด ฉันบอกว่าทั้งสองควรแยกจากกันฟังก์ชั่นการโหลดควรอยู่ในคลาสของโรงงาน ฉันคิดว่านี่เป็นความผิดพลาดของ SRP ... ชิ้นส่วนจากคลาสแบบอักษรของฉัน class Font { public: bool isLoaded() const; void loadFromFile(const std::string& file); void loadFromMemory(const void* buffer, std::size_t size); void free(); void some(); void another(); }; การออกแบบที่แนะนำ class Font { public: void some(); …

7
ความสามารถในการนำกลับมาใช้ใหม่มีความหมายเหมือนกันกับการออกแบบที่ดีหรือไม่?
สามารถนำมาใช้เป็นคุณลักษณะของดีออกแบบซอฟต์แวร์ ความสามารถนำกลับมาใช้ใหม่เป็นเงาที่ยอมรับได้("สัญกรณ์สั้น ๆ ของความหมาย") สำหรับการออกแบบซอฟต์แวร์ที่ดีหรือไม่? ทำไม?

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

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

3
คุณพิชิตความท้าทายในการออกแบบอสังหาริมทรัพย์หน้าจอขนาดใหญ่ได้อย่างไร [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว คำถามนี้เป็นเรื่องส่วนตัวมากขึ้น แต่ฉันหวังว่าจะได้มุมมองใหม่ ฉันคุ้นเคยกับการออกแบบสำหรับขนาดหน้าจอที่แน่นอน (ปกติแล้วคือ 1024x768) ซึ่งฉันพบว่าขนาดนั้นไม่เป็นปัญหา การขยายขนาดเป็น 1280x1024 ไม่ได้ช่วยให้คุณซื้ออสังหาริมทรัพย์ที่เพียงพอเพื่อสร้างความแตกต่างที่น่าพึงพอใจ แต่จะทำให้ฉันมีห้องหายใจเพิ่มขึ้นอีกเล็กน้อย โดยพื้นฐานแล้วฉันเพิ่งขยาย "ขนาดกริด" ของฉันและการออกแบบขั้นพื้นฐานเดียวกันสำหรับหน้าจอขนาดเล็กกว่ายังคงใช้งานได้ อย่างไรก็ตามในสองสามโครงการสุดท้ายลูกค้าของฉันทั้งหมดใช้จอ 1080p (1920x1080) และพวกเขาต้องการโซลูชันที่ใช้อสังหาริมทรัพย์มากที่สุดเท่าที่จะทำได้ ความกว้างของพิกเซลที่ 1920 มีเพียงสองเท่าของความกว้างที่ฉันเคยใช้และหน้าจอกว้างทำให้บางส่วนของเก่าของฉันไปที่วิธีการออกแบบไม่ทำงานเช่นกัน ปัญหาที่ฉันพบคือเมื่อนำเสนอด้วยพื้นที่มากฉันต้องเผชิญกับปัญหาที่สำคัญบางอย่าง ฉันควรใช้คอลัมน์กี่คอลัมน์ รูปแบบแบบกว้างให้ตัวเองแยกคอลัมน์ 3 โดยแยก 2: 1: 1 (เช่นคอลัมน์เนื้อหาที่ใหญ่กว่าอีกสองคอลัมน์) อย่างไรก็ตามถ้าฉันไปกับสามคอลัมน์ฉันจะทำอย่างไรกับคอลัมน์พิเศษนั้น ฉันจะใช้งานอสังหาริมทรัพย์อย่างมีประสิทธิภาพได้อย่างไร มีสิ่งล่อใจที่จะทำให้ทุกอย่างบนหน้าจอพร้อมกัน แต่ข้อมูลที่มากเกินไปทำให้แอปพลิเคชันใช้งานได้ยากขึ้น พื้นที่สีขาวเป็นสิ่งสำคัญที่จะช่วยให้เข้าใจข้อมูลที่ซับซ้อน แต่มากเกินไปทำให้แนวคิดที่เกี่ยวข้องดูแยกออก ฉันมักจะทำงานกับเว็บแอปพลิเคชันที่มีข้อมูลที่ซับซ้อนและการสร้างภาพและการนำเสนอเป็นกุญแจสำคัญในการทำความเข้าใจกับข้อมูลดิบ เมื่อผู้ใช้ของคุณมีหน้าจอขนาดใหญ่ (อย่างน้อย 24 ") ข้อมูลบางอย่างไม่อยู่ในสายตาและคุณจำเป็นต้องเลื่อนตัวชี้ในระยะทางไกลคุณจะแน่ใจได้อย่างไรว่าทุกสิ่งที่ต้องการอยู่ในจุดที่มองเห็นได้ เว็บไซต์อย่างง่ายเช่นบล็อกนั้นทำได้ดีกว่าเมื่อความกว้างถูก จำกัด …
10 design  gui  usability 

3
คำแนะนำเกี่ยวกับการรวม DI / IoC container เข้ากับแอพพลิเคชั่นที่มีอยู่
ตอนนี้ฉันกำลังเผชิญหน้ากับการรวมตู้คอนเทนเนอร์ควบคุม (IoC) เข้ากับแอปพลิเคชั่นที่มีอยู่และฉันกำลังมองหาคำแนะนำเกี่ยวกับวิธีที่สามารถทำได้โดยง่ายที่สุดด้วยเป้าหมายสูงสุดของการลดคัปปลิ้ง แม้ว่าโดยทั่วไปแล้วฉันจะไม่จัดชั้นเรียนส่วนใหญ่เป็นวัตถุเทพเจ้าแต่ก็มีความรับผิดชอบมากเกินไปและการพึ่งพาที่ซ่อนอยู่ผ่านสถิตยศาสตร์ซิงเกิลและการขาดการเชื่อมต่อ นี่คือพื้นหลังเล็กน้อยของความท้าทายที่ต้องเผชิญ: การฉีดขึ้นอยู่กับการใช้งานไม่บ่อยนัก วิธีการคงที่มากมาย - ทั้งเป็นวิธีโรงงานและผู้ช่วย ซิงเกิลนั้นค่อนข้างแพร่หลาย อินเทอร์เฟซเมื่อใช้งานจะไม่ละเอียดเกินไป วัตถุมักดึงการอ้างอิงที่ไม่จำเป็นผ่านคลาสพื้นฐาน ความตั้งใจของเราคือในครั้งต่อไปที่เราจำเป็นต้องทำการเปลี่ยนแปลงในพื้นที่เฉพาะที่เราพยายามที่จะหยอกล้อการพึ่งพาซึ่งในความเป็นจริงมีอยู่จริง แต่ถูกซ่อนอยู่หลังกลมเช่นเดี่ยวและสถิต ฉันคิดว่านั่นจะทำให้ IoC container เป็นรองสำหรับการแนะนำการฉีดพึ่งพา แต่ฉันคาดหวังว่าจะมีชุดของการปฏิบัติและคำแนะนำที่สามารถติดตามหรือพิจารณาซึ่งจะช่วยให้เราแยกการพึ่งพาเหล่านี้ออก

4
การกระจายข้อมูลข้ามขอบเขตวัตถุ
หลายครั้งที่วัตถุธุรกิจของฉันมักจะมีสถานการณ์ที่ข้อมูลจำเป็นต้องข้ามขอบเขตวัตถุบ่อยเกินไป เมื่อทำ OO เราต้องการให้ข้อมูลอยู่ในวัตถุเดียวและมากที่สุดเท่าที่เป็นไปได้รหัสทั้งหมดที่เกี่ยวข้องกับข้อมูลนั้นควรอยู่ในวัตถุนั้น อย่างไรก็ตามกฎเกณฑ์ทางธุรกิจไม่ได้ปฏิบัติตามหลักการนี้ทำให้ฉันมีปัญหา ตัวอย่างเช่นสมมติว่าเรามีคำสั่งซื้อที่มีหมายเลขของ OrderItems ซึ่งอ้างถึง InventoryItem ซึ่งมีราคา ฉันเรียกใช้ Order.GetTotal () ซึ่งสรุปผลของ OrderItem.GetPrice () ที่ทวีคูณปริมาณโดย InventoryItem.GetPrice () จนถึงตอนนี้ดีมาก แต่จากนั้นเราพบว่าบางรายการมีการขายสองรายการต่อการจัดการหนึ่งรายการ เราสามารถจัดการสิ่งนี้ได้โดยให้ OrderItem.GetPrice () ทำบางอย่างเช่น InventoryItem.GetPrice (ปริมาณ) และปล่อยให้ InventoryItem จัดการกับสิ่งนี้ อย่างไรก็ตามเราพบว่าดีลแบบสองต่อหนึ่งนั้นมีระยะเวลาที่ จำกัด เท่านั้น ช่วงเวลานี้จะต้องเป็นไปตามวันที่สั่งซื้อ ตอนนี้เราเปลี่ยน OrderItem.GetPrice () เป็น InventoryItem.GetPrice (quatity, order.GetDate ()) แต่เราต้องสนับสนุนราคาที่แตกต่างกันขึ้นอยู่กับระยะเวลาที่ลูกค้าอยู่ในระบบ: InventoryItem.GetPrice (ปริมาณ, คำสั่งซื้อ GetDate (), คำสั่งซื้อ GetCustomer …

7
การสร้างต้นแบบเป็นเรื่องธรรมดาในระยะแรกของการพัฒนาอย่างไร
ฉันเคยเรียนหลักสูตรการออกแบบซอฟต์แวร์มาบ้างในช่วงสองสามภาคการศึกษาที่ผ่านมาและในขณะที่ฉันเห็นประโยชน์ของการทำพิธีการมากมายฉันรู้สึกว่ามันไม่ได้บอกอะไรเกี่ยวกับโปรแกรมเอง: คุณไม่สามารถบอกได้ว่าโปรแกรมจะทำงานอย่างไรจาก Use Case spec แม้ว่าจะกล่าวถึงสิ่งที่โปรแกรมสามารถทำได้ คุณไม่สามารถบอกอะไรเกี่ยวกับประสบการณ์การใช้งานของผู้ใช้จากเอกสารข้อกำหนดแม้ว่ามันจะรวมถึงข้อกำหนดด้านคุณภาพ ลำดับไดอะแกรมเป็นคำอธิบายที่ดีว่าซอฟต์แวร์ทำงานเป็น call stack อย่างไร แต่มีข้อ จำกัด มากและให้มุมมองบางส่วนของระบบโดยรวม คลาสไดอะแกรมเหมาะอย่างยิ่งสำหรับการอธิบายวิธีการสร้างระบบ แต่ไร้ประโยชน์อย่างเต็มที่ในการช่วยให้คุณทราบว่าซอฟต์แวร์จำเป็นต้องมีอะไรบ้าง ซึ่งในพิธีการทั้งหมดนี้คือสิ่งที่สำคัญที่สุด: โปรแกรมมีลักษณะอย่างไรดำเนินการและมีประสบการณ์อย่างไร มันไม่สมเหตุสมผลเลยหรือที่จะออกแบบจากนั้น? มันจะดีกว่าหรือไม่ที่จะเข้าใจว่าโปรแกรมควรทำงานผ่านต้นแบบและพยายามนำไปใช้จริงหรือไม่? ฉันรู้ว่าฉันอาจเป็นทุกข์จากการสอนวิศวกรรมโดยนักทฤษฎี แต่ฉันต้องถามพวกเขาทำสิ่งนี้ในอุตสาหกรรมหรือไม่ ผู้คนจะทราบได้อย่างไรว่าโปรแกรมคืออะไรไม่ใช่สิ่งที่ควรจะเป็น ผู้คนต้นแบบมากหรือพวกเขาส่วนใหญ่ใช้เครื่องมือทางการเช่น UML และฉันก็ยังไม่ได้ใช้

1
SQLite จะมีประโยชน์น้อยลงหรือไม่หากไม่ยอมรับการแทรกค่าที่ไม่ใช่ตัวเลขลงในคอลัมน์ตัวเลข
ใน SQLite คำสั่งต่อไปนี้จะประสบความสำเร็จและสตริงจะถูกแทรก / ปรับปรุงลงในSALARYคอลัมน์ซึ่งเป็นประเภทINTEGER: update employee set salary='TOO MUCH' where emp_id=1; โปรดทราบว่าศูนย์จะไม่ถูกแทรก / อัปเดต แต่เป็นสตริง"TOO MUCH" ที่แท้จริงดังนั้นนี่จึงไม่เกี่ยวกับการแปลงประเภทอัตโนมัติ สถานะคำถามที่พบบ่อย: นี่คือคุณสมบัติไม่ใช่ข้อผิดพลาด SQLite ใช้การพิมพ์แบบไดนามิก มันไม่บังคับใช้ข้อ จำกัด ชนิดข้อมูล สามารถแทรกข้อมูลประเภทใดก็ได้ (โดยปกติ) ลงในคอลัมน์ใดก็ได้ คุณสามารถใส่สตริงความยาวโดยพลการลงในคอลัมน์จำนวนเต็มจำนวนจุดลอยตัวในคอลัมน์บูลีนหรือวันที่ในคอลัมน์อักขระ ประเภทข้อมูลที่คุณกำหนดให้กับคอลัมน์ในคำสั่ง CREATE TABLE ไม่ได้ จำกัด ข้อมูลที่สามารถใส่ลงในคอลัมน์นั้นได้ ทุกคอลัมน์สามารถเก็บสตริงความยาวได้ตามใจชอบ (มีข้อยกเว้นหนึ่งประการ: คอลัมน์ประเภท INTEGER Primary KEY อาจเก็บไว้เป็นจำนวนเต็มแบบ 64 บิตเท่านั้นข้อผิดพลาดจะเกิดขึ้นหากคุณพยายามใส่สิ่งอื่นที่ไม่ใช่จำนวนเต็มลงในคอลัมน์ INTEGER Primary KEY) ดังนั้นพฤติกรรมนี้มีเจตนาชัดเจน แต่ฉันสงสัยว่าทำไม SQLite …
10 design  sqlite 

2
ส่วนหน้าเขียนด้วยภาษาที่ใช้สำหรับแบ็กเอนด์! [ปิด]
ปิด คำถามนี้ต้องการรายละเอียดหรือความคมชัด ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ เพิ่มรายละเอียดและชี้แจงปัญหาโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา จากประสบการณ์ของฉันในการพัฒนาเว็บไซต์ฉันรู้ว่ามีการใช้ภาษาอย่าง PHP, Java, Python..etc สำหรับการพัฒนาแบ็กเอนด์ (ซอฟต์แวร์ที่ทำงานบนเซิร์ฟเวอร์) และสำหรับภาษาส่วนหน้าใช้ JS / HTML / CSS แต่ฉันเห็นหลาย บริษัท บอกว่าพวกเขาใช้เช่น PHP สำหรับการพัฒนาส่วนหน้าและไพ ธ อนสำหรับแบ็คเอนด์ นั่นหมายความว่า PHP เป็นส่วนหน้าสำหรับการเรียกบริการอื่น ๆ ที่เขียนเป็นภาษาอื่น ๆ ผ่าน REST, RPC .. เป็นต้น?

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

2
การออกแบบ Domain Driven ที่เทียบเท่ากับภาษาโปรแกรมที่ใช้งานได้
ฉันชอบความคิดเกี่ยวกับการออกแบบที่ขับเคลื่อนด้วยโดเมน แต่ในขณะที่ฉันกำลังเรียนรู้ Go ฉันสงสัยว่ามี DDD ที่เทียบเท่ากับภาษาที่มีประสิทธิภาพมากกว่าหรือไม่

2
ฉันควรแคชข้อมูลหรือกดฐานข้อมูลหรือไม่
ฉันไม่ได้ทำงานกับกลไกการแคชใด ๆ และสงสัยว่าตัวเลือกของฉันคืออะไรในโลก. net สำหรับสถานการณ์ต่อไปนี้ โดยทั่วไปเรามีบริการ REST ซึ่งผู้ใช้ผ่าน ID ของหมวดหมู่ (think folder) และหมวดหมู่นี้อาจมีหมวดหมู่ย่อยมากมายและแต่ละหมวดย่อยอาจมี 1,000 คอนเทนเนอร์สื่อ (คิดว่าวัตถุอ้างอิงไฟล์) ซึ่งมีข้อมูลเกี่ยวกับ ไฟล์ที่อาจอยู่บนเซิร์ฟเวอร์ NAS หรือ SAN (ไฟล์เป็นวิดีโอในกรณีนี้) ความสัมพันธ์ระหว่างหมวดหมู่เหล่านี้ถูกเก็บไว้ในฐานข้อมูลพร้อมกับกฎการอนุญาตและข้อมูลเมตาเกี่ยวกับหมวดย่อย ดังนั้นจากมุมมอง UI เรามีตัวควบคุมทรีโหลดที่ขี้เกียจซึ่งขับเคลื่อนโดยผู้ใช้โดยคลิกที่โฟลเดอร์ย่อยแต่ละโฟลเดอร์ (คิดว่าเป็น Windows explorer) เมื่อพวกเขามาที่ URL ของไฟล์วิดีโอพวกเขาจะสามารถดูวิดีโอได้ จำนวนผู้ใช้สามารถเติบโตเป็น 1000 และหมวดหมู่ย่อยและวิดีโออาจอยู่ในช่วง 10,000 เมื่อระบบเติบโต คำถามคือเราควรดำเนินการตามที่มันทำงานอยู่ในขณะที่แต่ละคำขอกระทบฐานข้อมูลหรือเราควรคิดถึงการแคชข้อมูลหรือไม่ เรากำลังใช้ IIS 6/7 และ Asp.net

5
OOP: อะไรคือสถานการณ์บางอย่างที่การออกแบบโดยใช้คลาสดีกว่าอินเตอร์เฟสที่ใช้
ผมอ่าน เว็บไซต์ของ JDOM ทำไม JDOM API จึงถูกกำหนดในรูปแบบของคลาสที่เป็นรูปธรรมมากกว่าส่วนต่อประสาน? Jason Hunter สรุปข้อโต้แย้งกับ API ที่ใช้อินเตอร์เฟสสำหรับ JDOM: ด้วยอินเทอร์เฟซทุกอย่างกลายเป็นโรงงานองค์ประกอบจะต้อง 'นำเข้า' ลงในเอกสารใหม่แทนที่จะเพิ่มเพียงอย่างเดียวจึงไม่สามารถรับประกันคุณสมบัติเช่นการทำให้เป็นอนุกรมในระยะยาวและรายการจะดำเนินต่อไป เราเริ่มต้นด้วยอินเตอร์เฟสจริง ๆ แล้ว ในระหว่างการตรวจสอบก่อนเผยแพร่ของเรากับเพื่อนบางคนเราได้รับข้อเสนอแนะเราควรลองคลาสที่เป็นรูปธรรม เราทำและการออกแบบก็ดีกว่ามาก ฉันเป็นนักออกแบบมือใหม่ คำแนะนำทั้งหมดที่ฉันเคยได้ยินจนถึงขณะนี้คือการต่อต้านการใช้การออกแบบด้วยชั้นเรียนที่เป็นรูปธรรม อาจจะใช้คลาสคอนกรีตที่เหมาะสมในบางสถานที่ มีปัญหาของคลาสทั่วไปที่ใช้คลาสคอนกรีตในการออกแบบไม่เป็นไร

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