Чи правильно інтерфейси залежати від конкретних класів?

Я створюю в Java інтерфейс для користувальницького обробника помилок.

Хочете передати об’єкт помилки аргументу, але мені потрібно, щоб він був дочірнім Exceptionкласом.

Чи добре використовувати моє визначене ім’я класу в інтерфейсі?

Чи не зробить це менш інтерфейсом з точки зору того, що він не залежить від будь-якої реалізації?

Я намагаюся зробити щось подібне:

public class CustomException {
    /* ... Implementation ... */
}

public interface Interface {

    void onError(CustomException ex);

}

По-перше, я повинен зазначити той факт, CustomExceptionякий не поширюється, Exceptionтому він насправді не є Exception.

Це сказав:

Якщо ви не переймаєтесь принципом інверсії залежності , залиште його таким, яким він є. Це абсолютно нормально для інтерфейсу , щоб залежати від класів конкретних, наприклад , багато інтерфейси залежать від Stringабо Objectякі є конкретними класами . Вся справа в тому, що ми схильні вважати, що класи, які належать до Java SDK, є більш стійкими (менш схильні до змін коду), ніж ті, що ми пишемо.

В іншій руці:

Якщо ви хочете слідувати DIP (який має незліченну кількість переваг і є моєю рекомендацією), тоді вам потрібно зробити одну з двох речей:

Варіант 1

• Зробіть CustomExceptionабстрактним
• Тримайте void onError(CustomException ex)як є

Варіант 2

• Зробіть CustomExceptionінтерфейс
• Тримайте void onError(CustomException ex)як є

З будь-яким із цих варіантів ви б відповідали DIP, оскільки інтерфейс не залежав би від конкретного класу, а лише від абстракцій.

При прямому застосуванні інверсії залежності абстракції належать верхнім / політичним шарам. Ця архітектура групує вищі компоненти / політики та конспекти, які визначають нижчі служби разом у одному пакеті. Шари нижчого рівня створюються успадкуванням / реалізацією цих абстрактних класів або інтерфейсів . Мартін, Роберт К. (2003).

• Agile Розробка програмного забезпечення, Принципи,> Шаблони та практики. Prentice Hall. С. 127–131. ISBN 978-0135974445.

Tulains правильно - інтерфейси весь час залежать від конкретних класів. Вони призначені лише для створення договору для власних проблем. Цей договір може передбачати отримання та повернення будь-яких даних.

Пам’ятайте, що в мовах вищого рівня навіть примітивні типи не такі примітивні. Тож ви все одно працюєте з бетонними типами!

Я гадаю, назвою ви маєте на увазі сам власне клас. Якщо ви намагаєтеся вказати фактичне ім'я класу винятку для ініціалізації відповідного винятку через Reflection, це не правильний шлях.

Якщо ви хочете використовувати користувальницький клас в інтерфейсі, ви, звичайно, можете використовувати власні класи у власних інтерфейсах. Класи стають частинами загальнодоступного інтерфейсу вашої бібліотеки / API. Структури даних та винятки - хороший приклад класів, які часто використовуються інтерфейсами.

Якщо вам потрібно використовувати різні винятки залежно від контексту, то, можливо, вам буде цікаво використовувати generics.