oop الفرق - واجهة مقابل فئة الملخص(عام OO)




بين شرح (25)

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

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

جهة تعامل:

يجب تنفيذ كل أسلوب معلن في الواجهة في الفئة الفرعية. يمكن أن توجد أحداث وواجهة وخصائص (C #) وطرق فقط في واجهة. يمكن للفئة تنفيذ واجهات متعددة.

فئة الملخص:

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

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

  2. سألني أحد المذيعين الآخرين ما إذا كان لديك متغير عام داخل الواجهة ، كيف سيكون ذلك مختلفًا عن المتغير في فئة الملخص؟ أصررت على أنه لا يمكنك الحصول على متغير عام داخل واجهة. لم أكن أعرف ما يريد أن يسمعه لكنه لم يكن راضيا أيضا.

انظر أيضا :


Answers

Interface : should be used if you want to imply a rule on the components which may or may not be related to each other

Pros:

  1. Allows multiple inheritance
  2. Provides abstraction by not exposing what exact kind of object is being used in the context
  3. provides consistency by a specific signature of the contractInterface:
  4. Allows multiple inheritance
  5. Provides abstraction by not exposing what exact kind of object is being used in the context
  6. Provides consistency by a specific signature of the contract

Cons:

  1. Must implement all the contracts defined
  2. Cannot have variables or delegates
  3. Once defined cannot be changed without breaking all the classes

Abstract Class : should be used where you want to have some basic or default behaviour or implementation for components related to each other

Pros:

  1. Faster then interface
  2. Has flexibility in the implementation (you can implement it fully or partially)
  3. Can be easily changed without breaking the derived classes

Cons:

  1. Cannot be instantiated
  2. Does not support multiple inheritance

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


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

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

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

في اعتقادي ، لم يتم اختراع الواجهات لتحقيق العديد من الميراث أو لفضح السلوك العام ، وبالمثل ، فإن الطبقات المجردة النقية ليست نقض واجهات لكن الواجهة هي وظيفة يستطيع الكائن القيام بها (عبر وظائف تلك الواجهة) و Class Abstract يمثل أصل التسلسل الهرمي لإنتاج الأطفال الذين لديهم بنية أساسية (خاصية + وظيفة) للوالدين

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

أعتقد أن كلا من المقابلين كانوا يتوقعون اختلاطًا مباشرًا بين هذين الفرقين وعندما فشلت ، حاولوا توجيهك نحو هذا الاختلاف من خلال تطبيق ONE على أنه الآخر

ماذا لو كان لديك فصل دراسي Abstract مع الأساليب المجردة فقط؟


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

يجب على جميع طياري القوات الجوية الأمريكية أن يتبعوا أنظمة معينة على نطاق القوة الجوية ، وأن جميع الطيارين من طراز C-141 (أو F-16 أو T-38) هم "طياري القوات الجوية الأمريكية". يمكن لأي شخص أن يكون ضابط السلامة. لذلك ، لتلخيص:

  • الطيار: الطبقة المجردة
  • C-141 Pilot: فئة محددة
  • ضابط ISafety: واجهة

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


إذا كنت تعتبر java كلغة OOP للإجابة على هذا السؤال ، فإن إصدار Java 8 يتسبب في بعض المحتوى الموجود في الإجابات السابقة عفا عليه الزمن. الآن ، يمكن أن تحتوي واجهة جافا على طرق افتراضية مع تنفيذ ملموس.

يوفر website Oracle الاختلافات الرئيسية بين interface abstract .

فكر في استخدام دروس الملخص إذا:

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

فكر في استخدام واجهات إذا:

  1. تتوقع أن تقوم الفئات غير المرتبطة بتنفيذ الواجهة الخاصة بك. على سبيل المثال ، يمكن للعديد من الكائنات غير المرتبطة تنفيذ واجهة Serializable .
  2. تريد تحديد سلوك نوع بيانات معين ، ولكن لا يهمك من يقوم بتنفيذ سلوكه.
  3. تريد الاستفادة من الميراث المتعدد من النوع.

بعبارات بسيطة ، أود أن استخدم

واجهة: لتنفيذ العقد من قبل كائنات متعددة غير ذات صلة

الفئة التجريدية: لتنفيذ السلوك نفسه أو مختلف بين كائنات متعددة ذات صلة

إلقاء نظرة على مثال الكود لفهم الأشياء بطريقة واضحة: كيف أكون قد أوضحت الفرق بين الطبقة وواجهة الملخص؟


في حين يشير سؤالك إلى أنه بالنسبة لـ "عام OO" ، يبدو أنه يركز بالفعل على استخدام .NET لهذه الشروط.

في .NET (تشبه Java):

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

ﺑﺼﻔﺔ ﻋﺎﻣﺔ ، ﻓﺈن اﻟﻔﺮوﻗﺎت ﻟﻴﺴﺖ ﺑﺎﻟﻀﺮورة ﻣﺤﺪدة ﺑﺸﻜﻞ ﺟﻴﺪ. على سبيل المثال ، يوجد مبرمجو C ++ الذين قد يحملون تعريفات جامدة مماثلة (تكون الواجهات مجموعة فرعية صارمة من الطبقات التجريدية التي لا يمكن أن تحتوي على تطبيق) ، في حين قد يقول البعض أن فئة تجريدية مع بعض التطبيقات الافتراضية لا تزال واجهة أو غير مجردة الطبقة لا تزال تحدد واجهة.

في الواقع ، هناك لغة C ++ تسمى واجهة غير افتراضية (NVI) حيث الطرق العامة هي طرق غير افتراضية "thunk" إلى وسائل افتراضية خاصة:


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

public class Vehicle {
    private Driver driver;
    private Seat[] seatArray; //In java and most of the Object Oriented Programming(OOP) languages, square brackets are used to denote arrays(Collections).
    //You can define as many properties as you want here ...
}

الآن دراجة ...

public class Bicycle extends Vehicle {
    //You define properties which are unique to bicycles here ...
    private Pedal pedal;
}

وسيارة ...

public class Car extends Vehicle {
    private Engine engine;
    private Door[] doors;
}

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

دروس مجردة

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

//......Code of Vehicle Class
abstract public void drive();
//.....Code continues

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

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

public interface Dialable {
    public void dial(Number n);
}

هنا يقوم صانع Dialable بتحديد كيفية الاتصال برقم. تحتاج فقط إلى إعطاءه رقم للاتصال.

// Makers define how exactly dialable work inside.

Dialable PHONE1 = new Dialable() {
    public void dial(Number n) {
        //Do the phone1's own way to dial a number
    }
}

Dialable PHONE2 = new Dialable() {
    public void dial(Number n) {
        //Do the phone2's own way to dial a number
    }
}


//Suppose there is a function written by someone else, which expects a Dialable
......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE1;
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

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

والأهم من ذلك ، إذا قمت في يوم من الأيام بتبديل Dialable بواحدة مختلفة

......
public static void main(String[] args) {
    Dialable myDialable = SomeLibrary.PHONE2; // <-- changed from PHONE1 to PHONE2
    SomeOtherLibrary.doSomethingUsingADialable(myDialable);
}
.....

يمكنك التأكد من أن الشفرة لا تزال تعمل على أكمل وجه لأن الوظيفة التي تستخدم dialable لا (ولا يمكنها) تعتمد على التفاصيل بخلاف تلك المحددة في واجهة Dialable. كلاهما تنفذ واجهة Dialable وهذا هو الشيء الوحيد الذي تهتم به الوظيفة.

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

المزيد من المعلومات Abstract classes vs Interfaces


Couple of other differences:

Abstract classes can have static methods, properties, fields etc. and operators, interfaces can't. Cast operator allows casting to/from abstract class but don't allow casting to/from interface.

So pretty much you can use abstract class on its own even if it is never implemented (through its static members) and you can't use interface on its own in any way.


Though this question is quite old, I would like to add one other point in favor of interfaces:

Interfaces can be injected using any Dependency Injection tools where as Abstract class injection supported by very few.


هناك نوعان من الاختلافات الأخرى -

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

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

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

[C # /. NET محددة] واجهات ، على عكس الفئات الأساسية التجريدية ، يمكن تطبيقها على أنواع القيمة (الهياكل). لا يمكن أن ترث الهياكل من فئات أساسية مجردة. يتيح ذلك تطبيق إرشادات السلوك / العقود السلوكية على أنواع القيم.


Most answers focus on the technical difference between Abstract Class and Interface, but since technically, an interface is basically a kind of abstract class (one without any data or implementation), I think the conceptual difference is far more interesting, and that might be what the interviewers are after.

An Interface is an agreement . It specifies: "this is how we're going to talk to each other". It can't have any implementation because it's not supposed to have any implementation. It's a contract. It's like the .h header files in C.

An Abstract Class is an incomplete implementation . A class may or may not implement an interface, and an abstract class doesn't have to implement it completely. An abstract class without any implementation is kind of useless, but totally legal.

Basically any class, abstract or not, is about what it is , whereas an interface is about how you use it . For example: Animal might be an abstract class implementing some basic metabolic functions, and specifying abstract methods for breathing and locomotion without giving an implementation, because it has no idea whether it should breathe through gills or lungs, and whether it flies, swims, walks or crawls. Mount , on the other hand, might be an Interface, which specifies that you can ride the animal, without knowing what kind of animal it is (or whether it's an animal at all!).

The fact that behind the scenes, an interface is basically an abstract class with only abstract methods, doesn't matter. Conceptually, they fill totally different roles.


Copied from CLR via C# by Jeffrey Richter...

I often hear the question, “Should I design a base type or an interface?” The answer isn't always clearcut.

Here are some guidelines that might help you:

■■ IS-A vs. CAN-DO relationship A type can inherit only one implementation. If the derived type can't claim an IS-A relationship with the base type, don't use a base type; use an interface. Interfaces imply a CAN-DO relationship. If the CAN-DO functionality appears to belong with various object types, use an interface. For example, a type can convert instances of itself to another type (IConvertible), a type can serialize an instance of itself (ISerializable), etc. Note that value types must be derived from System.ValueType, and therefore, they cannot be derived from an arbitrary base class. In this case, you must use a CAN-DO relationship and define an interface.

■■ Ease of use It's generally easier for you as a developer to define a new type derived from a base type than to implement all of the methods of an interface. The base type can provide a lot of functionality, so the derived type probably needs only relatively small modifications to its behavior. If you supply an interface, the new type must implement all of the members.

■■ Consistent implementation No matter how well an interface contract is documented, it's very unlikely that everyone will implement the contract 100 percent correctly. In fact, COM suffers from this very problem, which is why some COM objects work correctly only with Microsoft Word or with Windows Internet Explorer. By providing a base type with a good default implementation, you start off using a type that works and is well tested; you can then modify parts that need modification.

■■ Versioning If you add a method to the base type, the derived type inherits the new method, you start off using a type that works, and the user's source code doesn't even have to be recompiled. Adding a new member to an interface forces the inheritor of the interface to change its source code and recompile.


After all that, the interviewer came up with the question "What if you had an 
Abstract class with only abstract methods? How would that be different
from an interface?" 

docs.oracle.com/javase/tutorial/java/IandI/abstract.html clearly say that if an abstract class contains only abstract method declarations, it should be declared as an interface instead.

An another interviewer asked me what if you had a Public variable inside
the interface, how would that be different than in Abstract Class?

Variables in Interfaces are by default public static and final. Question could be framed like what if all variables in abstract class are public? Well they can still be non static and non final unlike the variables in interfaces.

Finally I would add one more point to those mentioned above - abstract classes are still classes and fall in a single inheritance tree whereas interfaces can be present in multiple inheritance.


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

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

abstract class: is only used to factorize some code between classes of the same responsability. Note that this is the main reason why multiple-inheritance is a bad thing in OOP, because a class shouldn't handle many responsabilities (use composition instead).

So interfaces have a real architectural role whereas abstract classes are almost only a detail of implementation (if you use it correctly of course).


Difference between Java Interface and Abstract Class

  1. Main difference is methods of a Java interface are implicitly abstract and cannot have implementations. A Java abstract class can have instance methods that implements a default behavior.

  2. Variables declared in a Java interface is by default final. An abstract class may contain non-final variables.

  3. Members of a Java interface are public by default. A Java abstract class can have the usual flavors of class members like private, protected, etc..

  4. Java interface should be implemented using keyword “implements”; A Java abstract class should be extended using keyword “extends”.

  5. An interface can extend another Java interface only, an abstract class can extend another Java class and implement multiple Java interfaces.

  6. A Java class can implement multiple interfaces but it can extend only one abstract class.

  7. Interface is absolutely abstract and cannot be instantiated; A Java abstract class also cannot be instantiated, but can be invoked if a main() exists.

  8. In comparison with java abstract classes, java interfaces are slow as it requires extra indirection.


An interface defines a contract for a service or set of services. They provide polymorphism in a horizontal manner in that two completely unrelated classes can implement the same interface but be used interchangeably as a parameter of the type of interface they implement, as both classes have promised to satisfy the set of services defined by the interface. Interfaces provide no implementation details.

An abstract class defines a base structure for its sublcasses, and optionally partial implementation. Abstract classes provide polymorphism in a vertical, but directional manner, in that any class that inherits the abstract class can be treated as an instance of that abstract class but not the other way around. Abstract classes can and often do contain implementation details, but cannot be instantiated on their own- only their subclasses can be "newed up".

C# does allow for interface inheritance as well, mind you.


From another answer of mine , mostly dealing with when to use one versus the other:

In my experience, interfaces are best used when you have several classes which each need to respond to the same method or methods so that they can be used interchangeably by other code which will be written against those classes' common interface. The best use of an interface is when the protocol is important but the underlying logic may be different for each class. If you would otherwise be duplicating logic, consider abstract classes or standard class inheritance instead.


Abstract class And Interface Difference :

  1. Abstract class can have abstract and non-abstract methods and Interface can have only abstract methods.
  2. Abstract class doesn't support multiple inheritance And Interface supports multiple inheritance.
  3. Abstract class can have final, non-final, static and non-static variables And Interface has only static and final variables.
  4. Abstract class can have static methods, main method and constructor And Interface can't have static methods, main method or constructor.
  5. Abstract class can provide the implementation of interface And Interface can't provide the implementation of abstract class.
  6. The abstract keyword is used to declare abstract class And The interface keyword is used to declare interface.
  7. Abstract class achieves partial abstraction (0 to 100%) because there are non abstract methods also in abstract class whereas interface achieves fully abstraction (100%).

Interfaces are light weight way to enforce a particular behavior. That is one way to think of.


أعتقد أن الإجابة التي يبحثون عنها هي الفرق الأساسي أو الفلسفي.

يتم استخدام وراثة الفئة التجريدية عندما تشارك الطبقة المشتقة الخصائص الأساسية وسلوك الطبقة المجردة. نوع السلوك الذي يحدد الفئة بالفعل.

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

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


  1. جهة تعامل:
    • We do not implement (or define) methods, we do that in derived classes.
    • We do not declare member variables in interfaces.
    • Interfaces express the HAS-A relationship. That means they are a mask of objects.
  2. Abstract class:
    • We can declare and define methods in abstract class.
    • We hide constructors of it. That means there is no object created from it directly.
    • Abstract class can hold member variables.
    • Derived classes inherit to abstract class that mean objects from derived classes are not masked, it inherit to abstract class. The relationship in this case is IS-A.

This is my opinion.


For sure it is important to understand the behavior of interface and abstract class in OOP (and how languages handle them), but I think it is also important to understand what exactly each term means. Can you imagine the if command not working exactly as the meaning of the term? Also, actually some languages are reducing, even more, the differences between an interface and an abstract... if by chance one day the two terms operate almost identically, at least you can define yourself where (and why) should any of them be used for.

If you read through some dictionaries and other fonts you may find different meanings for the same term but having some common definitions. I think these two meanings I found in this site are really, really good and suitable.

جهة تعامل:

A thing or circumstance that enables separate and sometimes incompatible elements to coordinate effectively.

Abstract:

Something that concentrates in itself the essential qualities of anything more extensive or more general, or of several things; essence.

مثال:

You bought a car and it needs fuel.

Your car model is XYZ , which is of genre ABC , so it is a concrete car, a specific instance of a car. A car is not a real object. In fact, it is an abstract set of standards (qualities) to create a specific object. In short, Car is an abstract class , it is "something that concentrates in itself the essential qualities of anything more extensive or more general" .

The only fuel that matches the car manual specification should be used to fill up the car tank. In reality, there is nothing to restrict you to put any fuel but the engine will work properly only with the specified fuel, so it is better to follow its requirements. The requirements say that it accepts, as other cars of the same genre ABC , a standard set of fuel.

In an Object Oriented view, fuel for genre ABC should not be declared as a class because there is no concrete fuel for a specific genre of car out there. Although your car could accept an abstract class Fuel or VehicularFuel, you must remember that your only some of the existing vehicular fuel meet the specification, those that implement the requirements in your car manual. In short, they should implement the interface ABCGenreFuel , which "... enables separate and sometimes incompatible elements to coordinate effectively" .

إضافة

In addition, I think you should keep in mind the meaning of the term class, which is (from the same site previously mentioned):

Class:

A number of persons or things regarded as forming a group by reason of common attributes, characteristics, qualities, or traits; kind;

This way, a class (or abstract class) should not represent only common attributes (like an interface), but some kind of group with common attributes. An interface doesn't need to represent a kind. It must represent common attributes. This way, I think classes and abstract classes may be used to represent things that should not change its aspects often, like a human being a Mammal, because it represents some kinds. Kinds should not change themselves that often.


As you might have got the theoretical knowledge from the experts, I am not spending much words in repeating all those here, rather let me explain with a simple example where we can use/cannot use Interface and Abstract class .

Consider you are designing an application to list all the features of Cars. In various points you need inheritance in common, as some of the properties like DigitalFuelMeter, Air Conditioning, Seat adjustment, etc are common for all the cars. Likewise, we need inheritance for some classes only as some of the properties like the Braking system (ABS,EBD) are applicable only for some cars.

The below class acts as a base class for all the cars:

public class Cars
{
    public string DigitalFuelMeter()
    {
        return "I have DigitalFuelMeter";
    }

    public string AirCondition()
    {
        return "I have AC";
    }

    public string SeatAdjust()
    {
        return "I can Adjust seat";
    }
}

Consider we have a separate class for each Cars.

public class Alto : Cars
{
    // Have all the features of Car class    
}

public class Verna : Cars
{
    // Have all the features of Car class + Car need to inherit ABS as the Braking technology feature which is not in Cars        
}

public class Cruze : Cars
{
    // Have all the features of Car class + Car need to inherit EBD as the Braking technology feature which is not in Cars        
}

Consider we need a method for inheriting the Braking technology for the cars Verna and Cruze (not applicable for Alto). Though both uses braking technology, the "technology" is different. So we are creating an abstract class in which the method will be declared as Abstract and it should be implemented in its child classes.

public abstract class Brake
{
    public abstract string GetBrakeTechnology();
}

Now we are trying to inherit from this abstract class and the type of braking system is implemented in Verna and Cruze:

public class Verna : Cars,Brake
{
    public override string GetBrakeTechnology()
    {
        return "I use ABS system for braking";
    }       
}

public class Cruze : Cars,Brake
{
    public override string GetBrakeTechnology()
    {
       return "I use EBD system for braking";
    }         
}

See the problem in the above two classes? They inherit from multiple classes which C#.Net doesn't allow even though the method is implemented in the children. Here it comes the need of Interface.

interface IBrakeTechnology
{
    string GetBrakeTechnology();
}

And the implementation is given below:

public class Verna : Cars, IBrakeTechnology
{
    public string GetBrakeTechnology()
    {
        return "I use ABS system for braking";
    }
}

public class Cruze : Cars, IBrakeTechnology
{
   public string GetBrakeTechnology()
   {
       return "I use EBD system for braking";
   }        
}

Now Verna and Cruze can achieve multiple inheritance with its own kind of braking technologies with the help of Interface.


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

  1. متى يجب أن نستخدم الواجهة؟

    إذا كنت لا تعرف التنفيذ فقط لدينا متطلبات المتطلبات ثم نذهب مع واجهة

  2. متى يجب علينا استخدام فئة الملخص؟

    إذا كنت تعرف التنفيذ ولكن ليس بشكل كامل (تنفيذ جزئي) ، فإننا نذهب مع طبقة الملخص.

    جهة تعامل

    كل طريقة افتراضيا مجردة يعني وسيلة واجهة مجردة 100 ٪ نقية.

    نبذة مختصرة

    يمكن أن يكون لها طريقة ملموسة وطريقة مجردة ، ما هي طريقة ملموسة ، والتي لديها تطبيق في فئة الملخص ، فئة تجريدية هي فئة يتم إعلانها مجردة - قد تكون أو لا تتضمن طرق مجردة.

    جهة تعامل

    لا يمكننا التصريح عن الواجهة كخاصة ومحمية

    س. لماذا لا نعلن أن الواجهة خاصة ومحمية؟

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

    طريقة واجهة
    كما لا يمكننا أن نعلن عن واجهة كخاصة ، محمية ، نهائية ، ثابتة ، متزامنة ، محلية .....

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

    نبذة مختصرة

    نحن نستخدم بسعادة مع الجمهور النهائي الخاص والخاص .... يعني عدم وجود قيود قابلة للتطبيق في مجردة.

    جهة تعامل

    يتم الإعلان عن المتغيرات في الواجهة على أنها نهائية ثابتة عامة بحيث لا يتم اعتبارنا أيضًا متغيرًا كخاص ومحمي.

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

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

    نبذة مختصرة

    المتغير التجريبي لا حاجة إلى إعلان نهائي ثابت علني.

آمل أن تكون هذه المقالة مفيدة.


If you have some common methods that can be used by multiple classes go for abstract classes. Else if you want the classes to follow some definite blueprint go for interfaces.

Following examples demonstrate this.

Abstract class in Java:

abstract class animals
{
    // They all love to eat. So let's implement them for everybody
    void eat()
    {
        System.out.println("Eating...");
    }
    // The make different sounds. They will provide their own implementation.
    abstract void sound();
}

class dog extends animals
{
    void sound()
    {
        System.out.println("Woof Woof");
    }
}

class cat extends animals
{
    void sound()
    {
        System.out.println("Meoww");
    }
}

Following is an implementation of interface in Java:

interface Shape
{
    void display();
    double area();
}

class Rectangle implements Shape 
{
    int length, width;
    Rectangle(int length, int width)
    {
        this.length = length;
        this.width = width;
    }
    @Override
    public void display() 
    {
        System.out.println("****\n* *\n* *\n****"); 
    }
    @Override
    public double area() 
    {
        return (double)(length*width);
    }
} 

class Circle implements Shape 
{
    double pi = 3.14;
    int radius;
    Circle(int radius)
    {
        this.radius = radius;
    }
    @Override
    public void display() 
    {
        System.out.println("O"); // :P
    }
    @Override
    public double area() 
    { 
        return (double)((pi*radius*radius)/2);
    }
}

Some Important Key points in a nutshell:

  1. The variables declared in Java interface are by default final. Abstract classes can have non-final variables.

  2. The variables declared in Java interface are by default static. Abstract classes can have non-static variables.

  3. Members of a Java interface are public by default. A Java abstract class can have the usual flavors of class members like private, protected, etc..





oop interface abstract-class