มีข้อเสียอย่างมีนัยสำคัญหรือไม่ขึ้นอยู่กับ abstractions?

ผมอ่านวิกินี้บน Stable Abstractions หลักการ (SAP)

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

คิดว่าแพ็คเกจของคุณเป็น API เพื่อนำตัวอย่างจากกระดาษใช้คำจำกัดความสำหรับReaderด้วยstring Reader.Read()และWriterด้วยvoid Writer.Write(string)เป็นนามธรรมของคุณ API

จากนั้นคุณสามารถสร้างคลาสCopyด้วยวิธีการCopier.Copy(Reader, Writer)และการใช้งานWriter.Write(Reader.Read())และอาจตรวจสอบสติ

ตอนนี้คุณจะทำให้การใช้งานคอนกรีตเช่นFileReader, FileWriter, KeyboardReaderและDownloadThingsFromTheInternetReaderและ

ถ้าคุณต้องการเปลี่ยนการใช้งานของคุณ FileReaderคุณ ไม่มีปัญหาเพียงแค่เปลี่ยนคลาสและคอมไพล์ใหม่

เกิดอะไรขึ้นถ้าคุณต้องการที่จะเปลี่ยนนิยามของนามธรรมของคุณReader? อ๊ะคุณไม่สามารถเพียงแค่เปลี่ยนที่ แต่คุณยังจะมีการเปลี่ยนแปลงCopier, FileReader, KeyboardReaderและDownloadThingsFromTheInternetReaderและ

นี่คือเหตุผลที่อยู่เบื้องหลังหลักการ Abstraction Abstraction: ทำให้ข้อสรุปของคุณมีเสถียรภาพน้อยกว่า abstractions

เพราะYAGNI YAGNI

หากคุณมีการใช้งานเพียงสิ่งเดียวทำไมต้องใส่ใจกับเลเยอร์พิเศษและไร้ประโยชน์ มันจะนำไปสู่ความซับซ้อนที่ไม่จำเป็น ยิ่งแย่ไปกว่านั้นบางครั้งคุณก็ให้ความคิดที่เป็นนามธรรมถึงวันที่การดำเนินการครั้งที่สองจะมาถึง ... และวันนี้ไม่เคยเกิดขึ้น ช่างเป็นงานที่เสียเปล่า!

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

ใน บริษัท ที่ฉันทำงานอยู่ซอฟต์แวร์บางตัวที่ฉันพัฒนานั้นเชื่อมโยงกับอุปกรณ์ฮาร์ดแวร์ที่ต้องสื่อสาร อุปกรณ์เหล่านี้ได้รับการพัฒนาเพื่อตอบสนองเป้าหมายที่เฉพาะเจาะจงและเป็นทุกอย่างยกเว้นโมดูลาร์ :-) เมื่ออุปกรณ์แรกที่ผลิตออกไปจากโรงงานและมีการติดตั้งที่ใดที่หนึ่งทั้งเฟิร์มแวร์และฮาร์ดแวร์ของมันไม่สามารถเปลี่ยนแปลงที่เคย

ดังนั้นฉันจึงมั่นใจได้ว่าบางส่วนของซอฟต์แวร์จะไม่มีวันเปลี่ยนแปลง ชิ้นส่วนเหล่านี้ไม่จำเป็นต้องพึ่งพา abstractions เนื่องจากมีเพียงการนำไปใช้งานเพียงครั้งเดียวและชิ้นส่วนนี้จะไม่เปลี่ยนแปลง การประกาศ abstractions ในส่วนของรหัสเหล่านี้จะสร้างความสับสนให้ทุกคนและใช้เวลามากขึ้น (โดยไม่ต้องสร้างคุณค่าใด ๆ )

ฉันคิดว่าคุณอาจสับสนกับคำที่เลือกโดย Robert Martin นี่คือสิ่งที่ฉันคิดว่าความสับสนเริ่มขึ้น:

นี่ก็หมายความว่าหากแพ็คเกจมีความเสถียรน้อยกว่า(มีแนวโน้มที่จะเปลี่ยนแปลงได้) ก็ควรมีรูปธรรมมากขึ้น

