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

ตัวอย่างเช่น: var duckBehaviors = new Duckbehavior(); duckBehaviors.quackBehavior = new Quack(); duckBehaviors.flyBehavior = new FlyWithWings(); Duck mallardDuck = new Duck(DuckTypes.MallardDuck, duckBehaviors) เนื่องจากคลาส Duck มีพฤติกรรมทั้งหมด (นามธรรม) การสร้างคลาสใหม่MallardDuck(ซึ่งขยายDuck) จึงไม่จำเป็นต้องมี การอ้างอิง: รูปแบบการออกแบบส่วนหัวแรกบทที่ 1

10 design-patterns  dependency-injection  strategy-pattern 

ฉันมีรหัสต่อไปนี้: public void moveCameraTo(Location location){ moveCameraTo(location.getLatitude(), location.getLongitude()); } public void moveCameraTo(double latitude, double longitude){ LatLng latLng = new LatLng(latitude, longitude); moveCameraTo(latLng); } public void moveCameraTo(LatLng latLng){ GoogleMap googleMap = getGoogleMap(); cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL); googleMap.moveCamera(cameraUpdate); } ฉันคิดว่าด้วยวิธีนี้ฉันกำจัดความรับผิดชอบในการรู้ว่าสิ่งที่อยู่LatLngในชั้นเรียนอื่นเช่น และคุณไม่จำเป็นต้องเตรียมข้อมูลก่อนเรียกฟังก์ชั่น คุณคิดอย่างไร? วิธีนี้มีชื่อหรือไม่? เป็นการฝึกที่ไม่ดีจริง ๆ หรือ?

10 design  design-patterns  clean-code  code-smell  bad-code 

ทุกครั้งที่มีคนมาถึงฉันและขอให้ฉันกำหนด Dependency Injection ตามแนวคิดและอธิบายข้อดีข้อเสียของการใช้ DI ในการออกแบบซอฟต์แวร์ ฉันยอมรับว่าฉันมีปัญหาในการอธิบายแนวคิดของ DI ทุกครั้งที่ฉันต้องบอกพวกเขาเกี่ยวกับประวัติศาสตร์เกี่ยวกับหลักการความรับผิดชอบเดียวองค์ประกอบการสืบทอด ฯลฯ ใครสามารถช่วยฉันอธิบายวิธีที่ดีที่สุดในการอธิบาย DI สำหรับนักพัฒนา

10 design  design-patterns  software 

