كسر API جافا

Question

ولدي API التالية:

public interface MyApi {

   /**
    * Performs some stuff.
    * @throws MyException if condition C1
    */
   public void method() throws MyException;
}

وأنا الآن إجراء التعديلات التالية في تنفيذ API بلدي

public class MyApiImpl {

   public void method() throws MyException {
     if (C1) {
       throw new MyException("c1 message");
     }
     ...
   }
}

ويتم استبداله:

public class MyApiImpl {

   public void method() throws MyException {
     if (C1) {
        throw new MyException("c1 message");
     } else if (c2) {
        throw new MyException("c2 message");
     }
     ...
   }
}

هل نعتبر هذا الكسر API؟

وكود العميل سوف لا تزال تجمع ولكن ليس أكثر احترام العقد طريقة التي يحددها جافادوك API منذ يتم طرح MyExcepiton من حالة "جديدة".

إذا يتم تحديث فقط ملفي جرة API، وتطبيق عملاء سوف لا تزال تعمل ولكن اعتمادا على طريقة عملاء قبض على استثناء من سلوك التطبيق يمكن أن تغير الكثير.

ما وجهة نظركم في ذلك؟

Answer 1

نعم، كنت كسر العقد واجهة عن طريق رمي استثناء عندما لا يحدث C1.

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

Answer 2

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

وهذا حقا يمكن أن تذهب في كلا الاتجاهين، فمن بينك وبين عملائك على ما نهجكم سوف يكون.

Answer 3

وهذا يعتمد إلى حد كبير على ما C2 هو. هو في حدود منطقية على العقد الموجودة من قبل؟ إذا كان الأمر كذلك، كنت تلبية العقد عن طريق رمي MyException. إذا لم يكن ثم ربما تحتاج لرمي نوع جديد من استثناء.

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

Answer 4

وأنا أقول "لا"، غير قابلة للكسر API، ما لم MyException هو RuntimeException. ثم هو عليه.

وعلى أي حال، فما استقاموا لكم فاستقيموا فرعية MyException لحالة C2

وينبغي أن يكون وكلا الشرطين C1 و C2 "استثنائية" IMHO، وأود أن لا تجعل هذه العادة من رمي الاستثناءات

Answer 5

وانها الكسر. ما إذا كان فرض API التي بنيات اللغة أو موثقة ببساطة غير ذي صلة.

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

Answer 6

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