الإفراط في استخدام واجهات Java في تنفيذ MS. Pac-Man

Question

لقد كنت مبرمج Java خلال السنوات الستة الماضية، ومنذ بداية هذا العام، حصلت على مهتمة برمجة اللعبة. لذلك، اعتقدت أنه من الجيد أن تبدأ لعبة شعبية ونفذت اللعبة السيدة باك مان في جاوة. أستطيع أن أقول إن تطبيقي يشبه حوالي 90٪ مماثلة للعبة الأصلية، وحاولت استخدام أكبر قدر ممكن من أنماط التصميم وأفضل الممارسات قدر الإمكان، لأن هذا كان مجرد مشروع شخصي لتعلم رمز الألعاب الأساسية الأساسية.

الآن بعد أن انتهيت من الترميز، أدركت أن لدي 19 واجهات و 17 فصلا فقط! لذلك أبدأ أتساءل عما إذا كنت قد أفرط بين الواجهات.

فيما يلي مثال على عدد قليل من الفئات / الواجهات التي أستخدمها:

فصل - fullgame (تنفذ fullgameinterface و fullgameobservable)

فصل - عرض 1 (تنفذ Fullgameobserver)

واجهه المستخدم - fullgameinterface (طرق الوظائف الأساسية: استئناف، وقفة، تشغيل، إلخ)

واجهه المستخدم - Fullgameobsable (يسمح بتسجيل طرق العرض للحصول على إعلام التحديث)

واجهه المستخدم - fullgameobserver (يتم تنفيذه من خلال وجهات نظر مختلفة من اللعبة لتلقي الإخطارات)

هل أنا متفوق على الواجهات؟

ما هو رأيك؟

Answer 1

واجهات جيدة. إنها ليست مشكلة في الحصول على الكثير منها.

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

Answer 2

استخدم واجهة إذا كنت ترغب في تغيير التطبيق.

لشيء مثل كائن FullGame الخاص بك، ربما لا تحتاج إلى الواجهة.

إذا كنت قد تغيرت وظيفة FullGame، فيمكنك التفكير في واجهة، حتى تتمكن من تبديل الكائن الذي تقوم بإنشاء مثيل له FullGameInterface.

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

تحرير للحصول على إجابة أكثر اكتمالا:

تعد الواجهات مفيدة لدفع الأساليب التي تريد الوصول إليها عن كائن (واجهة) من الكائن الفعلي (التنفيذ). هذا جيد لعدة المواقف:

1. لديك أكثر من تنفيذ تلك الأساليب، مع نفس الدلالات والعمليات العامة، ولكن مع مختلف التنفيذات الأساسية. علي سبيل المثال، List, ArrayList, ، و LinkedList. List هي الواجهة العامة التي تسمح العديد من الأساليب القائمة على المجموعات لقبول إما ArrayList أو أ LinkedList. وبعد ال Collection واجهة تسمح بترتيب مماثل لجميع المجموعات.
2. تحتاج إلى فصل الواجهة من تنفيذ الأسباب المعمارية. على سبيل المثال، يمكنك الحصول على كائن الاتصال على جهاز واحد وكائن التنفيذ على آخر. يقوم وكيل على آلة المكالمات بتنفيذ الواجهة للاتصال عبر الشبكة إلى الكائن الحقيقي. واجهة تعني أن المتصل لا يجب أن يعرف الفرق. جافا RMI فعلت هذا.
3. تحتاج إلى أن تكون قادرا على تعديل الطريقة التي يسمى الكائن. على سبيل المثال، تأخذ واجهة Image واثنان من المنفذين، FileImage و FileImageProxy. وبعد البروكسي يحمل FileImage عند الطلب ويمرر المكالمات إلى Image واجهة على الكائن الفعلي. لا يعرف العملاء أو يهتمون أبدا كيف يحصلون على الصورة، أو ما إذا كان محملا حقا أم لا؛ هم فقط يعرفون أن هناك Image ويمكنهم استخدامها.

Answer 3

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

كثير من الميراث للواجهة، وكذلك التنفيذ، هو عادة فكرة سيئة.

Answer 4

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