ฉันได้ยินวลีที่ถูกโยนและฉันมีข้อโต้แย้งที่ฟังดูบ้าอย่างสมบูรณ์ (ขออภัยถ้าฉันกำลังทำฟางอยู่ที่นี่ไม่ใช่ความตั้งใจของฉัน) โดยทั่วไปจะมีบางอย่างตาม: คุณไม่ต้องการสร้างสิ่งที่เป็นนามธรรมก่อนที่คุณจะรู้ว่ากรณีทั่วไปคืออะไรมิฉะนั้น (1) คุณอาจวางสิ่งต่าง ๆ ในสิ่งที่เป็นนามธรรมของคุณหรือ (2) ไม่สนใจสิ่งที่มีความสำคัญ (1) สำหรับฉันนี่ดูเหมือนว่าโปรแกรมเมอร์ไม่ได้ใช้งานได้จริงพวกเขาได้ตั้งสมมติฐานว่าสิ่งต่าง ๆ จะมีอยู่ในโปรแกรมสุดท้ายที่ไม่ได้ทำงานดังนั้นพวกเขาจึงทำงานร่วมกับสิ่งที่เป็นนามธรรมในระดับต่ำปัญหาไม่ใช่ สิ่งที่เป็นนามธรรมก่อนวัยอันควร (2) การทิ้งสิ่งที่มีความสำคัญเป็นสิ่งหนึ่งอาจเป็นไปได้อย่างสิ้นเชิงที่บางสิ่งจะถูกตัดออกจากข้อมูลจำเพาะที่ในภายหลังกลายเป็นเรื่องสำคัญทางออกสำหรับสิ่งนี้ไม่ได้เกิดขึ้นกับการตัดสินใจของคุณและทรัพยากรเสียเปล่า เดาผิดก็เพื่อให้ได้ข้อมูลเพิ่มเติมจากลูกค้า เราควรทำงานจากนามธรรมลงไปถึงข้อตกลงเพราะนี่เป็นวิธีที่จริงจังที่สุดในการทำสิ่งต่าง ๆ และไม่ใช่วิธีอื่น ๆ ถ้าเราไม่ทำเช่นนั้นเราก็เสี่ยงต่อการเข้าใจผิดของลูกค้าและการสร้างสิ่งต่าง ๆ ที่จำเป็นต้องเปลี่ยน แต่ถ้าเราสร้างเพียงนามธรรมที่ลูกค้าได้กำหนดไว้ในภาษาของพวกเขาเองเราก็ไม่เคยตกอยู่ในความเสี่ยงนี้ ภาพหนึ่งในที่มืดโดยมีการสรุปบางอย่าง) ใช่เป็นไปได้ที่ลูกค้าจะเปลี่ยนใจเกี่ยวกับรายละเอียด แต่สิ่งที่พวกเขาเคยใช้ในการสื่อสารสิ่งที่พวกเขาต้องการมักจะยังคงใช้ได้ ต่อไปนี้เป็นตัวอย่างสมมติว่าลูกค้าต้องการให้คุณสร้างหุ่นยนต์ที่บรรจุถุง: public abstract class BaggingRobot() { private Collection<Item> items; public abstract void bag(Item item); } เรากำลังสร้างบางสิ่งจากนามธรรมที่ลูกค้าใช้โดยไม่ต้องลงรายละเอียดเพิ่มเติมกับสิ่งที่เราไม่รู้ นี่คือความยืดหยุ่นอย่างยิ่งฉันเห็นสิ่งนี้ถูกเรียกว่า "นามธรรมก่อนวัยอันควร" เมื่อในความเป็นจริงมันจะเร็วกว่าที่จะคิดว่าวิธีการบรรจุถุงถูกนำไปใช้อย่างไรพูดหลังจากพูดคุยกับลูกค้าที่พวกเขาต้องการ . เพื่ออัปเดตชั้นเรียนของฉันทั้งหมดที่ฉันต้องทำคือเปลี่ยนลายเซ็น …

10 design  design-patterns  object-oriented-design  development-process  abstraction 

ฉันต้องการสร้างระบบที่จัดการข้อความแจ้งเตือนจากโปรแกรมต่าง ๆ และสามารถประมวลผลการแจ้งเตือนเหล่านั้นไปยังผู้บริโภคที่ไม่ต้องการทางอีเมล ทั้งหมดนี้จะถูกเก็บไว้ในเครือข่ายภายในหนึ่งเครือข่าย ฉันคิดว่าฉันต้องการสถาปัตยกรรมพื้นฐานที่มีลักษณะเช่นนี้: ข้อกังวลหลักที่ฉันมีอยู่ในปัจจุบันคือบิต "ตัวจัดการข้อความ" ซึ่งเป็นสิ่งที่จะเป็น "sort-of-API" ของฉัน ฉันต้องการส่วนประกอบทั้งหมดของระบบนี้เพื่อส่งข้อมูลไปยัง API ซึ่งจัดการการเขียนทั้งหมดไปยังฐานข้อมูล ฉันคิดว่าวิธีนี้ง่ายกว่าเพราะมันช่วยลดความปลอดภัยและช่วยให้ฉันมีการสืบค้น DB ที่ซับซ้อนมากขึ้นในโปรแกรมเดียว ข้อกังวลคือฉันต้องการให้สิ่งนี้เป็นผู้ไม่เชื่อเรื่องภาษา - หมายความว่ารหัสใด ๆ ควรจะสามารถส่งข้อความไปยังตัวจัดการของฉัน - ซึ่งจะตีความพวกเขา ฉันหวังว่าจะทำสิ่งนี้ผ่านไฟล์แบน JSON - หรือผ่านการเรียกใช้ REST ไปยังโปรแกรม (ให้ความยืดหยุ่นกับแอพพลิเคชั่นดาวน์สตรีม) คำถามของฉันคือ - ฉันควรรบกวนตัวจัดการข้อความหรือไม่หรือจะเพิ่มความเรียบง่ายให้อนุญาตการเข้าถึงฐานข้อมูลโดยตรงไปยังแอพพลิเคชั่นดาวน์สตรีมรวมถึงส่วนประกอบอื่น ๆ สองตัว (Management Console และ Alert Manager) ด้วยวิธีนี้พวกเขาสามารถแทรกการแจ้งเตือนใดก็ได้ที่พวกเขาต้องการ - ตราบใดที่ INSERT ในตาราง DB / s นั้นถูกต้อง ฉันไม่ได้เป็นนักออกแบบซอฟต์แวร์โดยการค้าขอตัวฉัน …

