Обойти последний метод в подклассе в Java?

Возникает вопрос: отличается ли порядок вывода средств для счета с овердрафтом? Нет, на самом деле это не так, процесс тот же: вы проверяете пароль, вы проверяете, достаточно ли средств, вы списываете деньги со счета.

Отличие - это шаг check there are enough funds. Итак, ваша абстракция должна это отражать, как и в случае с checkPassword().

public final void withdraw(double amount, String pass) {
 if (checkPassword(pass) && checkFundsAvailable(amount)) {
    setBalance(getBalance() - amount);
 } else {
    System.out.println("Rejected.");
 }
}

protected boolean checkFundsAvailable(double amount) {
  return amount <= getBalance();
}

И когда у вас может быть овердрафт, вы отменяете его с помощью:

protected boolean checkFundsAvailable(double amount) {
  return amount <= getBalance() + overdraftLimit;
}

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

P.s .: Несмотря на все вышесказанное, есть очень веская причина не подходить к этой проблеме с наследованием (если бы это была настоящая проблема, а не просто упражнение), но она более тонкая. Имея класс BankAccount и подкласс BankAccountOverdraft, вы также заявляете, что учетные записи, которые не допускают овердрафты, никогда не могут быть превращены в учетные записи с возможностью овердрафта, и наоборот. Но реальные банковские счета не ведут себя так, вы можете начать без допустимого овердрафта и согласовать лимит овердрафта позже. Наследование не может выразить это, вам нужно использовать некоторую форму композиции.

Другие предлагали изменить ваш дизайн, но важно понимать, почему ваш оригинальный дизайн не работает.

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

Как отмечает biziclop, можно использовать наследование, чтобы выразить связь между учетной записью, которая может иметь овердрафт, и учетной записью, которая не может. Но превращение одного из них в родительский нарушает принцип замещения Лискова. Вместо этого заставьте два класса реализовать или расширить общий интерфейс или суперкласс, который не определяет поведение овердрафта. Возможно, суперкласс вообще не должен включать метод withdraw. Избегайте написания одного класса, который работает в обоих направлениях. Если клиенту вашего API необходимо протестировать поведение и возможности объекта, вы обошли строгую типизацию, которая является одной из самых сильных сторон Java.

Есть отличная книга под названием Эффективная Java, которую должен прочитать каждый Java-программист. В нем рассказывается о том, как наследование нарушает инкапсуляцию и как каждый класс, допускающий наследование, должен разрабатываться очень тщательно. По этим причинам я считаю ужасной медвежьей услугой для студентов то, что наследование является одной из первых вещей, которым обучают на вводных курсах программирования. Он должен быть одним из последних.

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

Вы можете разделить withdraw на два отдельных метода. super метод может быть помечен final, и у вас может быть второй protected метод, который не помечен final, который выполняет фактическое снятие средств. Это заставляет проверку произойти, но позволяет фактическому поведению отказа быть динамичным.

public final void withdraw(double amount, String pass) {

    if (checkPassword(pass)) {
        withdraw(amount);
    } else {
        System.out.println("Rejected.");
    }
}

protected void withdraw(double amount) {

  if (getBalance() >= amount) {
    setBalance(getBalance() - amount);
  } else {
    System.out.println("Rejected.");
  }
}

В производственном классе ...

@Override
protected void withdraw(double amount) {

  if (getOverDraftLimit() + getBalance() >= amount) {
    setBalance(getBalance() - amount);
  } else {
    System.out.println("Rejected.");
  }
}

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