การตั้งชื่ออินเทอร์เฟซ: คำนำหน้า 'Can-' เทียบกับคำต่อท้าย 'สามารถ'

29

เป็นเรื่องปกติที่จะใช้ '-able' เป็นคำต่อท้ายสำหรับอินเทอร์เฟซเช่น

สามารถยิงได้แบบหมุนได้

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

เช่น 1หมายถึง Shootable หมายความว่าวัตถุสามารถยิงได้ (ปืนอาจใช้สิ่งนี้) หรือหมายความว่าสามารถยิงได้ (บอร์ดเป้าหมายอาจใช้สิ่งนี้) ด้วยคำนำหน้า 'Can-' อดีตจะเป็น "CanShoot" และส่วนหลังจะเป็น "CanBeShotAt" หรือ "CanShootAt"

เช่น 2เอกสาร 'CanBePrinted' และเครื่องพิมพ์ 'CanPrint'

หรือเราควรใช้ '-Able' และให้เอกสารอธิบายบริบทหรือไม่

ความคิดเห็นใด ๆ

api interfaces

— MustafaM
แหล่งที่มา

ผู้ชายให้ใช้ "-able" ระยะเวลา

— Tulains Córdova

2

ใช้ทั้งสำหรับclass Cannibal implements Can, Able {}

— Thomas Eding

18

บางทีคุณอาจต้องการ

ตัวอย่างจาก. Net:

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

ดูเหมือนจะไม่เป็นมาตรฐานที่สม่ำเสมอ ไปกับสิ่งที่อ่านดี

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

แก้ไข:ตามที่ระบุไว้คำถามเกี่ยวกับการเชื่อมต่อไม่ใช่คุณสมบัติ

ในกรณีนั้นฉันไม่พบอินเทอร์เฟซที่ชื่อ Can- ส่วนต่อประสานมักใช้งานได้ดี ฉันเห็นด้วยกับคำศัพท์นี้ วิธีการอาจขอเป็นพารามิเตอร์หรือISerializable object IPrintable documentการขอICanBeSerialized objectหรือการICanBePrinted documentอ่านเป็นสิ่งที่อึดอัดใจมาก

ในด้านอื่น ๆ , IPrinterเครื่องพิมพ์ผมขอแนะนำเพียงโทรติดต่อ วิธีการของคุณจะขอIPrinter deviceวิธีการของคุณจะถูกขอ

อ่านวิธีการด้านล่างดัง ๆ (โดยส่วนตัวแล้วฉันคิดว่าคำนำหน้า "ฉัน" จะเงียบ) มันอ่านได้ดีหรือไม่? มันฟังดูใช่มั้ย

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

— มือ-E-อาหาร
แหล่งที่มา

2

Document.IsPrintable ดีกว่า Document.CanBePrinted เท่าที่ฉันสามารถบอกได้ว่าพวกเขาใช้งานได้ดีเพื่อหลีกเลี่ยงเสียงที่ไม่โต้ตอบ

— Thanos Papathanasiou

"สามารถพิมพ์ได้" ดูเหมือนว่าภาษาอังกฤษที่เหมาะสมกว่า "สามารถพิมพ์ได้"

— Danny Varod

1

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

— Thanos Papathanasiou

3

ฉันเห็นว่านี่เป็นคำตอบที่ยอมรับได้ แต่นี่ไม่ได้ตอบคำถามของ OP ตัวอย่างที่มีให้คือชื่อคุณสมบัติ สหกรณ์จะขอประชุมการตั้งชื่อสำหรับการเชื่อมต่อของชื่อเช่นISerializable, และIDataErrorInfo INotifyPropertyChanged

— Kevin McCormick

@KevinMcCormick จุดดี! แก้ไขด้านบน

— Hand-E-Food

23

การพูดตามหลักไวยากรณ์ "canFoobar" เป็นคำกริยาในขณะที่ "Foobarable" เป็นคำคุณศัพท์หรือคำนาม (มักเป็นคำนามในบริบทของ API)