10 design  design-patterns  architecture  api  api-design 

อาจจะเหมือนหลาย ๆ คนฉันมักพบว่าตัวเองปวดหัวกับปัญหาการออกแบบซึ่งตัวอย่างเช่นมีรูปแบบการออกแบบ / วิธีการบางอย่างที่ดูเหมือนจะเหมาะกับปัญหาและมีประโยชน์ตามที่ต้องการ บ่อยครั้งที่มีข้อแม้บางอย่างซึ่งทำให้เป็นการยากที่จะใช้รูปแบบ / วิธีการโดยไม่ต้องทำงานใด ๆ ซึ่งจะส่งผลเสียต่อรูปแบบ / วิธีการ ฉันสามารถจบการวนซ้ำได้ง่ายในหลายรูปแบบ / วิธีการเพราะสามารถคาดเดาได้ว่าเกือบทั้งหมดมีข้อแม้ที่สำคัญมากในสถานการณ์จริงซึ่งไม่มีวิธีแก้ปัญหาที่ง่าย ตัวอย่าง: ฉันจะให้คุณตัวอย่างตามสมมุติบนพื้นฐานของจริงฉันเพิ่งพบ สมมติว่าฉันต้องการใช้การเรียงซ้อนมากกว่าการสืบทอดเนื่องจากลำดับชั้นการสืบทอดได้ขัดขวางความสามารถในการปรับขนาดของรหัสในอดีต ฉันอาจ refactor รหัส แต่แล้วพบว่ามีบริบทบางอย่างที่ superclass / baseclass เพียงต้องการเรียกฟังก์ชันการทำงานใน subclass แม้จะพยายามหลีกเลี่ยง วิธีที่ดีที่สุดถัดไปดูเหมือนว่าจะใช้รูปแบบผู้แทน / ผู้สังเกตการณ์ครึ่งและรูปแบบองค์ประกอบครึ่งเพื่อให้ซูเปอร์คลาสสามารถมอบหมายพฤติกรรมหรือเพื่อให้คลาสย่อยสามารถสังเกตเห็นเหตุการณ์ซูเปอร์คลาส จากนั้นชั้นเรียนจะสามารถปรับขนาดได้และบำรุงรักษาน้อยลงเพราะมันไม่ชัดเจนว่าควรจะขยายเวลาออกไปอย่างไรนอกจากนี้ยังเป็นการยากที่จะขยายผู้ฟัง / ผู้เข้าร่วมประชุมที่มีอยู่ ข้อมูลก็ไม่ได้ถูกซ่อนไว้อย่างดีเพราะใคร ๆ ก็เริ่มต้องการทราบถึงการนำไปปฏิบัติเพื่อดูวิธีการขยายซูเปอร์คลาส (เว้นแต่คุณจะใช้ความคิดเห็นอย่างกว้างขวาง) ดังนั้นหลังจากนี้ฉันอาจเลือกที่จะเพียงแค่ใช้ผู้สังเกตการณ์หรือผู้ได้รับมอบหมายอย่างสมบูรณ์เพื่อหลีกเลี่ยงข้อเสียที่มาพร้อมกับการผสมผสานวิธีการต่างๆ อย่างไรก็ตามสิ่งนี้มาพร้อมกับปัญหาของตัวเอง ตัวอย่างเช่นฉันอาจพบว่าฉันต้องมีผู้สังเกตการณ์หรือผู้รับมอบสิทธิ์เพื่อเพิ่มจำนวนพฤติกรรมจนกระทั่งฉันต้องมีผู้สังเกตการณ์ / ผู้ได้รับมอบหมายสำหรับพฤติกรรมทุกอย่าง ทางเลือกหนึ่งอาจจะมีเพียงผู้ฟัง / ผู้รับมอบสิทธิ์ที่ใหญ่สำหรับพฤติกรรมทั้งหมด แต่จากนั้นคลาสที่ใช้งานจะจบลงด้วยวิธีการที่ว่างเปล่ามากมายเป็นต้น จากนั้นฉันอาจลองวิธีอื่น แต่ก็มีปัญหามากมายเช่นกัน จากนั้นคนต่อไปและอีกคนหนึ่งหลังจาก …