หากคุณอ่านบทความต้นฉบับคุณจะเห็น (เน้นที่เหมือง):

นิยามคลาสสิกของความเสถียรของคำคือ: "ไม่ขยับง่าย" นี่คือคำจำกัดความที่เราจะใช้ในบทความนี้ นั่นคือความมั่นคงไม่ได้วัดความน่าจะเป็นที่โมดูลจะเปลี่ยน ค่อนข้างมันเป็นตัวชี้วัดของความยากลำบากในการเปลี่ยนแปลงโมดูล

เห็นได้ชัดว่าโมดูลที่เปลี่ยนแปลงได้ยากขึ้นจะมีความผันผวนน้อยลง ยิ่งโมดูลเปลี่ยนยากเช่นยิ่งมีเสถียรภาพมากก็จะยิ่งมีความผันผวนน้อยลง

ฉันได้พยายามเสมอกับทางเลือกของผู้เขียนของคำที่มีความเสถียรที่ผม (เช่นคุณ) มีแนวโน้มที่จะคิดของ "โอกาส" ด้านของความมั่นคงคือไม่น่าจะเปลี่ยนแปลง ความยากหมายความว่าการเปลี่ยนโมดูลนั้นจะทำลายโมดูลอื่น ๆ จำนวนมากและมันจะเป็นงานที่ต้องแก้ไขรหัส

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

ดังนั้นต่อไปนี้วิญญาณของ "รับผิดชอบ" ฉันมาพร้อมกับความหมายทางเลือกสำหรับการเปลี่ยนแปลงยาก (หรือไม่ควรเปลี่ยน ):

• Obligated - หมายถึงคลาสอื่น ๆ ขึ้นอยู่กับคลาสนี้ดังนั้นจึงไม่ควรเปลี่ยนแปลง
• Beholden - อ้างแล้ว
• ข้อ จำกัด - ภาระผูกพันของชั้นนี้ จำกัด สิ่งอำนวยความสะดวกในการเปลี่ยนแปลง

ดังนั้นการเสียบคำจำกัดความเหล่านี้ลงในคำสั่ง

ยิ่งมีเสถียรภาพแพคเกจนามธรรมมากขึ้นมันควรจะเป็น

• มากขึ้นภาระผูกพันในแพคเกจนามธรรมมากขึ้นมันควรจะเป็น
• ยิ่งเห็นคุณค่าของแพ็คเกจมากเท่าไรก็ยิ่งเป็นนามธรรมมากขึ้นเท่านั้น
• ยิ่งจำกัดแพคเกจนามธรรมมากขึ้นมันควรจะเป็น

ลองอ้างอิงหลักการนามธรรมที่มีเสถียรภาพ (SAP) โดยเน้นคำที่สับสนว่าเสถียร / ไม่เสถียร:

แพ็คเกจที่มีความเสถียรสูงสุดควรเป็นนามธรรมที่สุด แพ็คเกจที่ไม่เสถียรควรเป็นรูปธรรม นามธรรมของแพคเกจที่ควรจะอยู่ในสัดส่วนที่ของความมั่นคง

ให้ความกระจ่างโดยไม่มีคำที่สับสนเหล่านี้:

แพคเกจที่ได้รับการเห็นคุณค่าสูงสุดในส่วนอื่น ๆ ของระบบควรเป็นนามธรรมที่สุด แพ็คเกจที่สามารถเปลี่ยนแปลงได้โดยไม่มีปัญหาควรเป็นรูปธรรม นามธรรมของแพคเกจที่ควรจะอยู่ในสัดส่วนที่ว่ามันยากที่จะได้รับการแก้ไข

TL; DR

ชื่อคำถามของคุณถาม:

มีข้อเสียอย่างมีนัยสำคัญหรือไม่ขึ้นอยู่กับ abstractions?

ฉันคิดว่าถ้าคุณสร้าง abstractions อย่างถูกต้อง (เช่นพวกมันมีอยู่เพราะโค้ดจำนวนมากขึ้นอยู่กับพวกเขา) แล้วก็ไม่มีข้อเสียที่สำคัญ

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

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

