هل هناك فائدة من وجود فئة مجردة وواجهة؟

Question

لقد بدأت مع واجهة عامة تسمى Ilogin. تتطلب الواجهات أن تنفذ خصائصين: UserD وكلمة المرور. لدي العديد من فئات نوع تسجيل الدخول التي تنفذ هذه الواجهة. مع نمو مشروعي ونما ، وجدت أن العديد من الفئات كررت رمز المستخدم وكلمة المرور. الآن قررت أنني بحاجة إلى فئة تسجيل الدخول الأساسية.

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

هل هناك فائدة للحفاظ على كل من الفئة التجريدية والواجهة حولها؟

شكرًا!

Answer 1

بالتااكيد. دعونا نفكر في مثال ملموس.

قل أن لدينا فئة مجردة Animal. قل ، نحن نصنع بعض الفئات الفرعية Cat, Dog, Mosquito, ، و Eagle. يمكننا تنفيذها Eat(), Breathe(), Sleep() طرق الطبقة التجريدية Animal.

حتى الان جيدة جدا. الآن ، دعنا نقول أننا نريد الحصول على Fly() طريقة ل Mosquito و Eagle الطبقات. نظرًا لأن هذين الكائنات الحية لا يرتبطان جيدًا (أحدهما طائر ، وآخر هو حشرة) ، فلن يكون من السهل التوصل إلى سلف مشترك للاثنين يمكن أن نحصل عليهما كطبقة مجردة. من الأفضل تنفيذ هذا من خلال واجهة IFly.

ال IFly يمكن أن يكون الواجهة Fly() طريقة ليتم تنفيذها. كلاهما Mosquito و Eagle يمكن أن تكون الفصول الدراسية فئات فرعية من الفئة التجريدية Animal وتنفيذ الواجهة IFly وتكون قادرة على Eat(), Breathe(), Sleep() و Fly() دون وجود نوع من العلاقة بين الأسلوب الفردية بين الفئتين.

Answer 2

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

Answer 3

قطعاً. الواجهة هي دائمًا الطريقة الصحيحة للذهاب-وهي الطريقة التي يمكن أن ينفذها أي شيء (بما في ذلك شيء لديه بالفعل أحد الوالدين).

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

Answer 4

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

Answer 5

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

Answer 6

إذا كانت الفئة التجريدية لها وظيفة ، فمن الحكمة الاحتفاظ بها. ولكن إذا كان يحتوي فقط على أساليب مجردة ولا توجد حقول. لا أرى أي فائدة في الحفاظ على كليهما.

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

Answer 7

تحدد واجهتك العقد الذي يجب الوفاء به حتى يتم قبول الكائن ؛ يحدد فئتك التجريدية العقد الذي يجب الوفاء به وتحديد بعض تفاصيل التنفيذ المحددة.

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

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

Answer 8

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

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

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

Answer 9

أعتقد أن فائدة الحفاظ على الواجهة ستكون القدرة على تنفيذ واجهات متعددة في حين أن الفصل لا يمكن أن يرث إلا من فئة مجردة واحدة.

يمكنك تمديد وظائف الفئات الفرعية عن طريق إنشاء واجهة جديدة مع مجموعة مختلفة من الطرق.

Answer 10

على افتراض أنك تسأل على وجه التحديد عندما يكون للواجهة والفئة التجريدية توقيعات متطابقة ...

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

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