10 design  design-patterns  object-oriented  refactoring  clean-code 

ฉันได้อ่านบทความบทความและส่วน 4.1.4 ตอนที่ 4 ของคอมไพเลอร์: หลักการเทคนิคและเครื่องมือ (รุ่นที่ 2) (หรือที่รู้จักกันในชื่อ "The Dragon Book") ซึ่งทุกคนกล่าวถึงหัวข้อการกู้คืนข้อผิดพลาดทางไวยากรณ์ อย่างไรก็ตามหลังจากทดลองกับคอมไพเลอร์สมัยใหม่หลาย ๆ ตัวฉันได้เห็นแล้วว่าพวกเขากู้คืนจากข้อผิดพลาดทางความหมายเช่นเดียวกับข้อผิดพลาดทางไวยากรณ์ ฉันเข้าใจอัลกอริทึมและเทคนิคที่อยู่เบื้องหลังคอมไพเลอร์ที่กู้คืนจากข้อผิดพลาดเกี่ยวกับวากยสัมพันธ์ แต่ฉันไม่เข้าใจว่าคอมไพเลอร์สามารถกู้คืนจากข้อผิดพลาดทางความหมายได้อย่างไร ขณะนี้ฉันกำลังใช้รูปแบบผู้เยี่ยมชมที่แตกต่างกันเล็กน้อยเพื่อสร้างรหัสจากแผนผังไวยากรณ์นามธรรมของฉัน พิจารณาคอมไพเลอร์ของฉันรวบรวมการแสดงออกต่อไปนี้: 1 / (2 * (3 + "4")) คอมไพเลอร์จะสร้างแผนผังไวยากรณ์นามธรรมต่อไปนี้: op(/) | ------- / \ int(1) op(*) | ------- / \ int(2) op(+) | ------- / \ int(3) str(4) ขั้นตอนการสร้างรหัสจะใช้รูปแบบผู้เยี่ยมชมเพื่อสำรวจทรีไวยากรณ์แบบนามธรรมซ้ำ ๆ และดำเนินการตรวจสอบชนิด …

10 design  design-patterns  language-agnostic  type-systems 

