Swift-style-guide: تسمية البروتوكول

تم إنشاؤها على ٧ ديسمبر ٢٠١٥  ·  9تعليقات  ·  مصدر: raywenderlich/swift-style-guide

هل هناك طريقة مفضلة لتسمية البروتوكولات؟ مثل استخدام اللاحقة "يمكن" أو "جي". لقد صادفت سؤال StackExchange بإجابة جيدة جدًا.

هل يجب إضافة هذا إلى دليل الأسلوب؟

التعليق الأكثر فائدة

يبدو أن لاحقة "النوع" تسير في طريق الديناصور على الرغم من أنني اعتقدت أنني رأيت اقتراحًا يطير لاستخدام "Protocol" كما يفعل mitchellporter .

من إرشادات تصميم Swift API :

البروتوكولات التي تصف الشيء يجب أن تقرأ كأسماء (مثل المجموعة). يجب تسمية البروتوكولات التي تصف قدرة باستخدام اللواحق "الممكنة" أو "القابلة" أو "جي" (مثل Equatable أو ProgressReporting).

ال 9 كومينتر

أعتقد أنه سيكون من الصعب ترجمة نمط اسم C # إلى Swift. يعمل 'I' للواجهة في .NET نظرًا لاختلافات مساحة الاسم.

بالنسبة إلى gerunds ("قادر" و "جي") ، أعتقد أنهم يعملون بشكل مشابه كما في اللغة الإنجليزية:
"gerund هو اسم مكون من فعل بإضافة" -ing ".

على سبيل المثال: أحتاج إلى تجزئة (فعل) هذه الفئة ، هل هي قابلة للتجزئة (gerund)؟ أريد مقارنة (فعل) ، هل هذه الفئة قابلة للمقارنة (gerund)؟

إذا نظرت إلى C # ، فإنها لا تستخدم gerund لجميع الواجهات أيضًا. خذ Point (class) و IPoint (الواجهة التي تنفذ X و Y). جعل شيء ما يمكن توجيهه سيكون مضللاً بعض الشيء.

تعتبر البروتوكولات مثل UITableViewDelegate و UITableViewDataSource جيدة بالنسبة لي. أنا شخصياً ليس لدي أي مشاكل مع ... لاحقة البروتوكول ولكني لا أريدها كقاعدة عامة. أحيانًا تعمل كلمة "قادر" بشكل أفضل ، وأحيانًا تكون اللواحق الأخرى منطقية مثل ... مفوض أو ... مصدر البيانات.

أعتقد أنه إذا تم إنشاؤها اليوم ، فسيتم تسميتها UITableViewDelegateType و UITableViewDataSourceType. يسمي جريج هيو هذا "هو": http://www.skilled.io/gregheo/what-the-55-swift-standard-library-protocols-taught-me

تتضمن العديد من البروتوكولات الخاصة بي وظيفة أو خاصية واحدة فقط. ليس لدى Swift مشكلة في تسمية البروتوكول بنفس الاسم ، وأعتقد أن هذا نهج نظيف للغاية.

protocol bool {
   var bool: Bool {get}
}

struct Struct: bool {
   let bool = true
}

سأستخدم المفوض العادي واصطلاح تسمية مصدر البيانات عند الحاجة ، ولكن بالنسبة للبروتوكولات التي تُستخدم ببساطة لتكوين كائنات ، فقد قمت للتو بوضع Protocol في الاسم. لست متأكدًا مما إذا كانت هذه هي أفضل الممارسات أم لا ، عندما بحثت عنها لم أجد أي معلومات.

protocol AlertModalProtocol {
func titleText() -> String
func messageText() -> String
}

struct NewUserAlertModal: AlertModalProtocol {

    func titleText() -> String {
        return "Welcome new user"
    }

    func messageText() -> String {
        return "Thanks for joining the app."
    }
}

يبدو أن لاحقة "النوع" تسير في طريق الديناصور على الرغم من أنني اعتقدت أنني رأيت اقتراحًا يطير لاستخدام "Protocol" كما يفعل mitchellporter .

من إرشادات تصميم Swift API :

البروتوكولات التي تصف الشيء يجب أن تقرأ كأسماء (مثل المجموعة). يجب تسمية البروتوكولات التي تصف قدرة باستخدام اللواحق "الممكنة" أو "القابلة" أو "جي" (مثل Equatable أو ProgressReporting).

