متى أحدد أساليب Objective-C؟

Question

أنا أتعلم الهدف-C ، ولدي خلفية C/C ++.

• في C ++ الموجهة للكائنات ، تحتاج دائمًا إلى إعلان طريقتك قبل تحديد (تنفيذ) ، حتى لو تم الإعلان عنها في الفئة الأصل.

• في النمط الإجرائي ، IIRC ، يمكنك الابتعاد عن مجرد تحديد وظيفة طالما تسمى فقط من شيء آخر في نفس وحدة التجميع (أي نفس الملف) الذي جاء لاحقًا في الملف (جيدًا ، يتم توفيره أنت لا تعلن ذلك في مكان آخر مع "extern").

• الآن ، في Objective-C ، يبدو أنك بحاجة فقط إلى إعلان المحددين في ملف الرأس إذا تم استخدامهم من قبل شيء خارجي ، ويمكنك تعويض محددات في ملف .M الخاص بك على ما يرام ، والاتصال بهم ملف .M. أيضًا ، يبدو أن أساليب المفوض أو الأساليب الموروثة لا يتم تعريفها أبدًا.

هل أنا على الطريق الصحيح؟ متى تحتاج إلى تحديد محدد في Objective-C؟

Answer 1

بالنسبة لأساليب الهدف-C ، فإن الممارسة العامة هي وضع الأساليب التي ترغب في فضحها في @interface قسم ملف الرأس بحيث يمكن أن يتضمن التعليمات البرمجية الأخرى فقط .h ومعرفة كيفية التفاعل مع الكود الخاص بك. يعمل "الإعلان الكسول" القائم على الطلبات تمامًا مثل الوظائف في C-أنت لا تفعل ذلك يجب أن أعلن عن نموذج أولي ما لم يكن لديك تبعية لا يمكن حلها عن طريق الطلب ، ولكن يمكنك إضافة نماذج أولية للسيارة داخل @implementation إذا لزم الأمر.

لذا نعم ، أنت على المسار الصحيح. لا تكرر النموذج الأولي للطريقة للطرق الموروثة - يجدها المترجم في ملف رأس الوالد. يمكن تعريف طرق المندوب على أنها نماذج أولية في فئة (تم نقلها على فئة) وتنفيذها حسب الرغبة ، لكن المندوب لا يحتاج إلى توفير نموذج أولي ، لأنه تم تعريفه بالفعل. (لا يزال بإمكانه إذا أراد أن يوضح الوضوح ، وما إلى ذلك)

نظرًا لأنك تتعلم فقط الهدف-C ، فإن بقية هذه الإجابة هي تفاصيل أكثر بكثير مما طلبت. لقد تم تحذيرك. ؛-)

---

عندما تكتب بشكل ثابت متغير (على سبيل المثال MyClass* بدلاً من id) سوف يحذرك المترجم عندما تحاول استدعاء طريقة تفيد بأن الفصل لا يعلن أنه يتناسب ، سواء كان ذلك أم لا. إذا قمت بكتابة المتغير ديناميكيًا ، فلن يمنعك برنامج التحويل البرمجي من الاتصال بكل ما تريده ، وستحصل فقط على أخطاء في وقت التشغيل إذا اتصلت بشيء غير موجود. فيما يتعلق باللغة ، يمكنك استدعاء أي طريقة تنفذها الفصل دون أخطاء في وقت التشغيل - لا توجد طريقة لتقييد من يمكنه استدعاء طريقة.

أنا شخصياً أعتقد أن هذا أمر جيد في الواقع. لقد اعتدنا على التغليف وحماية التعليمات البرمجية الخاصة بنا من التعليمات البرمجية الأخرى التي نعاملها أحيانًا المتصل باعتباره كونيًا مرهقًا بدلاً من زميل في العمل أو العميل الجدير بالثقة. أجد أنه من الممتع للغاية أن ترمز مع عقلية "أنت تقوم بعملك وأقوم بعمل" حيث يحترم الجميع الحدود ويعتني بأشياءهم الخاصة. قد تقول إن "موقف" Objective-C هو واحد من ثقة المجتمع ، بدلاً من إنفاذ صارم. على سبيل المثال ، يسعدني أن أساعد أي شخص يأتي إلى مكتبي ، لكن سيشتاق حقًا إذا أفسد شخص ما أشيائي أو نقل الأشياء دون أن يسأل. لا يجب أن يكون الكود المصمم جيدًا بجنون العظمة أو الاجتماعية ، بل يجب أن يعمل بشكل جيد معًا. :-)