ฉันกำลังติดตามคำถามนี้แต่ฉันเปลี่ยนโฟกัสจากโค้ดเป็นหลักการ จากความเข้าใจของฉันเกี่ยวกับหลักการทดแทน Liskov (LSP) ไม่ว่าวิธีการใดที่อยู่ในคลาสพื้นฐานของฉันพวกเขาจะต้องดำเนินการในคลาสย่อยของฉันและตามหน้านี้หากคุณแทนที่วิธีในคลาสพื้นฐานและไม่ทำอะไรเลย คุณกำลังละเมิดหลักการ ตอนนี้ปัญหาของฉันสามารถสรุปได้เช่นนี้ฉันมีนามธรรมWeapon classและสองชั้นและSword ReloadableหากReloadableมีข้อมูลเฉพาะที่methodเรียกว่าReload()ฉันจะต้องลดความเร็วเพื่อเข้าถึงmethodและถ้าคุณต้องการหลีกเลี่ยงปัญหานั้น Strategy Patternจากนั้นผมก็คิดของการใช้ วิธีนี้แต่ละอาวุธเป็นเพียงตระหนักถึงการกระทำที่มีความสามารถในการดำเนินการดังนั้นสำหรับตัวอย่างเช่นReloadableอาวุธอย่างเห็นได้ชัดสามารถโหลด แต่ไม่สามารถและไม่ได้ตระหนักถึงSword Reload class/methodตามที่ระบุไว้ในโพสต์ Stack Overflow ของฉันฉันไม่จำเป็นต้องลดความเร็วและฉันสามารถเก็บList<Weapon>สะสม ในฟอรัมอื่นคำตอบแรกที่แนะนำเพื่อให้SwordระวังReloadเพียงไม่ทำอะไรเลย ได้รับคำตอบเดียวกันนี้ในหน้า Stack Overflow ที่ฉันลิงค์ไปด้านบน ฉันไม่เข้าใจว่าทำไม ทำไมการละเมิดหลักการและอนุญาตให้ Sword ต้องระวังReloadและปล่อยให้มันว่างเปล่า อย่างที่ฉันบอกไว้ในโพสต์ Stack Overflow SP จะแก้ปัญหาของฉันได้ค่อนข้างมาก ทำไมมันไม่เป็นทางออกที่ทำงานได้? public final Weapon{ private final String name; private final int damage; private final List<AttackStrategy> validactions; private final …

10 java  design-patterns  inheritance 

ฉันเป็นผู้พัฒนาเพียงผู้เดียวในโครงการที่อาจมีคนอื่นนำไปใช้ในโครงการต่อไปในอนาคต สมมติว่าฉันใช้รูปแบบ X เพื่อใช้คุณสมบัติ A หลังจากพัฒนาและทำให้คุณลักษณะเสร็จสมบูรณ์ฉันรู้ว่าฉันสามารถใช้คุณสมบัติเดียวกันโดยใช้รูปแบบ Y ซึ่งฉันเพิ่งเรียนรู้มา แต่ฟีเจอร์ A ทำงานได้ดีและการเปลี่ยนจาก X เป็น Y นั้นใช้เวลานานและให้ประโยชน์เล็กน้อย จากนั้นก็ถึงเวลาที่จะใช้งานคุณสมบัติ B มันคล้ายกับ A แต่คราวนี้ฉันต้องการใช้โอกาสนี้เพื่อเล่นกับรูปแบบ Y ฉันมีความสุขกับผลลัพธ์สุดท้ายดีกว่าเมื่อใช้คุณสมบัติ A แต่ตอนนี้โค้ดของฉันใช้สอง รูปแบบที่ต่างกัน, X และ Y, สำหรับคุณสมบัติที่คล้ายกัน แต่ไม่มีเหตุผลที่แท้จริงที่จะใช้รูปแบบที่แตกต่างกันยกเว้นความจริงที่ว่าเมื่อการสร้างฟีเจอร์ AI นั้นไม่ชำนาญพอที่จะใช้รูปแบบเดียวกันกับฟีเจอร์ B โปรดทราบว่าคำถามนี้ไม่ได้เกี่ยวกับการเลือกรูปแบบที่เหมาะสมสำหรับปัญหาที่กำหนด ; มันมีอยู่สองรูปแบบที่อยู่ร่วมกันในฐานของรหัสเพื่อแก้ปัญหาที่คล้ายกันซึ่งสามารถลดลงเหลือเพียงครั้งเดียวเพื่อให้มีการปรับโครงสร้าง รหัสนั้นมีกลิ่นหรือไม่? อะไรคือข้อเสียของการรักษาซอร์สโค้ดเช่นนี้? ฉันควรจะใช้รูปแบบเดียวเท่านั้นหรือไม่ เช่น refactor A เพื่อใช้ Y หรือใช้ X ต่อไปเมื่อเขียน B? ฉันจะสื่อสารได้อย่างไรว่าสาเหตุที่มีสองรูปแบบที่แตกต่างกันสำหรับคุณสมบัติที่คล้ายกันนั้นไม่มีเหตุผล ฉันกังวลมากเกินไปเกี่ยวกับสิ่งที่นักพัฒนาคนต่อไปคิดเกี่ยวกับรหัสของฉันหรือไม่

10 design-patterns  refactoring  documentation 

แก้ไข:ฉันต้องการจะชี้ให้เห็นว่าคำถามนี้อธิบายถึงปัญหาทางทฤษฎีและฉันรู้ว่าฉันสามารถใช้อาร์กิวเมนต์ตัวสร้างสำหรับพารามิเตอร์บังคับหรือส่งข้อยกเว้น runtime ถ้าใช้ API ไม่ถูกต้อง อย่างไรก็ตามฉันกำลังมองหาวิธีแก้ปัญหาที่ไม่ต้องการตัวสร้างอาร์กิวเมนต์หรือการตรวจสอบรันไทม์ ลองนึกภาพคุณมีCarอินเทอร์เฟซเช่นนี้: public interface Car { public Engine getEngine(); // required public Transmission getTransmission(); // required public Stereo getStereo(); // optional } ตามความคิดเห็นที่จะแนะนำCarต้องมีEngineและTransmissionแต่Stereoเป็นตัวเลือก นั่นหมายความว่าสร้างที่สามารถเพียงตัวอย่างที่เคยควรจะมีวิธีการถ้าและมีทั้งรับแล้วมอบให้กับผู้สร้างอินสแตนซ์ ด้วยวิธีการตรวจสอบชนิดจะปฏิเสธที่จะรวบรวมรหัสใด ๆ ที่พยายามที่จะสร้างอินสแตนซ์โดยไม่ต้องหรือbuild()Carbuild()EngineTransmissionCarEngineTransmission สายนี้สำหรับสร้างขั้นตอน โดยทั่วไปแล้วคุณจะใช้สิ่งนี้: public interface Car { public Engine getEngine(); // required public Transmission getTransmission(); // required public Stereo …

10 design-patterns  builder-pattern 

พื้นหลัง ฉันมีโครงการที่ขึ้นอยู่กับการใช้งานของอุปกรณ์ฮาร์ดแวร์บางประเภทในขณะที่มันไม่สำคัญว่าใครจะทำอุปกรณ์ฮาร์ดแวร์นั้นตราบเท่าที่มันเป็นสิ่งที่ฉันต้องทำ จากที่กล่าวมาแม้กระทั่งอุปกรณ์สองชิ้นที่ควรทำในสิ่งเดียวกันจะมีความแตกต่างเมื่อไม่ได้ผลิตโดยผู้ผลิตรายเดียวกัน ดังนั้นฉันจึงคิดว่าจะใช้อินเทอร์เฟซเพื่อแยกแอปพลิเคชันออกจากอุปกรณ์/ รุ่นที่เกี่ยวข้องและมีอินเทอร์เฟซที่ครอบคลุมฟังก์ชั่นระดับสูงสุดแทน นี่คือสิ่งที่ฉันคิดว่าสถาปัตยกรรมของฉันจะมีลักษณะ: กำหนดอินเตอร์เฟซใน C # IDeviceโครงการหนึ่ง มีรูปธรรมในห้องสมุดที่กำหนดไว้ในโครงการ C # อื่นที่จะใช้เพื่อเป็นตัวแทนของอุปกรณ์ มีอุปกรณ์ที่เป็นรูปธรรมใช้IDeviceอินเตอร์เฟซ IDeviceอินเตอร์เฟซที่อาจจะมีวิธีการเช่นหรือGetMeasurementSetRange ทำให้แอปพลิเคชันมีความรู้เกี่ยวกับรูปธรรมและส่งผ่านรูปธรรมไปยังรหัสแอปพลิเคชั่นที่ใช้งาน ( ไม่นำไปใช้ ) IDeviceอุปกรณ์ ฉันค่อนข้างแน่ใจว่านี่เป็นวิธีที่ถูกต้องที่จะไปเกี่ยวกับเรื่องนี้เพราะแล้วฉันจะสามารถเปลี่ยนอุปกรณ์ที่ใช้โดยไม่ส่งผลกระทบต่อแอปพลิเคชัน (ซึ่งดูเหมือนว่าจะเกิดขึ้นบางครั้ง) กล่าวอีกนัยหนึ่งมันไม่สำคัญว่าการใช้งานGetMeasurementหรือSetRangeทำงานผ่านคอนกรีตอย่างแท้จริง (อาจแตกต่างกันระหว่างผู้ผลิตอุปกรณ์) ข้อสงสัยเดียวในใจของฉันคือตอนนี้ทั้งแอปพลิเคชันและคลาสที่เป็นรูปธรรมของอุปกรณ์นั้นขึ้นอยู่กับไลบรารีที่มีIDeviceส่วนต่อประสาน แต่นั่นเป็นสิ่งที่ไม่ดี? ฉันไม่เห็นด้วยว่าแอปพลิเคชันไม่จำเป็นต้องรู้เกี่ยวกับอุปกรณ์ได้อย่างไรนอกจากอุปกรณ์และIDeviceอยู่ในเนมสเปซเดียวกัน คำถาม ดูเหมือนว่าวิธีการที่ถูกต้องสำหรับการใช้อินเทอร์เฟซเพื่อแยกการพึ่งพาระหว่างแอปพลิเคชันของฉันและอุปกรณ์ที่ใช้หรือไม่

10 c#  design-patterns  object-oriented  interfaces  dependency-management 

พิจารณาสถานการณ์ที่คลาสใช้พฤติกรรมพื้นฐานวิธีการและอื่น ๆ แต่คลาสที่แตกต่างกันของคลาสนั้นอาจมีอยู่สำหรับการใช้ที่แตกต่างกัน ในกรณีเฉพาะของฉันฉันมีเวกเตอร์ (เวกเตอร์เรขาคณิตไม่ใช่รายการ) และเวกเตอร์นั้นสามารถใช้ได้กับพื้นที่ยูคลิดมิติ N- มิติใด ๆ (1 มิติ, 2 มิติ, ... ) คลาส / ประเภทนี้สามารถกำหนดได้อย่างไร? นี่จะเป็นเรื่องง่ายใน C ++ ที่เทมเพลตของคลาสสามารถมีค่าจริงเป็นพารามิเตอร์ได้ แต่เราไม่มีความหรูหราใน Java ทั้งสองวิธีที่ฉันสามารถคิดได้ว่าสามารถนำมาใช้เพื่อแก้ปัญหานี้คือ: มีการดำเนินการของแต่ละกรณีที่เป็นไปได้ในเวลารวบรวม public interface Vector { public double magnitude(); } public class Vector1 implements Vector { public final double x; public Vector1(double x) { this.x = …

10 java  design-patterns  code-generation 

ดังนั้นฉันจึงมีโรงงานที่สร้างวัตถุของคลาสที่แตกต่างกัน คลาสที่เป็นไปได้ทั้งหมดมาจากบรรพบุรุษที่เป็นนามธรรม โรงงานมีไฟล์กำหนดค่า (ไวยากรณ์ JSON) และตัดสินใจว่าจะสร้างคลาสใดขึ้นอยู่กับการกำหนดค่าของผู้ใช้ เพื่อให้บรรลุสิ่งนี้โรงงานใช้ boost :: property_tree สำหรับ JSON-parsing เขาเดินผ่านต้นไม้ต้นทรีและตัดสินใจเลือกวัตถุที่เป็นรูปธรรมเพื่อสร้าง อย่างไรก็ตามผลิตภัณฑ์วัตถุมีหลายฟิลด์ (คุณลักษณะ) วัตถุมีคุณสมบัติประมาณ 5-10 ตัวในอนาคตอาจมีมากกว่านี้ขึ้นอยู่กับคลาสที่เป็นรูปธรรม ดังนั้นฉันไม่แน่ใจว่าตัวสร้างของวัตถุควรมีลักษณะอย่างไร ฉันสามารถคิดถึงวิธีแก้ปัญหาสองข้อ: 1) ตัวสร้างของผลิตภัณฑ์คาดว่าทุกแอตทริบิวต์เป็นพารามิเตอร์ดังนั้นตัวสร้างจะลงท้ายด้วยพารามิเตอร์ 10+ สิ่งนี้จะน่าเกลียดและนำไปสู่บรรทัดโค้ดที่ยาวและอ่านไม่ได้ อย่างไรก็ตามข้อดีคือโรงงานสามารถแยกวิเคราะห์ JSON และเรียกใช้ตัวสร้างด้วยพารามิเตอร์ที่ถูกต้อง คลาสผลิตภัณฑ์ไม่จำเป็นต้องรู้ว่าถูกสร้างขึ้นเนื่องจากการกำหนดค่า JSON ไม่จำเป็นต้องรู้ว่ามี JSON หรือการกำหนดค่าที่เกี่ยวข้องเลย 2) คอนสตรัคเตอร์ของผลิตภัณฑ์คาดว่าจะมีอาร์กิวเมนต์เดียวคือออบเจ็กต์ property_tree จากนั้นมันก็สามารถแยกวิเคราะห์ข้อมูลที่จำเป็น หากข้อมูลในการกำหนดค่าขาดหายไปหรือไม่อยู่ในขอบเขตของแต่ละคลาสผลิตภัณฑ์สามารถตอบสนองได้อย่างถูกต้อง โรงงานไม่จำเป็นต้องทราบว่าผลิตภัณฑ์หลายตัวต้องการข้อโต้แย้งใด โรงงานยังไม่จำเป็นต้องรู้วิธีการตอบสนองในกรณีที่มีการกำหนดค่าผิดพลาด และอินเทอร์เฟซตัวสร้างเป็นปึกแผ่นและเล็ก แต่ในฐานะที่เป็นข้อเสียผลิตภัณฑ์จำเป็นต้องดึงข้อมูลที่ต้องการจาก JSON ดังนั้นจึงรู้ได้ว่ามันถูกสร้างขึ้นอย่างไร ฉันมักจะชอบโซลูชัน 2) อย่างไรก็ตามฉันไม่แน่ใจว่านี่เป็นรูปแบบโรงงานที่ดีหรือไม่ รู้สึกผิดอย่างใดอย่างหนึ่งที่ทำให้ผลิตภัณฑ์ทราบว่าสร้างขึ้นด้วยการกำหนดค่า JSON ในอีกด้านหนึ่งผลิตภัณฑ์ใหม่สามารถแนะนำง่ายมาก ความคิดเห็นใด …

10 design-patterns  object-oriented  c++  architectural-patterns  factory-method 

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

10 design-patterns  object-oriented-design  database-design  data-structures 

ฉันได้ดูคำตอบและค้นหาใน Google แล้ว แต่ฉันไม่พบสิ่งที่เป็นประโยชน์ (เช่นนั่นจะไม่มีผลข้างเคียงที่น่าอึดอัดใจ) ปัญหาของฉันในเชิงนามธรรมคือฉันมีวัตถุและจำเป็นต้องดำเนินการลำดับที่ยาวนานของมัน ฉันคิดว่ามันเป็นสายการประกอบเช่นการสร้างรถ ผมเชื่อว่าวัตถุเหล่านี้จะเรียกว่าวิธีวัตถุ ดังนั้นในตัวอย่างนี้ในบางครั้งฉันจะมี CarWithoutUpholstery ซึ่งฉันจะต้องเรียกใช้ installBackSeat, installFrontSeat, installWoodenInserts (การดำเนินการไม่รบกวนซึ่งกันและกันและอาจทำได้ในแบบคู่ขนาน) การดำเนินการเหล่านี้ดำเนินการโดย CarWithoutUpholstery.worker () และให้ผลลัพธ์เป็นวัตถุใหม่ซึ่งจะเป็น CarWithUpholstery ซึ่งฉันจะเรียกใช้ cleanInsides (), validNoUpholsteryDefects () และอื่น ๆ การดำเนินงานในเฟสเดียวนั้นมีความเป็นอิสระอยู่แล้วเช่นฉันกำลังต่อสู้กับส่วนย่อยของพวกเขาที่อาจดำเนินการในลำดับใด ๆ (ที่นั่งด้านหน้าและด้านหลังอาจติดตั้งในลำดับใดก็ได้) ตรรกะของฉันในปัจจุบันใช้ Reflection เพื่อความง่ายในการใช้งาน นั่นคือเมื่อฉันมี CarWithoutUpholstery วัตถุจะตรวจสอบตัวเองสำหรับวิธีที่เรียกว่า performSomething () ณ จุดนั้นมันรันวิธีการเหล่านี้ทั้งหมด: myObject.perform001SomeOperation(); myObject.perform002SomeOtherOperation(); ... ในขณะที่ตรวจสอบข้อผิดพลาดและสิ่งต่างๆ ในขณะที่คำสั่งของการดำเนินงานเป็นสำคัญผมได้รับมอบหมายเพื่อทำพจนานุกรมในกรณีที่ผมเคยค้นพบคำสั่งบางเป็นสิ่งสำคัญหลังจากทั้งหมด สิ่งนี้ขัดแย้งกับYAGNIแต่มีค่าใช้จ่ายน้อยมาก - การเรียงลำดับแบบง่าย ๆ () …

10 design-patterns  refactoring  complexity