Имитация абстрактных методов с использованием исключений в Java

Question

Мне задали этот вопрос, и я, честно говоря, в тупике:

Вместо написания абстрактных методов мы могли бы попытаться имитировать их с помощью исключений, например:

public int someMethod(int someparameter) {
    throws new RuntimeException("unimplemented");
}

Какова будет цель этого и может ли кто-нибудь предоставить пример кода для абстрактного метода, который пытается подделать вышеизложенное?Любая помощь очень ценится.Спасибо.

Answer 1

Я могу придумать один (возможно) правильный вариант использования:У вас есть абстрактный класс и ряд других классов в вашем проекте, которые его расширяют.(Или абстрактный класс находится в библиотеке с открытым исходным кодом, поэтому вы понятия не имеете, какие другие классы во вселенной могут быть расширены из него.) Теперь вы обнаружите, что полезно добавить к этому классу новые абстрактные методы.Но если вы добавите abstract методы в класс, это нарушает работу любого другого класса, который уже расширил его, поскольку эти классы необходимо изменить, чтобы они содержали переопределение для новых методов.Итак, я понимаю, что в некоторых случаях было бы целесообразнее добавить их как неабстрактные методы и заставить их генерировать исключения на всякий случай. новый Класс, который его расширяет, использует новые методы, но забывает написать переопределяющий метод.Он не будет обнаружен во время компиляции, но, по крайней мере, может быть обнаружен во время тестирования.

Я не уверен, насколько законна эта причина, поскольку также можно определить новый абстрактный класс. NewImprovedWhatever который расширяет старый и содержит новые методы.Однако это может создать свои собственные проблемы с обслуживанием.Я не уверен.

Я заметил, что Java определяет абстрактный класс. java.net.SocketImpl, который содержит два неабстрактных метода, shutdownInput() и shutdownOutput(), чья реализация по умолчанию заключается в выдаче исключения:

protected void shutdownInput() throws IOException {
  throw new IOException("Method not implemented!");
}

В комментариях указано, что они были добавлены в версии 1.3, так что, возможно, именно поэтому и сделано именно так, т.е.не требовать модификации других классов, которые уже расширены SocketImpl.Но я не знаю наверняка.

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

Answer 2

У меня иногда бросается НеподдерживающийсяОперацияException Метод, функциональность которого еще не реализован.(Есть также также a a a href="http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/notimplementedException.html" rel="nofollow">NotImplementedException в Apache Commons , который является подклассом неподтвержденного объектива.) Это всегда было предназначено для заполнителя и сообщения для других, использующих связанный класс или услугу, что метод еще не завершен.Однако такой код никогда не добрался до производства.

Answer 3

Целью этого было бы целенаправленно написать ПЛОХОЙ КОД.
Если кто-то хочет сбить с толку своих читателей и хочет, чтобы они почувствовали агонию, проходя через свой код, то он пишет такой код.
Это также свидетельствует об отсутствии навыков проектирования в коде.
Плохо написанный API будет иметь такой код.
Не делай этого.