Swift-style-guide: اقتراحات للمراجعة القادمة

هل تضع علامة على @IBOutlets خاصتك لنفس السبب؟

أنا ممزق قليلاً بشأن هذا. من ناحية أخرى ، يمكن اعتبار @IBActions علنيًا نظرًا لتعرضهم للواجهة. من ناحية أخرى ، لا يوجد سبب وجيه لفضحهم وفي Obj-C ، أقوم دائمًا بإلصاقهم في ملف الطريقة. هناك اعتبار آخر هو أن المنافذ والإجراءات التي يتم سحبها من الوسيط المعرف (IB) يتم الإعلان عنها دائمًا على أنها داخلية / عامة.

أفترض أننا يجب أن نسأل أنفسنا ما إذا كانت فكرة جيدة لبناء تبعية على علامة @objc بالرغم من ذلك أم لا.

ها هي أفكاري:

1) أنا ضد استخدام علامة @objc . يتحرك Swift بنشاط بعيدًا عن Objective-C ، وكذلك البرامج التعليمية لـ RW.

2) فيما يتعلق بوضع علامة @IBAction و / أو @IBOutlet كـ private كقاعدة عامة في الدروس ، لا أعتقد أنني أحب هذا أيضًا.

في مشاريعي الخاصة ، نعم ، أقوم بتقييد النطاق قدر الإمكان. ومع ذلك ، لا أعتقد أن هذا هو المفهوم الأساسي في _ Most_ من دروس القراءة والكتابة.

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

أيضًا ، أعتقد أن هذا سيضيف فقط خطوة تحرير تقنية أخرى إلى عمليات التحقق العديدة التي نقوم بها بالفعل ، ومرة ​​أخرى ، أتساءل عن مقدار القيمة التي ستوفرها حقًا في البرامج التعليمية.

IMHO ، أعتقد أننا يجب أن نذعن للمؤلف والمحرر التقني في النطاق لـ @IBAction و @IBOutlet s بدلاً من وجود قاعدة عليها.

بقدر ما أعلم ، يجب عليك استخدام علامة objc لتتمكن من تمييز وظيفة المحدد على أنها خاصة.

نعم ، أنا بالتأكيد أضع علامة IBOutlets الخاصة بي. إنها تفاصيل تنفيذ لا ينبغي عرضها للمتصلين الخارجيين ما لم يكن ذلك ضروريًا للغاية.

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

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

شكرا لردود الفعل والاقتراحات.

لا تحتاج طرق @objc إلى إرسال ديناميكي كامل ليتم تمييزها على أنها خاصة. التحكم في الوصول والإرسال غير مرتبطين. على سبيل المثال ، الأعمال التالية:

    <strong i="8">@IBAction</strong> private func buttonTapped(sender: UIButton) {
    }

أظن أن لديك شيئًا آخر في ذهنك ، وأود أن أفهمه.

ملاحظة:
فيما يتعلق بالغرض من الدليل ، أعتقد أنه ورد بوضوح تام في الفقرة الأولى. أنا شخصياً أستخدم نسخة متشعبة منه في مشاريعي الخاصة مع تعديلات على قاعدة التباعد ورأس حقوق النشر وبعض قواعد UIKit و IB الإضافية. أعتقد أنه يمكن استخدامه غالبًا كنقطة انطلاق.

تشير المشكلة grosch إلى استخدام المحددات.
let recognizer = UITapGestureRecognizer(target: self, action: #selector(buttonTapped(_:)))

لكي يكون المحدد خاصًا ، يجب أن يكون إما:
<strong i="10">@objc</strong> private func buttonTapped(sender: UITapGestureRecognizer)
أو
private dynamic func buttonTapped(sender: UITapGestureRecognizer)

آه ، فهمت الآن. شكرا! 👋
الأساليب المميزة بعلامة private من فئة متوافقة مع Obj-C لا يتم إرسالها ديناميكيًا (أي ليست محددات). بطريقة ما ، فإن الدليل الحالي يغطي بالفعل هذا بالفعل. يجب وضع علامة على الأشياء الخاصة بشكل عام على أنها خاصة لتحسين الوضوح. راجع https://github.com/raywenderlich/swift-style-guide#access -control
بمجرد وضع علامة private ، فإنها تكون عبارة عن تفاصيل تنفيذ خاصة بالفئة. إذا كنت بحاجة إلى الإشارة إليه كمحدد في مكان ما ، فلن يكون لديك حقًا خيار سوى اختياره. أعتقد أنه من الأفضل أن تكون كسولًا بشأن هذا الجزء الثاني لأنه مع Swift 3 ... (عفوًا ، أعني Swift 4) مرونة ABI ، لن يكون تغيير الطريقة الخاصة تغييرًا جذريًا. أيضًا ، من خلال تمييز الطرق الخاصة بـ @objc ، فأنت بذلك تمنع المُحسِّن من التضمين ، وما إلى ذلك ، لذلك هناك جانب سلبي كبير للقيام بذلك.