หลักการตั้งชื่อสำหรับคลาสนามธรรม


103

ฉันจำได้ชัดเจนว่าครั้งหนึ่งแนวทางที่ Microsoft ผลักดันคือการเพิ่มคำต่อท้าย "ฐาน" ในคลาสนามธรรมเพื่อขจัดความจริงที่ว่ามันเป็นนามธรรม ดังนั้นเราต้องเรียนเหมือนSystem.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, และของหลักสูตรSystem.Windows.Forms.ButtonBaseSystem.Collections.CollectionBase

แต่ฉันสังเกตเห็นว่าในช่วงปลายปีที่ผ่านมาคลาสนามธรรมจำนวนมากใน Framework ดูเหมือนจะไม่เป็นไปตามอนุสัญญานี้ ตัวอย่างเช่นคลาสต่อไปนี้ล้วนเป็นนามธรรม แต่ไม่เป็นไปตามหลักการนี้:

  • System.DirectoryServices.ActiveDirectory.DirectoryServer

  • System.Configuration.ConfigurationElement

  • System.Drawing.Brush

  • System.Windows.Forms.CommonDialog

และนั่นเป็นเพียงสิ่งที่ฉันสามารถตีกลองได้ในไม่กี่วินาที ดังนั้นฉันจึงค้นหาสิ่งที่เอกสารทางการพูดเพื่อให้แน่ใจว่าฉันไม่ได้บ้า ผมพบว่ารายชื่อของการเรียน, Structs และการเชื่อมต่อใน MSDN ที่แนวทางการออกแบบเพื่อการพัฒนาห้องสมุด Class น่าแปลกที่ฉันไม่พบคำแนะนำในการเพิ่ม "ฐาน" ต่อท้ายชื่อคลาสนามธรรม และแนวทางดังกล่าวไม่มีให้ใช้งานสำหรับ Framework เวอร์ชัน 1.1 อีกต่อไป

ฉันแพ้มันหรือเปล่า? เคยมีแนวทางนี้หรือไม่? เพิ่งถูกทิ้งโดยไม่มีคำพูด? ฉันสร้างชื่อชั้นยาว ๆ ด้วยตัวเองตลอดสองปีที่ผ่านมาเพื่ออะไร?

มีคนโยนกระดูกให้ฉันที่นี่

อัพเดท ฉันไม่ได้บ้า แนวทางมีอยู่ Krzysztof Cwalina จับเรื่องนี้ในปี 2548


หากคุณอ่านบทความนั้น Krzysztof เพียงแค่บ่นเกี่ยวกับการได้รับ "ชุดคำแนะนำ" - ไม่จำเป็นว่าคำแนะนำเหล่านั้นจะเป็นคำแนะนำอย่างเป็นทางการของ Microsoft ฉันจำได้ว่าอ่านหลักเกณฑ์ของ MS และเห็นว่าพวกเขาแนะนำให้ต่อต้านสิ่งนี้
John Rudy

1
ฉันอ่านแล้วแม้ว่าจะเป็นครั้งแรกที่ฉันจำได้ว่าเคยเห็นบทความนั้น ๆ มันเป็นความโล่งใจที่จริง ฉันไม่เคยชอบคำแนะนำนี้เลย มันจะช่วยฉันได้มากจากที่นี่ :)
Mike Hofer

คำตอบ:


68

ในแนวทางการออกแบบกรอบหน้า 174 รัฐ:

หลีกเลี่ยงการตั้งชื่อคลาสพื้นฐานด้วยคำต่อท้าย "ฐาน" หากคลาสนั้นมีไว้สำหรับใช้ใน API สาธารณะ

นอกจากนี้: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx



14

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

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


11

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

คำต่อท้ายฐานเป็นสิ่งที่น่าเกลียดเมื่อเขียนโปรแกรมกับอินเทอร์เฟซดังนั้นฉันคิดว่าแนวทางของ Microsoft ที่ไม่ควรใช้นั้นมีผลเมื่อใช้คลาสนามธรรมเป็นส่วนใหญ่เช่นอินเทอร์เฟซ อาจเป็นความหมายของ Public API

ประเด็นคือมีหลายกรณีที่ไม่มีทางเลือกอื่นที่ดีกว่าในการใช้คำต่อท้ายฐาน


4
ฉันเห็นด้วย. ฉันกำลังทำงานในระบบฟีดที่แยกวิเคราะห์เนื้อหาจากแหล่งต่างๆ เราใช้อินเทอร์เฟซ API ชื่อIFeedParserใน API สาธารณะและภายในเราใช้คลาสบทคัดย่อพื้นฐานที่มีฟังก์ชันการทำงานทั่วไปที่ชื่อBaseFeedParser
Rui Jarimba

1

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

ในฐานะทางเลือก:ฉันต้องการใช้ "Kind" เป็นคำต่อท้ายเพื่อระบุว่าวัตถุนั้นเป็น "ของหรือเป็นของเผ่าพันธุ์หรือตระกูลที่ระบุ" ( วิกิพจนานุกรม: -kind )

ตัวอย่าง: DataProviderและReflectiveDataProviderเป็นทั้งสองอย่างDataProviderKind

แรงบันดาลใจจากชีววิทยาที่เช่น "canis lupus" เป็นของตระกูล "Canoidea" ซึ่งแปลได้คร่าวๆว่า "dog-ish"


1

Microsoft สหรัฐอเมริกาที่:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ CONSIDER ที่ลงท้ายชื่อของคลาสที่ได้รับด้วยชื่อของคลาสพื้นฐานซึ่งสามารถอ่านได้มากและอธิบายความสัมพันธ์ได้อย่างชัดเจนตัวอย่างบางส่วนของโค้ดนี้ ได้แก่ ArgumentOutOfRangeException ซึ่งเป็น Exception ชนิดหนึ่งและ SerializableAttribute ซึ่งเป็น ชนิดของแอตทริบิวต์อย่างไรก็ตามสิ่งสำคัญคือต้องใช้วิจารณญาณอย่างสมเหตุสมผลในการนำแนวทางนี้ไปใช้ตัวอย่างเช่นคลาส Button เป็นเหตุการณ์การควบคุมชนิดหนึ่งแม้ว่า Control จะไม่ปรากฏในชื่อก็ตาม "

โดยทั่วไปแล้วสิ่งนี้จะออกกฎโดยปริยายโดยใช้ "ฐาน" ในชื่อ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.