ذلك مثير للاهتمام. من واقع خبرتي ، كانت هناك حاجة إلى ThingType عندما يكون Thing تقليديًا فئة غير مجردة. (على سبيل المثال ، Thing هو نوع ملموس ينفذ ThingType ، وأنواع أخرى أكثر تحديدًا تنفذ أيضًا ThingType.) NSObjectProtocol هو مثال على هذا النوع من الأشياء.

سأضيف بعض النصوص على غرار مسودة إرشادات تصميم واجهة برمجة التطبيقات.

سويفت
أثناء مشاهدة كود شخص آخر ، واجهت مشكلة ، تلك البروتوكولات التي تصف ، ما هي ، عندما تكون أسماء ، غير مريحة بهدوء ، لأنني غالبًا ما أخلطها مع طرق الفصل. لحل هذه المشكلة ، أعتقد أن أفضل طريقة لاستخدام القاعدة التالية:

When the protocol name is a noun - write ..Protocol (yes, even in swift);
على سبيل المثال ، PhotoModuleProtocol
When the protocol is an adverb or an adjective - write ..able, ..ing and so on;
على سبيل المثال قابل للاختبار

في رأيي ، من الأفضل الآن صراحة ما هو العد التنازلي للتعرف على رمز شخص ما ، من أشياء Swift hipster.

لقد نشرت تعليقي الأخير في عام 2015 ... منذ ذلك الحين ، انتقلت إلى استخدام ما شاركتهgregheo سابقًا:

البروتوكولات التي تصف الشيء يجب أن تقرأ كأسماء (مثل المجموعة). يجب تسمية البروتوكولات التي تصف قدرة باستخدام اللواحق "الممكنة" أو "القابلة" أو "جي" (مثل Equatable أو ProgressReporting).

لذلك على سبيل المثال ، عادةً ما يكون هناك نوع نموذج أساسي يبدو كالتالي:

protocol BaseType {
    var objectId: String { get set }
    var createdAt: NSDate? { get set }
    var updatedAt: NSDate? { get set }
    func toJSON() -> [String: AnyObject]
    static func from(json: [String: AnyObject]) -> AnyObject
}

نظرًا لأن جميع الطرز في جميع أنحاء التطبيق ستحتاج إلى هذه الوظيفة ، فستتوافق جميعها مع BaseType . لقد قمت بالفعل بتسمية هذا النوع الأساسي بعد اسم التطبيق ، لذلك إذا كان اسم تطبيقك Instagram فسيكون InstagramType . الآن بعد أن أفكر في هذا ، يبدو أن تضمين Type في الاسم لا معنى له ... لا يوجد سبب يمنعك من تسميته BaseModel أو InstagramModel أو حتى Model .

أما بالنسبة للبروتوكولات التي تصف القدرات ، فقد كنت أستخدم لاحقات النوع "قادرة" و "ible" و "جي" أيضًا.

توقفت عن استخدام كلمة protocol في أسمائي لأنها شعرت بأنها زائدة عن الحاجة وشعرت أيضًا أنني كنت أستخدمها لتسهيل فهم أي شخص "مرحبًا ، هذا بروتوكول ، وليس فصلًا" الذي شعرت به خطأ لأنه من المفترض أن ينظر إلى البروتوكولات على أنها مساوية للفئات ، إن لم تكن فوقها ، بسرعة.

لذا بدلاً من تمييزها عن طريق تضمين البروتوكول في الاسم ، أتركها فقط. هذا هو بالضبط ما أشعر به صحيحًا بالنسبة لي ، فأنا لا أدعي أن أيًا من هذا صواب أو خطأ. حتى بعد مرور سنوات ، كنت دائمًا أكتشف أشياء جديدة في Swift وقد تخليت عن محاولة اكتشاف كل شيء. مجرد محاولة للتجربة ومعرفة ما سيأتي به المجتمع في هذه المرحلة :)

ومع ذلك ، فإن تسمية البروتوكولات حسب الاسم ينتج عنها إضافة بعض الكلمات (يمكن أن تكون "..Model" ، "..Type" وما إلى ذلك) لتحديد أنها بروتوكول وليس فئة. يتغير فقط في نوع هذه الكلمة المراد استخدامها =)

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات