"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Dave Tolls wrote:You could also make your class final, which would (should?) prevent the warning.
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Roel De Nijs wrote:
Dave Tolls wrote:You could also make your class final, which would (should?) prevent the warning.
Then you'll get a compiler error instead (if you have subclasses of course which seems to be the case based on the OP)
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Fred Kleinschmidt wrote:But your superclass might call some method if its own that you have overridden.
Stephan van Hulst wrote:If you make MachineSelect final, the methods won't be overridable and your problem is solved.
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Fred Kleinschmidt wrote:For any methods called in your constructor that are overrides or public, create a private method to do that functionality, and call hose private methoids from your constructor and from the public or overridden methods. For example, let's take AddItem:
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
J. Kevin Robbins wrote:
Stephan van Hulst wrote:If you make MachineSelect final, the methods won't be overridable and your problem is solved.
No joy. Still get the compiler warnings.
J. Kevin Robbins wrote:That did it! No warnings, the code works the same, and I feel better about having more robust code in the project.
Fred Kleinschmidt wrote:NO - you NEVER call the overridden method from the private method. It's the other way around. The overridden method calls the private method, and the private method does all the work.
Fred Kleinschmidt wrote:The private method could even call super.addItem() if desired (for example, if it wants to do whatever its superclass does, plus add logging).
you NEVER call the overridden method from the private method
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
If the original AddItem changes for any reason, you (or someone else) must not forget to update MyAddItem