ดังนั้นหากแพ็คเกจของคุณกำลังจะเปลี่ยนบ่อยๆควรจัดให้มี concretes ไม่ใช่ abstractions มิฉะนั้น ... ใครจะใช้มัน? ;)

โปรดจำไว้ว่าการวัดความมั่นคงของมาร์ตินและสิ่งที่เขาหมายถึงโดย "ความมั่นคง":

Instability = Ce / (Ca+Ce)

หรือ:

Instability = Outgoing / (Incoming+Outgoing)

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

ในขณะเดียวกันเมื่อคุณมีสถานการณ์ตรงข้ามของ "ความมั่นคง" ที่สมบูรณ์พร้อมกับแพ็คเกจที่ใช้โดยสิ่งหนึ่งหรือหลายอย่าง แต่มันก็ไม่ได้ใช้อะไรเป็นของตัวเองเหมือนแพ็คเกจกลางที่ซอฟต์แวร์ใช้นั่นคือเมื่อ Martin บอกว่าสิ่งนี้ควรจะเป็น นามธรรม. ซึ่งได้รับการเสริมด้วยส่วน DIP ของ SOLI (D) หลักการการพึ่งพาการพึ่งพาซึ่งโดยทั่วไประบุว่าการพึ่งพาควรไหลไปสู่ ​​abstractions อย่างสม่ำเสมอทั้งรหัสระดับต่ำและระดับสูง

นั่นคือการพึ่งพาควรไหลไปสู่ ​​"ความมั่นคง" อย่างสม่ำเสมอและแม่นยำยิ่งขึ้นการพึ่งพาควรไหลไปสู่บรรจุภัณฑ์ที่มีการอ้างอิงที่เข้ามามากกว่าการพึ่งพาขาออกและยิ่งกว่านั้นการพึ่งพาควรไหลไปสู่ ​​abstractions สรุปสาระสำคัญของเหตุผลที่อยู่เบื้องหลังคือ abstractions จัดให้มีห้องหายใจเพื่อทดแทน subtype อีกอันหนึ่งโดยเสนอระดับความยืดหยุ่นสำหรับชิ้นส่วนที่เป็นรูปธรรมที่ใช้อินเทอร์เฟซการเปลี่ยนแปลงโดยไม่ทำลายการพึ่งพาเข้ามาสู่อินเตอร์เฟสนามธรรมนั้น

มีข้อเสียอย่างมีนัยสำคัญหรือไม่ขึ้นอยู่กับ abstractions?

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

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

สำหรับบริบทจำนวนมากที่อาจเป็นกรณีที่มีวิศวกรและลูกค้าที่คาดหวังความต้องการซอฟต์แวร์ล่วงหน้าและการออกแบบที่มีความเสถียร (ใน, ไม่มีการเปลี่ยนแปลง) abstractions ในขณะที่ abstractions เหล่านั้นเสนอห้องหายใจทั้งหมดที่พวกเขาต้องการสลับการใช้งานที่เป็นรูปธรรม แต่ในบางโดเมนบทคัดย่ออาจไม่เสถียรและมีแนวโน้มที่จะไม่เพียงพอในขณะที่ข้อมูลที่ต้องการของเครื่องยนต์อาจง่ายกว่ามากในการคาดการณ์และทำให้เสถียรล่วงหน้า ดังนั้นในกรณีเหล่านั้นมันจะเป็นประโยชน์มากขึ้นจากมุมมองการบำรุงรักษา (ความง่ายในการเปลี่ยนและขยายระบบ) สำหรับการพึ่งพาการไหลไปยังข้อมูลมากกว่านามธรรม ใน ECS ชิ้นส่วนที่ไม่เสถียรที่สุด (เหมือนในส่วนที่เปลี่ยนบ่อยที่สุด) มักเป็นฟังก์ชันที่อยู่ในระบบ (PhysicsSystemเช่นในขณะที่ชิ้นส่วนที่เสถียรที่สุด (อย่างน้อยน่าจะมีการเปลี่ยนแปลง) คือส่วนประกอบที่เพิ่งประกอบไปด้วยข้อมูลดิบ ( MotionComponentเช่น) ซึ่งระบบทั้งหมดใช้