โปรดสังเกตความแตกต่างที่ละเอียดอ่อน: - หมายถึงบทบาทแฝงกับคำนามที่นำไปใช้นั่นคือถ้าบางสิ่งนั้นเป็น Foobarable จากนั้นก็สามารถเป็นอย่างอื่นโดย foobarred; สามารถแสดงถึงบทบาทที่กระตือรือล้นนั่นคือถ้ามีอะไรบางอย่างที่สามารถโฟโนบาร์ได้มันก็จะทำให้เกิดสิ่งอื่นได้ หรือจากมุมที่แตกต่าง: ถ้า A สามารถ foobar B แล้วA.canFoobar()และB is Foobarableและ

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

instance.canFoobar();

class Something implements Foobarable { ... }

— tdammers
แหล่งที่มา

7

ส่วนตัวฉันจะติดกับรุ่นที่ใช้งานได้ นี่คือเหตุผลของฉัน: บรรณาธิการกราฟิก (ส่วนใหญ่?) ส่วนใหญ่แนะนำตัวระบุตามสิ่งที่คุณพิมพ์ แม้ว่าบางส่วนของพวกเขาจะ 'ฉลาด' พอที่จะค้นหาตัวระบุภายในได้ แต่บางคนก็แค่เสนอจุดเริ่มต้นการค้นหาของตัวระบุ

หากต้องการเพิ่มความเร็วในการพิมพ์คุณจะต้องย่อรายการตัวระบุที่แนะนำด้วยการกดปุ่มให้น้อยที่สุดเท่าที่จะทำได้ ตัวระบุเพิ่มเติมจะมีจุดเริ่มต้นเหมือนกันเช่น 'ICan-' ตัวอักษรที่คุณจะต้องพิมพ์

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

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

อย่าลืมว่าเครื่องมือการรีแฟคเตอร์ที่ดีช่วยให้คุณเปลี่ยนชื่อได้บ่อยเท่าที่คุณต้องการ ดังนั้นจึงง่ายต่อการทดสอบด้วยวิธีการที่แตกต่างกัน

— Manfred
แหล่งที่มา

1

+1 เหตุผลของฉันจะเหมือนกันให้ใส่กริยาควบคุมก่อนเพื่อให้ง่ายต่อการค้นหา / ค้นหา / เรียงลำดับใน IDE

— Pap

1

Intellisense ไม่เพียงทำงานด้วยวิธีการดังกล่าวเท่านั้น แต่ยังมีการสแกนข้อความของมนุษย์ด้วยคำนำหน้าทำให้รหัสของคุณอ่านง่ายขึ้น

— jk

7

เห็นได้ชัดว่าคำนำหน้าและคำต่อท้ายเป็นตัวเลือกที่ชัดเจนสำหรับการกระทำประเภทต่างๆหรือทิศทางที่แตกต่างกันการดำเนินการที่

การใช้งานและค่ากำหนดปัจจุบันอาจไม่สอดคล้องกันเนื่องจากหลายสาเหตุ

การกระทำดำเนินการโดยวัตถุ:
CanShoot -> มันยิง (ที่) บางสิ่ง
CanFly -> มันบิน
CanChange -> มันเปลี่ยน

มีการดำเนินการกับวัตถุ:
อ่านได้ -> คุณสามารถอ่าน
เขียนได้ -> คุณสามารถเขียน (ถึง)
พิมพ์ได้ -> คุณสามารถพิมพ์ได้

แม้ว่ามันอาจจะไม่ได้เป็นกฎหรือจำเป็นต้องมีเหตุผล แต่ก็ช่วยให้นำมาใช้ในการประชุมและรักษาความสอดคล้องของการใช้งานในการตั้งชื่อตัวแปร

— คริส
แหล่งที่มา

4

ฉันคิดว่าคุณอาจต้องการแยกความแตกต่างระหว่างความสามารถและการอนุญาต ในขณะที่SerializableและCanSerializeบ่งบอกว่าสิ่งที่เป็นความสามารถในการต่อเนื่องนอกจากนี้ยังมีปัญหาเกี่ยวกับสิทธิ์ (หรืออาจจะขาดพื้นที่ดิสก์) MaySerializeและคุณอาจจำเป็นที่จะต้องพิจารณา ออกจากสิ่งที่~ableเอาความจำเป็นที่จะแยกแยะความแตกต่างระหว่างและcanmay

— Tangurena
แหล่งที่มา

SerializableIfNotDiskFullAndIfNotPermissionMissing ... ฮ่า ๆ :)

— สูงสุด

2

