2

I have a method in my class that does nothing.

public class SpecialCheckingAccount extends BankAccount
{
    public void deductWithdrawalFees()
    {}
}

That method is only there because BankAccount has it as an abstract method. BankAccount calls deductWithdrawalFees() every time someone makes a withdrawal. It's supposed to deduct a withdrawal fee.

The SpecialCheckingAccount class represents a special checking account that doesn't have a withdrawal fee.

I was under the impression every method should have a javadoc. How do you javadoc a method like this?

EDIT: deductWithdrawalFees() in the BankAccount class (the abstract superclass) has Javadoc ("Deduct the fees associated with making a deposit from the balance") but I feel that it doesn't quite apply to an empty implementation, where nothing is technically deducted, and the fee is nonexistent. Thus I don't think inheriting the javadoc would really be an answer to this question.

Soundsgoood
  • 315
  • 3
  • 8
  • Possible duplicate of [Overridden methods in JavaDoc](http://stackoverflow.com/questions/15905127/overridden-methods-in-javadoc) – Iłya Bursov May 02 '17 at 20:13
  • 7
    I would take this and expand on it, explaining why the method is there with no implementation: "The SpecialCheckingAccount class represents a special checking account that doesn't have a withdrawal fee." – victor May 02 '17 at 20:13
  • 2
    @victor That is a good answer. You should write it as an answer. – Andreas May 02 '17 at 20:14
  • Note that it's not necessarily a good idea to use inheritance for this. By allowing your method to be overridden like this, you presumably are giving implementors access to internals of the `BankAccount` class in order to deduct the fee - what's to stop them draining the bank account (accidentally or otherwise). Instead, for example, you could provide a `WithdrawalFeeStrategy` as a constructor parameter, which returns the amount of fee to deduct for a given size of transaction. – Andy Turner May 02 '17 at 20:20

3 Answers3

5

I would take this and expand on it, explaining why the method is there with an implementation that does nothing: "The SpecialCheckingAccount class represents a special checking account that doesn't have a withdrawal fee."

Suggestion from @Andreas: A good Java Runtime Library example of something like this is the javadoc of AbstractList.set(int index, E element), which repeats the javadoc of the interface and adds: This implementation always throws an UnsupportedOperationException. --- To use the same phrasing, your javadoc could say: This implementation does nothing, since a special checking account doesn't have a withdrawal fee.

victor
  • 802
  • 7
  • 12
  • 1
    A good Java Runtime Library example of something like this is the javadoc of [`AbstractList.set(int index, E element)`](https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#set-int-E-), which repeats the javadoc of the interface and adds: *This implementation always throws an UnsupportedOperationException.* --- To use the same phrasing, the javadoc could say: *This implementation does nothing, since a special checking account doesn't have a withdrawal fee.* --- (Victor, you can enhance your answer with this, if you want) – Andreas May 02 '17 at 20:25
1

Why write a Javadoc at all? BankAccount.deductWithdrawalFees() should have one, and that should be all that is needed. I would however document the empty block like this:

public class SpecialCheckingAccount extends BankAccount
{
    @Override
    public void deductWithdrawalFees()
    {
        // nop: SpecialCheckingAccount has no withdrawal fee.
    }
}

You should also add the @Overrideannotation.

Axel
  • 13,939
  • 5
  • 50
  • 79
0

You could have the deduction be a value of zero to have it "function". Then specify in the doc the purpose of the special checking account is to have no withdrawal fees.

Steve
  • 91
  • 1
  • 7