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



14 Answers

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

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

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

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

Question

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

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

جهة تعامل:

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

فئة الملخص:

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

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

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

انظر أيضا :




  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.




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

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

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

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

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

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

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

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

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

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




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.




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



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

و

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




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



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.




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.




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.




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

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

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

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

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

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

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




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

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




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.




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

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

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

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

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

    جهة تعامل

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

    نبذة مختصرة

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

    جهة تعامل

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

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

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

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

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

    نبذة مختصرة

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

    جهة تعامل

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

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

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

    نبذة مختصرة

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

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




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






Related