ومع ذلك ، هناك العديد من الأساليب لتنظيم واجهاتك ، اعتمادًا على مستوى التفاصيل التي تريدها/تحتاجها في تعريض واجهات للمستخدمين. أي طرق تعلن في الرأس العام هي لعبة عادلة بشكل أساسي لأي شخص لاستخدامها. إن إعلانات طريقة الاختباء تشبه إلى حد ما قفل سيارتك أو منزلك - ربما لن تبقي الجميع خارجًا ، ولكن (1) "يبقي الناس صادقين" من خلال عدم إغراءهم بشيء لا ينبغي أن يعبث به ، (2 ) أي شخص يفعل سيعرف Get In Swere أنهم لم يكن من المفترض ، ولا يمكنهم حقًا تقديم شكوى من العواقب السلبية.

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

• MyClass.h - واجهة برمجة التطبيقات العامة (واجهة برمجة التطبيقات)
• MyClass_Private.h -الشركة الداخلية SPI (واجهة برمجة النظام)
• MyClass_Internal.h -مشروع IPI الداخلي للمشروع (واجهة البرمجة الداخلية)
• MyClass.m - التنفيذ ، بشكل عام لجميع إعلانات API/SPI/IPI
• MyClass_Foo.m - تنفيذ إضافي ، مثل الفئات

API هو استخدام الجميع ، ويتم دعمه للجمهور (عادة في Foo.framework/Headers). يعرض SPI وظائف إضافية للعملاء الداخليين من الكود الخاص بك ، ولكن مع فهم أن الدعم قد يكون محدودًا وأن الواجهة تخضع للتغيير (عادة في Foo.framework/PrivateHeaders). يتكون IPI من تفاصيل خاصة بالتنفيذ لا ينبغي استخدامها أبدًا خارج المشروع نفسه ، ولا يتم تضمين هذه الرؤوس في الإطار على الإطلاق. أي شخص يختار استخدام مكالمات SPI و IPI يفعل ذلك على مسؤوليته الخاصة ، وعادة ما يكون على حسابه عندما تحطم التغييرات الكود. :-)

Answer 2

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

أيضًا ، إذا قمت بتحديد طريقة في ملف .m فوق أي رمز يطلق عليه (إعلان كسول) ، فلن يولد أي تحذيرات. ومع ذلك ينطبق الشيء نفسه ، يمكنك إرسال رسالة إلى كائن دون الإعلان عنها.

بالطبع - هذا يعني أنه لا توجد طرق خاصة في Objective -C. يمكن استدعاء أي طريقة تنفذها الفصل.

تفضيل شخصي. إذا كانت طريقة عامة (أي واحدة تستخدم خارجيا). أعلن ذلك في .h وتحديد في .m. إذا كنت ترغب في الحد من ذلك ، أو على الأقل تشير إلى أنها طريقة خاصة ، فاستخدمها الفئات/الامتدادات الفئة في ملف .M. على الرغم من أن الكثير من رمز المثال يستخدم طريقة الإعلان البطيئة.

Answer 3

يعامل Objective -C وظائف "الرسائل" ، وعلى هذا النحو ، يمكنك إرسال "رسالة" إلى أي كائن - حتى واحد لا يذكر صراحة في واجهته يمكن أن يقبله. نتيجة لذلك ، لا توجد أشياء مثل الأعضاء الخاصين في OBJ-C.

يمكن أن يكون هذا قويًا للغاية ، ولكنه مصدر للارتباك لمبرمجي OBJ -C الجدد - وخاصة تلك القادمة من C ++ أو Java أو C#. فيما يلي القواعد الأساسية للإبهام:

• يجب عليك تحديد جميع الأساليب العامة في واجهة intercly حتى يعرف المستهلكون الرسائل التي تتوقع التعامل معها.
• يجب عليك تحديد أساليب خاصة في واجهة interching لتجنب رسائل التحويل البرمجي وتجنب الاضطرار إلى طلب الأساليب في emplementation الخاصة بك.
• يجب عليك استخدام البروتوكولات عند تنفيذ اتفاقية معينة لطرق فصلك.

الكثير من هذا هو التفضيل الشخصي ، ومع ذلك فهو يساعد على تجنب تحذيرات المترجمات المزعجة والحفاظ على تنظيم الكود الخاص بك. وسهل الفهم.