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




الفرق بين abstract & interface (20)

  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.

https://code.i-harness.com

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

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

جهة تعامل:

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

فئة الملخص:

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

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

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

انظر أيضا :


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

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

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

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


إذا كنت تعتبر 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" إلى وسائل افتراضية خاصة:


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

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

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

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


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

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

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

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

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

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

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


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


ينقل القائمون على المقابلات شجرة غريبة. بالنسبة للغات مثل C # و Java ، هناك اختلاف ، ولكن بلغات أخرى مثل C ++ ليست كذلك. إن نظرية OO لا تفرق بين الاثنين ، بل مجرد تركيب اللغة.

الفئة التجريدية هي فئة مع كل من التطبيق والواجهة (طرق افتراضية نقية) سيتم توريثها. واجهات عموما ليس لديها أي تنفيذ ولكن فقط وظائف افتراضية نقية.

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


1) An interface can be seen as a pure Abstract Class, is the same, but despite this, is not the same to implement an interface and inheriting from an abstract class. When you inherit from this pure abstract class you are defining a hierarchy -> inheritance, if you implement the interface you are not, and you can implement as many interfaces as you want, but you can only inherit from one class.

2) You can define a property in an interface, so the class that implements that interface must have that property.

فمثلا:

  public interface IVariable
  {
      string name {get; set;}
  }

The class that implements that interface must have a property like that.


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%).

Interface Types vs. Abstract Base Classes

Adapted from the Pro C# 5.0 and the .NET 4.5 Framework book.

The interface type might seem very similar to an abstract base class. Recall that when a class is marked as abstract, it may define any number of abstract members to provide a polymorphic interface to all derived types. However, even when a class does define a set of abstract members, it is also free to define any number of constructors, field data, nonabstract members (with implementation), and so on. Interfaces, on the other hand, contain only abstract member definitions. The polymorphic interface established by an abstract parent class suffers from one major limitation in that only derived types support the members defined by the abstract parent. However, in larger software systems, it is very common to develop multiple class hierarchies that have no common parent beyond System.Object. Given that abstract members in an abstract base class apply only to derived types, we have no way to configure types in different hierarchies to support the same polymorphic interface. By way of example, assume you have defined the following abstract class:

public abstract class CloneableType
{
// Only derived types can support this
// "polymorphic interface." Classes in other
// hierarchies have no access to this abstract
// member.
   public abstract object Clone();
}

Given this definition, only members that extend CloneableType are able to support the Clone() method. If you create a new set of classes that do not extend this base class, you can't gain this polymorphic interface. Also, you might recall that C# does not support multiple inheritance for classes. Therefore, if you wanted to create a MiniVan that is-a Car and is-a CloneableType, you are unable to do so:

// Nope! Multiple inheritance is not possible in C#
// for classes.
public class MiniVan : Car, CloneableType
{
}

As you would guess, interface types come to the rescue. After an interface has been defined, it can be implemented by any class or structure, in any hierarchy, within any namespace or any assembly (written in any .NET programming language). As you can see, interfaces are highly polymorphic. Consider the standard .NET interface named ICloneable, defined in the System namespace. This interface defines a single method named Clone():

public interface ICloneable
{
object Clone();
}

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.


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.


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.


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.


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.


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


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.


الإجابة على السؤال الثاني: publicالمتغير المعرّف interfaceهو static finalافتراضيًا بينما يكون publicالمتغير في abstractالفصل متغير مثيل.





abstract-class