สิ่งที่เป็นนามธรรม: สงครามระหว่างการแก้ปัญหาและการแก้ปัญหาทั่วไป [ปิด]

ในฐานะโปรแกรมเมอร์ฉันพบว่าตัวเองอยู่ในภาวะที่กลืนไม่เข้าคายไม่ออกที่ฉันต้องการให้โปรแกรมของฉันเป็นนามธรรมและทั่วไปที่สุด

การทำเช่นนั้นมักจะอนุญาตให้ฉันนำรหัสของฉันมาใช้ซ้ำและมีวิธีแก้ปัญหาทั่วไปที่มากขึ้นสำหรับปัญหาที่อาจเกิดขึ้น (หรืออาจจะไม่เกิดขึ้น) อีกครั้ง

จากนั้นเสียงนี้ในหัวของฉันบอกว่าเพียงแก้ปัญหาหลอกตามันเป็นเรื่องง่าย! ทำไมต้องใช้เวลามากกว่าที่คุณต้องทำ

เราทุกคนต้องเผชิญกับคำถามนี้อย่างแน่นอนซึ่งสิ่งที่เป็นนามธรรมอยู่บนไหล่ขวาของคุณและ Solve-it-stupid นั่งทางซ้าย

สิ่งที่ฟังและบ่อยครั้ง? กลยุทธ์ของคุณสำหรับสิ่งนี้คืออะไร? คุณควรสรุปทุกอย่างหรือไม่

สิ่งที่ฟังและบ่อยครั้ง?

ไม่เป็นนามธรรมจนกว่าคุณจะต้อง

ตัวอย่างเช่นใน Java คุณต้องใช้อินเตอร์เฟส พวกเขาเป็นนามธรรม

ใน Python คุณไม่มีอินเทอร์เฟซคุณมี Duck Typing และคุณไม่จำเป็นต้องมีระดับความเป็นนามธรรมสูง ดังนั้นคุณก็ทำไม่ได้

กลยุทธ์ของคุณสำหรับสิ่งนี้คืออะไร?

ไม่เป็นนามธรรมจนกว่าคุณจะเขียนมันสามครั้ง

ครั้งเดียว - ดี - ครั้งเดียว เพียงแค่แก้มันและเดินหน้าต่อไป

สองครั้งบ่งชี้ว่าอาจมีรูปแบบที่นี่ หรืออาจจะไม่ มันอาจเป็นเรื่องบังเอิญ

สามครั้งคือจุดเริ่มต้นของรูปแบบ ตอนนี้มันอยู่เหนือความบังเอิญ ตอนนี้คุณสามารถสรุปได้สำเร็จ

คุณควรสรุปทุกอย่างหรือไม่

เลขที่

แน่นอนว่าคุณไม่ควรสรุปสิ่งใดจนกว่าคุณจะมีหลักฐานแน่ชัดว่าคุณกำลังทำสิ่งที่เป็นนามธรรม หากไม่มี "กฎการทำซ้ำสามครั้ง" คุณจะเขียนเนื้อหาที่ไร้สาระในแบบที่ไม่ช่วยเหลือ

การทำเช่นนั้นมักจะอนุญาตให้ฉันนำรหัสของฉันมาใช้ซ้ำ

นี่คือสมมติฐานที่มักจะเป็นเท็จ สิ่งที่เป็นนามธรรมอาจไม่ช่วยเลย มันสามารถทำได้ไม่ดี ดังนั้นอย่าทำจนกว่าคุณจะต้อง

อ้า YAGNI แนวคิดที่ถูกทารุณที่สุดในการเขียนโปรแกรม

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

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

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

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

Syllogism:

1. Generality มีราคาแพง

2. คุณกำลังใช้เงินของคนอื่น

3. ดังนั้นค่าใช้จ่ายในการสร้างความเป็นสากลจะต้องเป็นธรรมต่อผู้มีส่วนได้ส่วนเสีย

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

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

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

ณ จุดนี้คุณควรละทิ้ง C # และยอมรับ JavaScript แต่คุณยังไม่ได้อยู่ใกล้พอ จะเกิดอะไรขึ้นถ้ามีคนต้องการเปลี่ยนวิธีการค้นหาสมาชิกสำหรับวัตถุนี้โดยเฉพาะ? บางทีคุณควรเขียนทุกอย่างใน Python แทน

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

เพื่อให้ชัดเจนการทำสิ่งที่เป็นมาตรฐานและการนำนามธรรมมาใช้นั้นเป็นสองสิ่งที่แตกต่างกันโดยสิ้นเชิง

ตัวอย่างเช่นพิจารณาฟังก์ชั่นที่คัดลอกหน่วยความจำ

ฟังก์ชั่นเป็นนามธรรมที่ซ่อนวิธีคัดลอก 4 ไบต์

int copy4Bytes (ถ่าน * pSrc, ถ่าน * pDest)

การวางนัยทั่วไปจะทำให้ฟังก์ชั่นนี้คัดลอกจำนวนไบต์ใด ๆ

int copyBytes (ถ่าน * pSrc, ถ่าน * pDest, int numBytesToCopy)

สิ่งที่เป็นนามธรรมให้ยืมตัวเองเพื่อนำมาใช้ใหม่ในขณะที่ลักษณะทั่วไปเพียงทำให้สิ่งที่เป็นประโยชน์ในกรณีเพิ่มเติม

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

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

กฎทั่วไปที่ดีสำหรับสิ่งนี้คือ Zero, One, Infinity นั่นคือถ้าคุณต้องการสิ่งที่คุณเขียนมากกว่าหนึ่งครั้งคุณสามารถคิดว่าคุณต้องการเวลามากขึ้นและพูดคุยทั่วไป กฎนี้บอกเป็นนัยว่าคุณไม่ต้องกังวลกับสิ่งที่เป็นนามธรรมในครั้งแรกที่คุณเขียนอะไรบางอย่าง

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

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

ข้อแรก: ค่านิยมทั่วไปก่อนวัยอันควรมีราคาแพง

ที่สอง: นำเสนอในแบบจำลองของคุณเฉพาะสิ่งที่อยู่ในโดเมนปัญหาเสมอและความสัมพันธ์ของคลาสไม่เปลี่ยนแปลง

ประการที่สาม: รักษานโยบายของคุณให้ห่างจากกลไกของคุณ

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

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

ฉันเป็นแฟนตัวยงของหลักการ KISS

ฉันมุ่งเน้นการให้สิ่งที่ฉันขอให้ทำไม่ใช่ทางออกที่ดีที่สุด ฉันต้องปล่อยความสมบูรณ์แบบ (และ OCD) เพราะมันทำให้ฉันมีความสุข

ที่Abstractionอยู่บนไหล่ขวาของคุณและSolve-it-stupidนั่งทางซ้าย

ผมไม่เห็นด้วยกับการ"แก้มันโง่"ผมคิดว่ามันอาจจะมากขึ้น"แก้ปัญหาสมาร์ท"

อะไรที่ฉลาดกว่า:

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

ตัวเลือกเริ่มต้นควรเป็นตัวเลือกที่สอง นอกจากว่าคุณสามารถแสดงให้เห็นถึงความต้องการ generational

วิธีการแก้ปัญหาแบบทั่วไปควรจะเกิดขึ้นเมื่อคุณทราบว่าเป็นสิ่งที่จะใช้ในโครงการ / กรณีต่างๆ

ฉันมักจะพบวิธีแก้ปัญหาทั่วไปที่ดีที่สุดให้เป็น"รหัสห้องสมุด Core"