هرماش هل يجب الإعلان عن طرق في واجهة Java مع أو بدون معدِّل وصول عام؟




هرماش جافا سوينغ (9)

يجعل JLS هذا واضحًا:

يُسمح ، ولكن لا يشجع على ذلك كأسلوب ، أن يحدد بشكل عام المعدل public و / أو المعدل abstract للطريقة المعلن عنها في الواجهة.

هل يجب الإعلان عن الطرق في واجهة Java مع أو بدون معدّل الوصول public ؟

من الناحية الفنية لا يهم ، بالطبع. دائمًا ما تكون طريقة الصف التي تطبق interface public . لكن ما هي الاتفاقية الأفضل؟

جافا نفسها ليست ثابتة في هذا. انظر على سبيل المثال Collection مقابل مقابل ، أو Future مقابل ScriptEngine .


أكتب دائمًا ما سأستخدمه إذا لم يكن هناك واجهة ، وكنت أكتب تنفيذًا مباشرًا ، أي أنني سأستخدم public .


مع إدخال معدِّلات default private static لأساليب الواجهة في Java 8/9 ، تصبح الأمور أكثر تعقيدا وأنا أميل إلى الاعتقاد بأن الإعلانات الكاملة أكثر قابلية للقراءة (تحتاج إلى Java 9 لتجميعها):

public interface MyInterface {

    //minimal
    int CONST00 = 0;
    void method00();
    static void method01() {}
    default void method02() {}
    private static void method03() {}
    private void method04() {}

    //full
    public static final int CONST10 = 0;
    public abstract void method10();
    public static void method11() {}
    public default void method12() {}
    private static void method13() {}
    private void method14() {}

}

انها ذاتية تماما. أغفل المعدل public الزائد كما يبدو وكأنه فوضى. كما ذكر آخرون - الاتساق هو مفتاح هذا القرار.

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


وأود أن تجنب وضع المعدلات التي يتم تطبيقها بشكل افتراضي. كما أشار ، يمكن أن يؤدي إلى عدم الاتساق والارتباك.

أسوأ ما رأيته هو واجهة مع طرق أعلن abstract ...


سيتعلم الأشخاص الواجهة الخاصة بك من إكمال الشفرة في IDE أو في Javadoc ، وليس من قراءة المصدر. لذا لا داعي لوضع "الجمهور" في المصدر - لا أحد يقرأ المصدر.


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

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

إن إضافة تلك المعدّلات في الشفرة الخاصة بك لا لزوم لها ولا فائدة منها ولا يمكن أن يؤدي إلا إلى استنتاج مفاده أنك تفتقر إلى المعرفة و / أو فهم أساسيات جافا.


أنا أفضل تخطي ذلك ، قرأت في مكان ما أن واجهات افتراضيا ، public abstract .

ولدهشتي فإن الكتاب - Head First Design Patterns ، يستخدم public مع واجهة التصريح وطرق الواجهة ... التي جعلتني أعيد التفكير مرة أخرى وأنا هبطت على هذا المنصب.

على أي حال ، أعتقد أنه يجب تجاهل المعلومات المتكررة.


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

ﻟذا ، ﻟﺳت ﻣﺗﺄﻛدًا ﺣﻘﺎً ﻣﺎ ھو اﻷﻓﺿل ، وﻟﻛن ﺷﻲء واﺣد ﻻ أﺣب ﺣﻘﺎً ھو اﺳﺗﺧدام public abstract ﻓﻲ أﺳﺎﻟﯾب اﻟوﺻل. يقوم Eclipse بهذا في بعض الأحيان عند إعادة بيعه مع "Extract Interface".





public-method