Я создаю интерфейс на Java для пользовательского обработчика ошибок.
Хочу передать объект ошибки аргумента, но мне нужно, чтобы он был потомком Exceptionкласса.
Можно ли использовать мое имя класса в интерфейсе?
Разве это не сделает его менее интерфейсным с точки зрения отсутствия зависимости от какой-либо реализации?
Я пытаюсь сделать что-то вроде этого:
public class CustomException {
/* ... Implementation ... */
}
public interface Interface {
void onError(CustomException ex);
}
java
design
object-oriented
interfaces
nikachx
источник
источник
CustomExceptionчасть реализации или часть интерфейса?StringбезопаснееCustomException? Почему это важно, еслиCustomException, в свою очередь, имеет другие зависимости?Ответы:
Во-первых, я должен указать на тот факт, что
CustomExceptionэто не распространяется,Exceptionпоэтому это не совсем такException.Это говорит:
Если вам не важен принцип инверсии зависимости , оставьте его как есть. Это совершенно нормально для интерфейса , чтобы зависеть от классов конкретных, например , многие интерфейсы зависят от
StringилиObjectкоторые являются конкретными классами . Дело в том, что мы склонны полагать, что классы, принадлежащие Java SDK, более стабильны (менее подвержены изменениям, нарушающим код), чем те, которые мы пишем.С другой стороны:
Если вы хотите следовать DIP (который имеет бесчисленные преимущества и является моей рекомендацией), то вы должны сделать одну из двух вещей:
Опция 1
CustomExceptionаннотациюvoid onError(CustomException ex)как естьВариант 2
CustomExceptionинтерфейсvoid onError(CustomException ex)как естьС любой из этих опций вы будете соответствовать DIP, так как интерфейс не будет зависеть от какого-либо конкретного класса, только от абстракций.
источник
Interfaceинтерфейс принимает aCustomExceptionи оставляет его вызывающей стороне для его предоставления, вызывающая сторона может предоставить любой класс, который расширяется,CustomExceptionдаже еслиCustomExceptionэто конкретный класс - что было бы невозможно, если быInterfaceон каким-то образом отвечал за создание Это. Эта инверсия управления, более чем работа с интерфейсами (хотя это, безусловно, помогает), это то, чем я считаю DI.Тулинс прав - интерфейсы все время зависят от конкретных классов. Они предназначены только для создания контракта для своих собственных задач. Этот контракт может включать сбор и возврат любых данных.
Помните, что в языках более высокого уровня даже примитивные типы не так примитивны. Так что вы все равно работаете с конкретными типами!
источник
Полагаю, по имени вы имеете в виду сам фактический класс. Если вы пытаетесь указать фактическое имя класса исключения , чтобы инициализировать соответствующее исключение с помощью Reflection, это не правильный путь.
Если вы хотите использовать пользовательский класс в интерфейсе, вы, конечно, можете использовать свои собственные классы в своих собственных интерфейсах. Классы становятся частью открытого интерфейса вашей библиотеки / API. Структуры данных и исключения являются хорошим примером классов, которые часто используются интерфейсами.
Если вам нужно использовать разные исключения в зависимости от контекста, тогда вас может заинтересовать использование обобщений.
источник