ไม่สำคัญว่าสิ่งหนึ่งจะถูกรวมเข้ากับสิ่งอื่น ๆ อย่างแน่นหนาหากสิ่งนั้นไม่เคยเปลี่ยนแปลง ฉันพบว่ามันมีประสิทธิผลมากกว่าปกติในช่วงหลายปีที่ผ่านมาเพื่อมุ่งเน้นหาเหตุผลที่น้อยกว่าสำหรับสิ่งต่าง ๆ ที่จะเปลี่ยนแปลงการแสวงหาความมั่นคงแทนที่จะทำให้พวกเขาเปลี่ยนแปลงได้ง่ายขึ้น
Decouplingฉันพบว่ามีประโยชน์มากจนถึงจุดที่บางครั้งฉันชอบการทำซ้ำรหัสเล็กน้อยเพื่อ decouple แพ็คเกจ เป็นตัวอย่างพื้นฐานฉันมีทางเลือกในการใช้ห้องสมุดคณิตศาสตร์ของฉันเพื่อใช้ไลบรารีรูปภาพ ฉันไม่ได้และเพิ่งทำซ้ำฟังก์ชันคณิตศาสตร์พื้นฐานบางอย่างซึ่งเป็นการลอกเลียนแบบเล็กน้อย
ตอนนี้ไลบรารีรูปภาพของฉันเป็นอิสระอย่างสมบูรณ์จากห้องสมุดคณิตศาสตร์ในแบบที่ไม่ว่าฉันจะทำการเปลี่ยนแปลงอะไรกับ lib คณิตศาสตร์ของฉันมันจะไม่ส่งผลกระทบต่อไลบรารีรูปภาพ นั่นคือการวางความมั่นคงเป็นอันดับแรกและสำคัญที่สุด ไลบรารีรูปภาพมีเสถียรภาพมากขึ้นในขณะนี้เนื่องจากมีเหตุผลในการเปลี่ยนแปลงน้อยลงอย่างมากเนื่องจากมันถูกแยกออกจากไลบรารีอื่น ๆ ที่สามารถเปลี่ยนแปลงได้ (นอกเหนือจากไลบรารีมาตรฐาน C ซึ่งหวังว่าไม่ควรเปลี่ยนแปลง) โบนัสยังง่ายต่อการปรับใช้เมื่อเป็นเพียงไลบรารีแบบสแตนด์อโลนที่ไม่ต้องการดึง libs จำนวนมากเพื่อสร้างและใช้งาน
ความเสถียรมีประโยชน์มากสำหรับฉัน ฉันชอบสร้างชุดโค้ดที่ผ่านการทดสอบอย่างดีซึ่งมีเหตุผลน้อยลงเรื่อย ๆ ที่จะเปลี่ยนแปลงในอนาคต นั่นไม่ใช่ความฝันที่ไพเราะ ฉันมีรหัส C ที่ฉันใช้และใช้อีกครั้งตั้งแต่ปลาย 80 ซึ่งไม่ได้เปลี่ยนเลยตั้งแต่นั้นมา มันเป็นที่ยอมรับในระดับต่ำเช่นพิกเซลและพิกเซลที่เกี่ยวข้องกับรูปทรงเรขาคณิตในขณะที่สิ่งต่าง ๆ ในระดับที่สูงขึ้นของฉันล้าสมัย แต่มันก็เป็นสิ่งที่ยังคงช่วยได้มาก นั่นหมายถึงห้องสมุดที่พึ่งพาสิ่งต่าง ๆ น้อยลงหากไม่มีสิ่งภายนอกเลย ความน่าเชื่อถือจะเพิ่มขึ้นเรื่อย ๆ หากซอฟต์แวร์ของคุณขึ้นอยู่กับรากฐานที่มั่นคงซึ่งพบว่ามีเหตุผลเพียงเล็กน้อยหรือไม่มีเหตุผลที่จะเปลี่ยนแปลง ชิ้นส่วนที่เคลื่อนไหวได้น้อยลงเป็นสิ่งที่ดีจริงๆแม้ว่าในทางปฏิบัติชิ้นส่วนที่เคลื่อนไหวนั้นมีจำนวนมากกว่าชิ้นส่วนที่มั่นคง
การมีเพศสัมพันธ์แบบหลวมอยู่ในหลอดเลือดดำเดียวกัน แต่ฉันพบว่าการมีเพศสัมพันธ์แบบหลวมนั้นมีความเสถียรน้อยกว่าไม่มีข้อต่อ หากคุณไม่ได้ทำงานเป็นทีมกับนักออกแบบส่วนต่อประสานที่ยอดเยี่ยมและลูกค้าที่ไม่ได้เปลี่ยนความคิดของฉันมากกว่าที่เคยทำงานแม้แต่อินเทอร์เฟซที่บริสุทธิ์มักจะหาเหตุผลที่จะเปลี่ยนวิธีที่ยังทำให้เกิดการแตกซ้อน แนวคิดนี้ว่าความมั่นคงสามารถเกิดขึ้นได้โดยการนำการอ้างอิงไปสู่นามธรรมแทนที่จะเป็นรูปธรรมจะมีประโยชน์เฉพาะถ้าการออกแบบส่วนต่อประสานนั้นง่ายต่อการทำให้ถูกต้องในครั้งแรกมากกว่าการใช้งาน ฉันมักจะพบว่าสิ่งที่ตรงกันข้ามนักพัฒนาอาจสร้างสิ่งที่ดีมากหากไม่ได้ยอดเยี่ยมการใช้งานตามข้อกำหนดการออกแบบที่พวกเขาคิดว่าพวกเขาควรปฏิบัติตามเท่านั้นที่จะพบในอนาคตที่ความต้องการการออกแบบเปลี่ยนแปลงอย่างสมบูรณ์
ดังนั้นฉันชอบความมั่นคงและ decoupling อย่างสมบูรณ์เพื่อที่ฉันสามารถพูดได้อย่างมั่นใจว่า "ห้องสมุดเล็ก ๆ แห่งนี้ซึ่งถูกใช้มานานหลายปีและปลอดภัยโดยการทดสอบอย่างละเอียดมีความเป็นไปได้ที่จะต้องเปลี่ยนแปลงไม่ว่าจะเกิดอะไรขึ้นในโลกภายนอก ." มันทำให้ฉันมีชีวิตชีวาเล็กน้อยไม่ว่าการเปลี่ยนแปลงการออกแบบจะถูกเรียกจากภายนอก
การมีเพศสัมพันธ์และความเสถียรตัวอย่าง ECS
ฉันยังรักระบบส่วนประกอบของเอนทิตีและพวกเขาแนะนำการมีเพศสัมพันธ์อย่างแน่นหนามากเพราะระบบในการพึ่งพาองค์ประกอบทั้งหมดเข้าถึงและจัดการข้อมูลดิบโดยตรงเช่น:
การพึ่งพาทั้งหมดที่นี่ค่อนข้างแน่นเนื่องจากส่วนประกอบเพิ่งเปิดเผยข้อมูลดิบ การพึ่งพาไม่ได้ไหลไปสู่สิ่งที่เป็นนามธรรมพวกมันกำลังไหลไปสู่ข้อมูลดิบซึ่งหมายความว่าแต่ละระบบมีจำนวนความรู้สูงสุดที่เป็นไปได้เกี่ยวกับองค์ประกอบแต่ละประเภทที่พวกเขาร้องขอให้เข้าถึง ส่วนประกอบไม่มีการทำงานกับทุกระบบที่เข้าถึงและแก้ไขข้อมูลดิบ อย่างไรก็ตามมันง่ายมากที่จะให้เหตุผลเกี่ยวกับระบบเช่นนี้เนื่องจากมันค่อนข้างแบน หากพื้นผิวมีลักษณะเป็นเกลียวคุณก็จะรู้ได้ทันทีว่าระบบนี้มีเฉพาะการเรนเดอร์และการเพนต์ส่วนประกอบการเข้าถึงระบบพื้นผิวและคุณอาจจะสามารถแยกแยะระบบการเรนเดอร์ได้อย่างรวดเร็ว
ในขณะที่ทางเลือกคู่ที่หลวมอาจเป็น:
... ด้วยการพึ่งพาทั้งหมดที่ไหลไปสู่ฟังก์ชั่นที่เป็นนามธรรมไม่ใช่ข้อมูลและทุก ๆ สิ่งในแผนภาพนั้นเปิดเผยถึงส่วนต่อประสานสาธารณะและฟังก์ชันการทำงานของมันเอง ที่นี่การพึ่งพาทั้งหมดอาจจะหลวมมาก วัตถุอาจไม่ได้ขึ้นอยู่กับแต่ละอื่น ๆ โดยตรงและโต้ตอบกันผ่านทางอินเตอร์เฟซที่บริสุทธิ์ ยังคงเป็นเรื่องยากมากที่จะให้เหตุผลเกี่ยวกับระบบนี้โดยเฉพาะหากมีสิ่งผิดปกติเกิดขึ้นเนื่องจากการโต้ตอบที่ซับซ้อน นอกจากนี้ยังจะมีการโต้ตอบกันมากขึ้น (การมีเพศสัมพันธ์มากขึ้นแม้ว่าจะเป็นคนขี้แพ้) มากกว่า ECS เพราะหน่วยงานจำเป็นต้องรู้เกี่ยวกับองค์ประกอบที่พวกเขารวมกันแม้ว่าพวกเขาจะรู้เกี่ยวกับอินเทอร์เฟซสาธารณะของกันและกันเท่านั้น
นอกจากนี้หากมีการเปลี่ยนแปลงการออกแบบกับสิ่งใดก็ตามคุณจะได้รับความเสียหายเพิ่มมากขึ้นกว่า ECS และโดยทั่วไปจะมีเหตุผลและการล่อลวงสำหรับการเปลี่ยนแปลงการออกแบบมากขึ้นเนื่องจากทุกสิ่งพยายามที่จะให้ส่วนต่อประสานและวัตถุที่เป็นนามธรรม ที่มาพร้อมกับความคิดที่ว่าสิ่งเล็ก ๆ น้อย ๆ ทุกอย่างจะพยายามกำหนดข้อ จำกัด และข้อ จำกัด ในการออกแบบและข้อ จำกัด เหล่านั้นมักจะเป็นสิ่งที่รับประกันการเปลี่ยนแปลงการออกแบบ ฟังก์ชั่นมีข้อ จำกัด มากขึ้นและต้องทำให้สมมติฐานการออกแบบมากมายกว่าข้อมูลดิบ
ฉันพบว่าในทางปฏิบัติแล้วระบบ ECS "แบบแฟลต" ข้างต้นนั้นง่ายกว่าที่จะให้เหตุผลมากกว่าระบบที่เป็นแบบคู่ที่หลวมที่สุดและมีใยแมงมุมที่ซับซ้อนที่มีการพึ่งพาแบบหลวม ๆ และที่สำคัญที่สุดสำหรับฉันฉันพบว่ามีเหตุผลน้อยมาก สำหรับรุ่น ECS จำเป็นต้องเปลี่ยนส่วนประกอบใด ๆ ที่มีอยู่เดิมเนื่องจากส่วนประกอบที่ขึ้นอยู่กับไม่มีความรับผิดชอบยกเว้นเพื่อให้ข้อมูลที่เหมาะสมที่จำเป็นสำหรับระบบการทำงาน เปรียบเทียบความยากลำบากในการออกแบบIMotionอินเทอร์เฟซที่บริสุทธิ์และวัตถุการเคลื่อนไหวที่เป็นรูปธรรมการใช้อินเทอร์เฟซที่ให้ฟังก์ชันการทำงานที่ซับซ้อนในขณะที่พยายามรักษาค่าคงที่เหนือข้อมูลส่วนตัวกับองค์ประกอบการเคลื่อนไหวที่ต้องการเพียงให้ข้อมูลดิบที่เกี่ยวข้องกับการแก้ปัญหา ฟังก์ชั่น
ฟังก์ชั่นนั้นยากกว่ามากที่จะได้รับข้อมูลซึ่งเป็นเหตุผลว่าทำไมฉันจึงคิดว่ามันมักจะดีกว่าที่จะชี้นำการไหลของการพึ่งพาต่อข้อมูล ท้ายที่สุดมีไลบรารีเวกเตอร์ / เมทริกซ์กี่อันที่นั่น? มีกี่คนที่ใช้การแสดงข้อมูลที่เหมือนกันและแตกต่างกันเล็กน้อยในการทำงาน? นับไม่ถ้วน แต่เรายังคงมีข้อมูลจำนวนมากเหมือนกันเพราะเราต้องการความแตกต่างเล็กน้อยในการทำงาน มีไลบรารีรูปภาพกี่อัน? จำนวนของพวกเขาเป็นตัวแทนของพิกเซลในวิธีที่แตกต่างและไม่ซ้ำกัน? แทบจะทุก ๆ ครั้งและแสดงให้เห็นอีกครั้งว่าการทำงานนั้นไม่เสถียรและมีแนวโน้มที่จะเปลี่ยนแปลงการออกแบบมากกว่าข้อมูลในหลาย ๆ สถานการณ์ แน่นอนในบางจุดที่เราต้องการฟังก์ชั่นการใช้งาน แต่คุณสามารถออกแบบระบบที่การพึ่งพาจำนวนมากต่อข้อมูล และไม่ใช่ไปสู่ abstractions หรือฟังก์ชั่นโดยทั่วไป ดังกล่าวจะจัดลำดับความสำคัญความมั่นคงเหนือการมีเพศสัมพันธ์
ฟังก์ชั่นที่เสถียรที่สุดที่ฉันเคยเขียน (แบบที่ฉันใช้และนำมาใช้ใหม่ตั้งแต่ปลายยุค 80 โดยไม่ต้องเปลี่ยนเลย) คือทุกสิ่งที่อาศัยข้อมูลดิบเช่นฟังก์ชันเรขาคณิตที่เพิ่งได้รับการยอมรับ ลอยและจำนวนเต็มไม่ได้คนที่ขึ้นอยู่กับความซับซ้อนMeshวัตถุหรือIMeshอินเตอร์เฟซหรือเวกเตอร์ / คูณเมทริกซ์ซึ่งก็ขึ้นอยู่กับfloat[]หรือไม่หนึ่งที่ขึ้นอยู่กับdouble[]FancyMatrixObjectWhichWillRequireDesignChangesNextYearAndDeprecateWhatWeUse