Похоже, что Emptyness
не проходит тест «должен быть подклассом» в отношении Door
. Проверка состоит в том, что верно следующее предложение: Emptyness
- это Door
. Поскольку Door
может быть закрыто, Emptyness
не соответствует этому требованию.
Рекомендовать использовать агрегацию, а не наследование. Пусть Emptyness
реализует свой собственный интерфейс (или другой соответствующий интерфейс, но не Door
), а содержит Door
экземпляр, который он использует для выполнения соответствующих операций.
Делать что-то вроде переопределения операции close
, чтобы ничего не делать или генерировать исключение, совершенно неуместно , если Door#close
не определен как необязательный (через тег throws
для соответствующего исключения) , (И остерегайтесь «необязательных» операций в иерархиях классов, они обычно указывают на проблему проектирования. Не всегда, но обычно.) Пример, который Андреас приводит для Iterator#remove
, например: Iterator#remove
помечен как бросать UnsupportedOperationException
. Если Door#close
помечен таким образом, и если вы чувствуете себя комфортно при таком способе ведения дел, прекрасно, вы здесь. Но если этого не произойдет, то Emptyness
не сможет выполнить контракт Door
, что обычно означает, что вам нужно пойти другим путем.