Принцип замены Liskov (LSP), шаблон прокси и исключения

Question

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

Клиентский код, который использует интерфейс, получит неожиданное исключение. Я предполагаю, что в этой ситуации нарушается принцип LSP.

Но как можно обрабатывать сетевые исключения в этом случае, если им не разрешено распространяться из интерфейса?

Вот некоторые Java-код, чтобы уточнить, что я имею в виду:

interface Interface 
{ 
    abstract void method1(); 
    abstract void method2(); 
    abstract void method3(); 
} 

class Implementation implements Interface 
{ 
    void method1(); 
    void method2(); 
    void method3(); 
} 

class ProxyOverNetwork implements Interface 
{ 
    // I can't add the NetworkException as it is not part of the Interface 
    // and would violate LSP, but how to handle the network problems then, 
    // when the ProxyOverNetwork might not be the right place to do so? 

    void method1() throws(NetworkException); 
    void method2() throws(NetworkException); 
    void method3() throws(NetworkException); 
} 

бы я должен изменить интерфейс, чтобы исключения распространяться вне дома?

Answer 1

Учитывая, что вы пишете в Java, если вы хотите, чтобы ваши Interface должны быть реализованы таким образом, таким образом, что вызовы метода могут потерпеть неудачу, вам нужно сделать одну из двух вещей: либо

• изменения Interface, чтобы они повышали проверенное исключение, или
• заставляют реализации поднимать необработанные исключения.

Относительные преимущества и недостатки проверенных и непроверенных исключений подробно обсуждаются на SO и по всему Интернету. Я не писал много Java в течение нескольких лет, но несколько лет назад тенденция заключалась в использовании только исключенных исключений, чтобы сохранить вызывающего абонента проблемы с их обработкой. Честные люди Ruby (я один) расскажут вам, что они забывают обрабатывать случаи ошибок все время благодаря их нетипизированному языку и в конечном итоге обрабатывают их в исправлениях. Теперь Haskell является модным, язык, в котором тиковые подписи используются для ограничения поведения такими способами, которые заставили бы неконтролируемый лагерь исключений кричать на холмы.

Я бы использовал проверенное исключение, чтобы убедиться, что вызывающий абонент обрабатывает возможные сбои. Однако я бы не использовал NetworkException, но что-то общее, как MethodFailureException (если бы мы знали, что Interface мы могли бы выбрать лучшее имя), которое могло бы распространяться NetworkException. Это избавляет вызывающего от знания о реализации, позволяя им обрабатывать ошибку.