แต่วิธีการดึง () ไม่ใช่วิธีที่ขึ้นอยู่กับว่าส่วนต่อประสานผู้ใช้คืออะไร
จากมุมมองการจัดเรียงในทางปฏิบัติโค้ดบางอย่างในระบบของคุณจำเป็นต้องรู้วิธีการวาดบางอย่างเช่นRectangleถ้านั่นเป็นข้อกำหนดของผู้ใช้ และนั่นจะทำให้บางสิ่งบางอย่างในระดับต่ำลงไปเช่นการทำพิกเซลแรสเตอร์หรือแสดงบางอย่างในคอนโซล
คำถามจากมุมมองของการมีเพศสัมพันธ์คือใคร / สิ่งที่ควรขึ้นอยู่กับข้อมูลประเภทนี้และระดับรายละเอียด (เช่นนามธรรมเช่น)?
ความสามารถในการวาด / การแสดงบทคัดย่อ
เพราะหากรหัสการวาดในระดับที่สูงกว่านั้นขึ้นอยู่กับสิ่งที่เป็นนามธรรมนามธรรมสิ่งนั้นอาจจะสามารถทำงานได้ เป็นตัวอย่างที่วางแผนไว้IDrawerอินเทอร์เฟซที่เป็นนามธรรมบางอย่างอาจสามารถนำมาใช้ในทั้งคอนโซลและ GUI API เพื่อทำสิ่งต่าง ๆ เช่นรูปร่างแบบพล็อต (การใช้คอนโซลอาจปฏิบัติต่อคอนโซลเช่นบางส่วน แน่นอนว่าเป็นตัวอย่างที่คาดเดาได้เนื่องจากไม่ใช่สิ่งที่คุณต้องการทำคือรักษาคอนโซลเอาต์พุตเหมือนบัฟเฟอร์ภาพ / เฟรม โดยทั่วไปแล้วความต้องการของผู้ใช้ส่วนใหญ่จะเรียกร้องให้มีการโต้ตอบด้วยข้อความเป็นหลักในคอนโซล
การพิจารณาก็เป็นวิธีการที่ง่ายก็คือการออกแบบที่เป็นนามธรรมที่มีเสถียรภาพหรือไม่? เพราะอาจเป็นเรื่องง่ายหากคุณกำหนดเป้าหมายทั้งหมดเป็น GUI APIs ที่ทันสมัยเพื่อย่อความสามารถในการวาดรูปร่างพื้นฐานเช่นการพล็อตเส้น, สี่เหลี่ยม, พา ธ , ข้อความ, สิ่งต่าง ๆ แบบนี้ (เพียงแค่การแรสเตอร์ 2D แบบง่ายๆ ด้วยอินเทอร์เฟซแบบนามธรรมเดียวที่สามารถนำไปใช้งานได้อย่างง่ายดายผ่านประเภทย่อยต่างๆด้วยค่าใช้จ่ายน้อย หากคุณสามารถออกแบบสิ่งที่เป็นนามธรรมได้อย่างมีประสิทธิภาพและนำไปใช้กับแพลตฟอร์มเป้าหมายทั้งหมดฉันจะบอกว่ามันเป็นความชั่วร้ายที่น้อยกว่ามากถ้าแม้แต่ความชั่วร้ายเลยสำหรับรูปร่างหรือการควบคุม GUI หรืออะไรก็ตามที่รู้วิธีวาดตัวเองโดยใช้ สิ่งที่เป็นนามธรรม
แต่สมมติว่าคุณกำลังพยายามที่จะสรุปรายละเอียดเลือดออกที่แตกต่างกันระหว่าง Playstation Portable, iPhone, XBox One และพีซีเกมที่ทรงพลังในขณะที่ความต้องการของคุณคือการใช้เทคนิคการเรนเดอร์ / การแรเงา 3D แบบเรียลไทม์ . ในกรณีนั้นพยายามที่จะสร้างอินเทอร์เฟซแบบนามธรรมเพื่อสรุปรายละเอียดการแสดงผลเมื่อความสามารถของฮาร์ดแวร์และ API แตกต่างกันอย่างมากจนแทบจะมั่นใจได้ว่าจะส่งผลให้มีเวลาในการออกแบบและการออกแบบใหม่อย่างมหาศาล การค้นพบและเช่นเดียวกันกับโซลูชันตัวหารร่วมที่ต่ำที่สุดที่ไม่สามารถใช้ประโยชน์จากความเป็นเอกลักษณ์และพลังของฮาร์ดแวร์พื้นฐานได้
ทำให้การอ้างอิงไหลต่อการออกแบบที่ "ง่าย"
ในสาขาของฉันฉันอยู่ในสถานการณ์สุดท้าย เรากำหนดเป้าหมายฮาร์ดแวร์จำนวนมากที่มีขีดความสามารถและ API ที่แตกต่างกันอย่างรุนแรงและพยายามสร้างการวาดภาพ / การวาดภาพหนึ่งสิ่งที่เป็นนามธรรมเพื่อปกครองพวกเขาทั้งหมดนั้นไร้ขอบเขต (เราอาจกลายเป็นคนดังระดับโลก ตัวเปลี่ยนในอุตสาหกรรม) ดังนั้นสิ่งสุดท้ายที่ฉันต้องการในกรณีของฉันเป็นเหมือนกระเชอShapeหรือModelหรือParticle Emitterที่รู้วิธีการวาดตัวเองแม้ว่าจะมีการแสดงที่วาดภาพในระดับสูงสุดและวิธีการที่เป็นนามธรรมมากที่สุด ...
... เพราะ abstractions เหล่านั้นยากเกินกว่าจะออกแบบได้อย่างถูกต้องและเมื่อการออกแบบนั้นยากที่จะแก้ไขให้ถูกต้องและทุกอย่างขึ้นอยู่กับมันนั่นเป็นสูตรสำหรับการเปลี่ยนแปลงการออกแบบส่วนกลางที่มีค่าใช้จ่ายสูงที่สุด ดังนั้นสิ่งสุดท้ายที่คุณต้องการคือการพึ่งพาในระบบของคุณที่จะไหลไปสู่การออกแบบที่เป็นนามธรรมยากเกินกว่าที่จะแก้ไขให้ถูกต้อง
ยากขึ้นอยู่กับง่ายไม่ง่ายขึ้นอยู่กับยาก
ดังนั้นสิ่งที่เราทำคือทำให้การพึ่งพาอาศัยอยู่กับสิ่งที่ออกแบบได้ง่าย มันง่ายกว่ามากในการออกแบบนามธรรม "โมเดล" ซึ่งเน้นไปที่การจัดเก็บสิ่งต่าง ๆ เช่นรูปหลายเหลี่ยมและวัสดุและได้รับการออกแบบที่ถูกต้องมากกว่าการออกแบบ "Renderer" นามธรรมซึ่งสามารถนำไปใช้ได้อย่างมีประสิทธิภาพ ร้องขออย่างสม่ำเสมอสำหรับฮาร์ดแวร์ที่แตกต่างกันเป็น PSP จากพีซี
ดังนั้นเราจึงกลับการพึ่งพาจากสิ่งที่ยากต่อการออกแบบ แทนที่จะทำให้แบบจำลองนามธรรมรู้วิธีวาดตัวเองไปสู่การออกแบบ renderer นามธรรมที่พวกเขาทั้งหมดขึ้นอยู่กับ (และทำลายในการใช้งานของพวกเขาหากการเปลี่ยนแปลงการออกแบบที่) เราแทนที่จะมี renderer นามธรรมที่รู้วิธีการวาดวัตถุนามธรรมทุกฉากในฉากของเรา นางแบบ, ตัวปล่อยอนุภาค, ฯลฯ ), และดังนั้นเราจึงสามารถใช้ OpenGL renderer subtype สำหรับพีซีเช่นRendererGl, อีกอันสำหรับ PSPs RendererPsp, อีกอันสำหรับโทรศัพท์มือถือ, ฯลฯ ในกรณีนั้นการพึ่งพานั้นไหลไปสู่การออกแบบที่เสถียร, ง่ายต่อการแก้ไข, ตั้งแต่ตัวเรนเดอร์ไปจนถึงเอนทิตีประเภทต่าง ๆ (โมเดลอนุภาคพื้นผิว ฯลฯ ) ในฉากของเราไม่ใช่วิธีอื่น
- ฉันกำลังใช้ "ความเสถียร / ความไม่แน่นอน" ในแง่ที่แตกต่างจากตัวชี้วัดเชิงประจักษ์ / จุดอ่อนของลุงบ็อบที่วัดความยากลำบากในการเปลี่ยนแปลงมากขึ้นเท่าที่ฉันสามารถเข้าใจได้ ฉันกำลังพูดถึงเพิ่มเติมเกี่ยวกับ "ความน่าจะเป็นที่ต้องการการเปลี่ยนแปลง" แม้ว่าตัวชี้วัดความมั่นคงของเขาจะมีประโยชน์ เมื่อ "ความน่าจะเป็นของการเปลี่ยนแปลง" เป็นสัดส่วนกับ "ความง่ายในการเปลี่ยนแปลง" (เช่น: สิ่งที่น่าจะต้องมีการเปลี่ยนแปลงมากที่สุดมีความไม่แน่นอนและข้อต่อจากอวัยวะของลุงบ๊อบข้อต่อ) การเปลี่ยนแปลงใด ๆ ที่น่าจะเป็นไปได้ ต้องการเพียงแทนที่การใช้งานโดยไม่ต้องสัมผัสการออกแบบที่เป็นศูนย์กลาง
หากคุณพบว่าตัวเองพยายามที่จะแยกแยะสิ่งที่อยู่ในระดับกลางของ codebase ของคุณและมันก็ยากเกินกว่าที่จะออกแบบแทนที่จะตีหัวกับกำแพงและหัวรุนแรงเปลี่ยนแปลงอย่างต่อเนื่องในแต่ละเดือน / ปีที่ต้องมีการอัพเดทไฟล์ต้นฉบับ 8,000 ไฟล์ ทำลายทุกอย่างที่ขึ้นอยู่กับมันข้อเสนอแนะหมายเลขหนึ่งของฉันคือการพิจารณาคว่ำการอ้างอิง ดูว่าคุณสามารถเขียนโค้ดในลักษณะที่สิ่งที่ยากในการออกแบบหรือไม่นั้นขึ้นอยู่กับทุกสิ่งที่ง่ายต่อการออกแบบไม่มีสิ่งที่ง่ายต่อการออกแบบขึ้นอยู่กับสิ่งที่ยากในการออกแบบ โปรดทราบว่าฉันกำลังพูดถึงการออกแบบ (โดยเฉพาะการออกแบบส่วนต่อประสาน) และไม่ใช้งาน: บางครั้งสิ่งที่ง่ายต่อการออกแบบและยากที่จะนำไปใช้ และบางครั้งสิ่งที่ยากในการออกแบบ แต่ใช้งานง่าย การไหลเวียนของการพึ่งพาสู่การออกแบบดังนั้นการโฟกัสควรอยู่ที่ความยากลำบากในการออกแบบที่นี่เพื่อกำหนดทิศทางการไหลของการพึ่งพา
หลักการความรับผิดชอบเดี่ยว
สำหรับฉัน SRP ไม่ค่อยน่าสนใจที่นี่ตามปกติ (แต่ขึ้นอยู่กับบริบท) ฉันหมายถึงว่ามีการทำตัวให้สมดุลในการออกแบบสิ่งต่าง ๆ ที่ชัดเจนในวัตถุประสงค์และการบำรุงรักษา แต่Shapeวัตถุของคุณอาจต้องเปิดเผยข้อมูลโดยละเอียดหากพวกเขาไม่รู้วิธีวาดตัวเองและอาจไม่มีสิ่งที่มีความหมายมากนัก ทำกับรูปร่างในบริบทการใช้งานเฉพาะกว่าสร้างและวาด มีการแลกเปลี่ยนกับทุกสิ่งทุกอย่างและมันไม่เกี่ยวข้องกับ SRP ที่สามารถทำให้สิ่งต่าง ๆ ตระหนักถึงวิธีการวาดตัวเองสามารถกลายเป็นฝันร้ายการบำรุงรักษาจากประสบการณ์ของฉันในบริบทบางอย่าง
มันมีอะไรมากมายที่เกี่ยวข้องกับการมีเพศสัมพันธ์และทิศทางการไหลเวียนของการพึ่งพาในระบบของคุณ หากคุณพยายามที่จะพอร์ตอินเทอร์เฟซการแสดงผลที่เป็นนามธรรมที่ทุกอย่างขึ้นอยู่กับ (เพราะพวกเขากำลังใช้มันเพื่อดึงตัวเอง) ไปยัง API / ฮาร์ดแวร์เป้าหมายใหม่และตระหนักดีว่าคุณต้องเปลี่ยนการออกแบบเป็นอย่างมาก เป็นการเปลี่ยนแปลงที่มีค่าใช้จ่ายสูงซึ่งต้องเปลี่ยนการใช้งานทุกอย่างในระบบของคุณซึ่งรู้วิธีวาดตัวเอง และนั่นคือปัญหาการบำรุงรักษาที่ใช้งานได้จริงที่สุดที่ฉันพบกับสิ่งต่าง ๆ ที่ทราบถึงวิธีการวาดตัวเองถ้านั่นแปลว่าเรือบรรทุกของการพึ่งพาที่ไหลไปสู่ abstractions ซึ่งยากเกินกว่าจะออกแบบได้อย่างถูกต้อง
ความภาคภูมิใจของนักพัฒนา
ฉันพูดถึงจุดนี้เพราะจากประสบการณ์ของฉันมักจะเป็นอุปสรรคที่ใหญ่ที่สุดในการกำหนดทิศทางของการพึ่งพาต่อสิ่งที่ง่ายต่อการออกแบบ มันง่ายมากสำหรับนักพัฒนาที่จะทะเยอทะยานเล็กน้อยที่นี่และพูดว่า"ฉันจะออกแบบการข้ามการแสดงผลข้ามแพลตฟอร์มเพื่อควบคุมพวกเขาทั้งหมดฉันจะแก้ไขสิ่งที่นักพัฒนารายอื่นใช้เวลาในการย้ายพอร์ตและฉันจะได้รับ มันถูกต้องและมันจะทำงานได้อย่างมหัศจรรย์ในทุก ๆ แพลตฟอร์มที่เราสนับสนุนและใช้เทคนิคการเรนเดอร์ที่ล้ำสมัยในทุกๆ ๆ ; ฉันจินตนาการไว้ในหัวแล้ว "ในกรณีที่พวกเขาต่อต้านวิธีการปฏิบัติที่หลีกเลี่ยงการทำเช่นนั้นและเพียงแค่พลิกทิศทางของการพึ่งพาและแปลสิ่งที่อาจมีค่าใช้จ่ายมหาศาลและการเปลี่ยนแปลงการออกแบบส่วนกลางที่เกิดขึ้นซ้ำ ๆ เพื่อการเปลี่ยนแปลงที่เกิดขึ้นในท้องถิ่น ต้องมีสัญชาตญาณ "ธงขาว" ในนักพัฒนาเพื่อให้ยอมแพ้เมื่อมีบางสิ่งที่ยากเกินกว่าที่จะออกแบบในระดับนามธรรมและทบทวนกลยุทธ์ทั้งหมดของพวกเขาไม่เช่นนั้นพวกเขาจะอยู่ในความโศกเศร้าและเจ็บปวด ฉันขอแนะนำให้ถ่ายโอนความทะเยอทะยานและจิตวิญญาณการต่อสู้ไปสู่การใช้งานที่ล้ำสมัยของสิ่งที่ง่ายต่อการออกแบบมากกว่าที่จะนำความทะเยอทะยานที่พิชิตโลกไปสู่ระดับการออกแบบอินเตอร์เฟส