อนุสัญญาการตั้งชื่อโปรโตคอล Swift [ปิด]


53

มาจากพื้นหลังส่วนใหญ่ c # ฉันเคยใช้คำว่า "อินเตอร์เฟส" สำหรับการอธิบายวัตถุที่ไม่มีการใช้งานที่กำหนดพฤติกรรม ใน c # การประชุมคือการเพิ่มชื่อส่วนต่อประสานด้วย "I" เช่นในIEnumerableเป็นต้น

แน่นอนว่าแนวคิดนี้มีชื่อแตกต่างกันในภาษาต่างๆ ใน Swift แนวคิดเดียวกันนี้เรียกว่า "โปรโตคอล" เมื่อฉันพัฒนาโปรโตคอลฉันมักจะมีชื่อคล้ายกันมากสำหรับโปรโตคอลและคลาสที่ใช้งานมัน จนถึงตอนนี้ฉันได้ต่อท้ายคำว่า "โปรโตคอล" กับวัตถุเหล่านี้ในลักษณะเดียวกับที่ฉันใช้ "I" ใน c #, ในEnumerableProtocol, ฯลฯ

มีความคิดเห็นเกี่ยวกับการตั้งชื่อโปรโตคอลสำหรับโพรโทคอลอย่างรวดเร็วหรือไม่?



โดยทั่วไปคำศัพท์ที่ใช้ในชื่อโปรโตคอลควรถ่ายทอดความสามารถ Equatableเรียนสามารถ equated, NSCopyingเรียนสามารถโดยการคัดลอก ฯลฯ ยกเว้นอย่างเดียวที่อยู่ในใจเป็นผู้ได้รับมอบหมายและแหล่งข้อมูลที่มีหรือSomethingDelegate SomethingDataSourceฉันคิดว่าความแตกต่างคือชั้นเรียนที่เป็นเจ้าของจะมีบางอย่างที่เหมือนvar dataSource: SomethingDataSourceกัน แต่คุณจะไม่เห็นอะไรเช่นvar foo: Equatableนั้น
Ben Leggiero

คำตอบ:


82

สวิฟท์ได้ครบกำหนดอย่างมีนัยสำคัญในปีที่ผ่านมาตั้งแต่คำตอบนี้ถูกเขียน แนวทางการออกแบบระบุว่า :

  • โปรโตคอลที่อธิบายสิ่งที่ควรอ่านเป็นคำนาม (เช่นCollection)

  • โปรโตคอลที่อธิบายความสามารถควรจะตั้งชื่อโดยใช้คำต่อท้ายable, ibleหรือing(เช่นEquatable, ProgressReporting)

ขอบคุณDavid James ที่ให้ความสำคัญกับเรื่องนี้!

คำตอบเดิม

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

ในกรณีที่ไม่มีไกด์สไตล์อย่างเป็นทางการสำหรับ Swift เราต้องหาตัวเราเองหรือยืมจากไกด์หรือรหัสที่มีอยู่ ตัวอย่างเช่นคู่มือสไตล์ Objective-C สำหรับ Cocoa มีส่วนนี้:

ชื่อคลาสและโปรโตคอล

โปรโตคอลควรตั้งชื่อตามลักษณะการทำงานของกลุ่ม:

  • โปรโตคอลส่วนใหญ่จัดกลุ่มวิธีการที่ไม่เกี่ยวข้องกับคลาสใดโดยเฉพาะ ควรตั้งชื่อโปรโตคอลประเภทนี้เพื่อไม่ให้โปรโตคอลสับสนกับคลาส หลักการทั่วไปคือการใช้แบบฟอร์ม gerund (“ ... ไอเอ็นจี”):

    NSLocking- ดี
    NSLock- แย่ (ดูเหมือนชื่อสำหรับชั้นเรียน)

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

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

อย่างไรก็ตามคำแนะนำของจุดที่สองไม่สามารถใช้งานได้อีกต่อไป:

เนื่องจากเนมสเปซของคลาสและโพรโทคอลถูกรวมเป็นหนึ่งเดียวใน Swift NSObjectโพรโทคอลใน Objective-C จะถูกแมปใหม่NSObjectProtocolในใน Swift (ที่มา )

ที่นี่…Protocolคำต่อท้ายถูกนำมาใช้เพื่อแยกแยะโปรโตคอลจากชั้นเรียน

ห้องสมุดมาตรฐานสวิฟท์มีโปรโตคอลEquatable, และComparable Printableสิ่งเหล่านี้ไม่ได้ใช้แบบฟอร์ม“ … ing” ของ Cocoa แต่ต่อท้าย“ …สามารถ” เพื่อประกาศว่าอินสแตนซ์ใด ๆ ของประเภทนี้จะต้องสนับสนุนการดำเนินการบางอย่าง


ข้อสรุป

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

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

ชื่อEquatableProtocolนี้ไม่แนะนำให้ใช้ ชื่อEquatableหรือEquatingจะไกลดีกว่าและผมไม่ได้คาดหวังระดับใด ๆ Equatableที่จะมีชื่อ ในกรณีนี้Protocolคำต่อท้ายคือเสียงรบกวน


6
FooDelegate ก็เป็นเรื่องธรรมดาเช่นกัน (อย่างน้อยก็สำหรับผู้ได้รับมอบหมายซึ่งมักจะเป็นโปรโตคอล ... อาจจะเป็นจริงเสมอ)
Stripes

3
ตามแนวทางการออกแบบ Swift API: swift.org/documentation/api-design-guidelines >> โปรโตคอลที่อธิบายสิ่งที่ควรอ่านว่าเป็นคำนาม (เช่นชุดสะสม) >> โปรโตคอลที่อธิบายความสามารถควรตั้งชื่อโดยใช้คำต่อท้ายที่สามารถใช้งานได้หรือไอเอ็นจี (เช่น Equatable, ProgressReporting)
David James

1
@ ฉันจะตั้งชื่อโปรโตคอลอย่างไรสำหรับคลาส BluetoothService หรือ UserDataManager "... ไอเอ็นจี" หรือ "... สามารถ" ไม่พอดีที่นี่และฉันต้องการหลีกเลี่ยงคำต่อท้าย "โปรโตคอล" ความคิดใด ๆ ตามหลักเกณฑ์การออกแบบของ Api โปรโตคอลควรเป็นคำนามเช่น BluetoothService ในกรณีนี้ แต่ชื่อใดควรมีการนำไปใช้ BluetoothServiceImpl? Btw หลังจากหลายตัวอย่างที่ฉันเห็นฉันคิดว่า C # มีการเชื่อมต่อที่ดีที่สุดด้วยคำนำหน้า "I" เช่น IAnything, IEquatable, ISmthAware: D
Wojciech Kulik

1
@WojciechKulik ฉันไม่แน่ใจว่าชื่อที่ดีในกรณีของคุณคืออะไร มากขึ้นอยู่กับวิธีการใช้โปรโตคอลเหล่านั้น อย่างไรก็ตาม ... ชื่อบริการและ ... ผู้จัดการอาจเป็นกลิ่นรหัส - ชื่อนั้นเหมือนกันถ้าคุณลบคำต่อท้ายนั้น บางชื่อที่ต้องพิจารณา: บลูทู ธ , บลูทู ธ เชื่อมต่อ, บลูทูธrotocol, UserData, UserDataRepository, UserDataWriting, UserDataProtocol
amon

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