เมื่อคลาสย่อย / อินเทอร์เฟซที่ใช้งานฉันคิดว่ากฎง่ายๆคือคุณควรจะสามารถพูดว่า "B is a" (โดยที่ B ใช้ A) มันไม่ถูกต้องที่จะพูด:

A DocumentคือCanBePrinted

แต่ฟังดูดี (หรืออย่างน้อยก็ดีกว่า) ที่จะพูดว่า:

A DocumentคือPrintable

— Gyan aka Gary Buyn
แหล่งที่มา

2

ฉันคิดว่าทั้ง Xable Grammar-wise และ Vable-ระเบียบ Xable นั้นดีกว่าสำหรับชื่อของอินเตอร์เฟสในขณะที่ IsX, CanX, DoesX ดีกว่าสำหรับชื่อของคุณสมบัติ

จาก MSDN:

"ทำชื่อคุณสมบัติบูลีนด้วยวลียืนยัน (CanSeek แทนที่จะเป็น CantSeek) หรือคุณสามารถเติมคำนำหน้าคุณสมบัติบูลีนด้วย Is, Can หรือ Has ได้ แต่จะเพิ่มมูลค่าได้ที่ไหน" http://msdn.microsoft.com/en-us/library/ms229012.aspx

— Danny Varod
แหล่งที่มา

+1 สำหรับลิงก์ที่มีประโยชน์ ฉันไม่สามารถคิดออกว่าจะตั้งชื่ออะไร

— CamelBlues

0

ในความคิดของฉันตัวแปร "-able" นั้นสามารถอ่านได้มากขึ้นดังนั้น CanDoSomething ของคุณที่เสนอมาซึ่งกำหนดอูม humps มากขึ้น

— นกนางแอ่น
แหล่งที่มา

1

และ Can- เป็นชื่อเมธอดมากขึ้น

— ratchet freak

ชื่อคุณสมบัติ - ดู MSDN ชื่อวิธีการควรเป็น "คำกริยาหรือวลีกริยา" นอกจากนี้มีอะไรผิดปกติกับ humps หลาย ๆ ตัว?

— Danny Varod

0

ใน Scala *Ableใช้สำหรับอินเตอร์เฟส แต่Can*ใช้สำหรับรูปแบบคลาสชนิด เป็นหลักเพื่อให้สามารถเรียกวิธีการบางอย่างค่านัยของประเภทที่แน่นอนจะต้องมีอยู่ในขอบเขต บางครั้งชื่อของประเภทนี้จะCanขึ้นต้นด้วย

— axel22
แหล่งที่มา

Can * ไม่ใช่ชื่อที่ดีสำหรับชั้นเรียน อ้างจาก MSDN: "สนใจชื่อคลาสอินเทอร์เฟซและประเภทค่าที่มีคำนามวลีคำนามหรือวลีคำคุณศัพท์เป็นครั้งคราวโดยใช้ปลอก Pascal" ลิงก์: msdn.microsoft.com/en-us/library/ms229040.aspxชื่อที่ดีสำหรับ ชั้นจะเป็นเอกสารชื่อที่ยอมรับได้จะสามารถพิมพ์ได้

— Danny Varod

ตัวอย่างหนึ่งในภาษา Scala CanBuildFromเป็น นี่จะเป็นวลีที่เป็นคำคุณศัพท์ กรณีใช้ของคลาสนี้แตกต่างจากคลาสอื่นอย่างมาก อินสแตนซ์ของคลาสนี้แทบไม่เคยสร้างหรือแก้ไขโดยไคลเอนต์ - แต่จะมีอยู่ในขอบเขตสำหรับบางประเภท หากพวกมันพร้อมใช้งานสำหรับบางประเภทแล้ววิธีการที่เกี่ยวข้องกับประเภทที่มีการทำเครื่องหมายเพื่อต้องการประเภทนี้สามารถเรียก สิ่งนี้มีอยู่เพื่อเสนอกลไกการขยายความยืดหยุ่นมากกว่าการพิมพ์ย่อย ดูscala-lang.org/node/114

— axel22

ฉันจำได้ว่าใช้วลีคำคุณศัพท์สำหรับคลาสจำลองที่ใช้อินเทอร์เฟซสำหรับการทดสอบหน่วย - เนื่องจากพวกเขาไม่มีบทบาทจริง

— Danny Varod