Интерфейс Java расширяет вопросы

Если вы расширяете интерфейс (то же самое относится и к реализации интерфейса), вы не можете переопределить метод и заставить его генерировать больше проверенных исключений, чем исходный. Вы можете бросить столько же или меньше, но не больше.

Подумай об этом:

interface A {
  void foo();
}

interface B extends A {
  void foo() throws IOException;
}

A a = new B() { ... }
a.foo();

потенциально может вызвать IOException, но вы не сможете узнать об этом. Вот почему вы не можете этого сделать.

Это, конечно, вполне приемлемо:

interface A {
  void foo() throws IOException;
}

interface B extends A {
  void foo();
}

A a = new B() { ... }
try {
    a.foo();
} catch (IOException e) {
    // must catch even though B.foo() won't throw one
}

Однако ваш BookNotFoundException может расширить RuntimeException или RemoteException. Однако не уверен, что это хороший подход.

Что хорошего в одном типе, который расширяет оба этих интерфейса? Вы что-нибудь теряете, когда клиент зависит от двух разных объектов?

Чрезмерное использование наследования — распространенная ошибка новичков, потому что «наследование» — одна из примечательных особенностей объектно-ориентированного программирования. Однако в большинстве случаев композиция является лучшим выбором. В таком случае, почему бы не иметь два отдельных сервиса? Затем добавление CafeteriaService и DormitoryService позже не повлияет на существующие интерфейсы.

Что касается дизайна, метод addBookToStudent выиграл бы от возможности генерировать BookNotFoundException. Интерфейсы хрупки в том смысле, что любое их изменение приводит к поломке большого количества кода. Вы должны быть очень осторожны в их первоначальном дизайне. Например, BookNotFoundException, вероятно, слишком специфично; не может ли существовать множество исключений, препятствующих «добавлению» книги ученику? (Я предполагаю, что студенты берут книги в библиотеке во временное пользование.) Например: CheckOutLimitExceededException, UnpaidFinePendingException, AdultLiteraturePermissionException и т. д.

Тщательно продумайте типы проверенных исключений, которые могут подойти для уровня абстракции при проектировании интерфейсов, потому что их трудно изменить позже.

Несколько идей для вас:

1. Объявите метод addBookToStudent в интерфейсе, чтобы создать исключение BookNotFoundException. Несмотря на то, что StudentServer может никогда не генерировать исключение, это не означает, что вы все равно не можете поместить его в интерфейс.

2. Вы можете создать новое исключение — ObjectNotFoundException и наследовать от него BookNotFoundException и StudentNotFoundException, а затем объявить addBookToStudent для создания исключения ObjectNotFoundException.

3. Что я, вероятно, сделал бы в «реальной жизни» — пусть StudentServer общается с BookServer, чтобы проверить идентификатор книги и выдать само исключение, а не выполнять эту проверку на FrontEndServer. Особенно, если StudentServer на самом деле будет напрямую использоваться чем-то другим, кроме FrontEndServer.

Я бы посоветовал вам попытаться отделить открытый API от API, используемого для реализации вашей функциональности. Я предполагаю, что цель внешнего интерфейса служб RMI состоит в том, чтобы обеспечить разделение и стабильность от вызывающего приложения.

При этом я бы посоветовал вам:

• Напишите API, который вы хотите предоставить
• Напишите реализации, которые связывают ваш API и серверные службы.

Теоретически это возможно, если BookNotFoundException расширяет RemoteExcepiton.

Однако я предполагаю, что у вас нет контроля над интерфейсом StudentServer. Похоже, цель этого интерфейса — не вызывать исключение BookNotFoundException. Хотя я могу понять, почему вы этого хотите, интерфейс, похоже, этого не поощряет.

Исключения вызываются методами, а не интерфейсами или классами. Поэтому, если в интерфейсе BookServer есть метод, он может вызвать исключение, когда вы добавите его в интерфейс.

Если вы думаете о добавлении исключения в метод addBookToStudent в интерфейсе FrontEndServer, ответ будет отрицательным, это невозможно. Переопределенные методы в классах и интерфейсах могут только сузить или полностью удалить исключение, но не добавлять новые исключения.

Если вы задумаетесь об этом, то увидите, что это логично. Ваш FrontEndServer можно использовать как BookServer с помощью кода. Код во время компиляции ожидает исключения, определенные в BookServer. Затем во время выполнения BookServer внезапно создает исключение, которое не определено в интерфейсе BookServer. Если этот фрагмент кода знает только, что BookException является неожиданным, нет операторов catch или throws для его обработки.