Follow up query of practice exam question: how come Moo is abstract?

[damithc]

[Spoiler alert] this is from the practice exam. Don't read if you haven't done the practice exam yet.

Posting on behalf of a student:

I was wondering why the first answer was incorrect since there is no indication that Moo is an abstract class anywhere.

[qinguorui2001]

because Moo implements Goo, but not show store() method as attribute,(not implement the interface) if it's concrete class, this leads to error, while if Moo is abstract class, then no need for it to implement store()-> no error

[AllardQuek]

What if the store() method has a default implementation?

Then wouldn't Moo not need to be abstract and the code would still compile?

[qinguorui2001]

to be consistent with Foo, see what other classes did

[kaixin-hc]

Hmm, but couldn't this mean something different?

Could it be that Bar might override process() in Foo, and Moo might override process() again, but Moo keeps the default implementation from store and hence does not specify it?

[qinguorui2001]

Could it be that Bar might override process() in Foo, and Moo might override process() again, but Moo keeps the default implementation from store and hence does not specify it?

so why it shows process method in Moo? if it doesn't show, do u know it overrides process of bar ? we can omit the method, but as the diagram is for human reading, at least it should be clear, if u don't write store in Moo, the first option is question one could raise

[fans2619]

What if the store() method has a default implementation?

Then wouldn't Moo not need to be abstract and the code would still compile?

Erm Goo is an interface, so the store() method cannot have a default implementation?

[kaixin-hc]

@fans2619 In java you can have default implementations in the interfaces (see https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html which was linked in the textbook under c++ to Java). Though I do think you're right in that most people prefer not to put default implementations in interfaces and just use abstract classes if they need to do that...

@qinguorui2001 Sorry, I don't understand. What I'm saying is that given that UML diagrams should omit information that is not required, we should assume that all information shown is relevant. Methods can be omitted if they don't add relevant information, and we know it inherits. Referencing examples from the textbook, we can see that its valid to omit methods that aren't overridden, so it makes sense to assume the inclusion means that they could be overridden (example from Class inheritance under class diagrams in the UML section):

I think by human reading both the interpretation that Moo is abstract since it didn't implement store OR the interpretation that Moo is not abstract & store has a default method should be valid. I think one of the limitations of UML is that there are these sort of ambiguities that need to be resolved by referencing the code / documentation alongside the diagram.

[damithc]

What if the store() method has a default implementation?

Then wouldn't Moo not need to be abstract and the code would still compile?

Good point @AllardQuek . The question doesn't take the possibility of default implementations into account (which is a feature added to Java more recently).

[fans2619]

In java you can have default implementations in the interfaces (see https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html which was linked in the textbook under c++ to Java).

Thanks for letting me know this! I just went to try and it works!

[chunweii]

Is there a way to distinguish default methods and abstract methods in interfaces for UML diagrams?

For eg. using italics for abstract methods (or writing {abstract} beside the method) But the problem with that is the examples in the textbook do not indicate that the methods in the interface are abstract.

[damithc]

Is there a way to distinguish default methods and abstract methods in interfaces for UML diagrams?

No. It's a Java thing, not a UML thing.

[qinguorui2001]

hi,prof. during exam, do we consider the default method?

[damithc]

hi,prof. during exam, do we consider the default method?

If it is relevant, the questions will mention it.

[chengseong]

So to clarify, the reason why Moo needs to be an abstract class is because we are under the assumption that Goo did not have a default implementation of store() and Moo did not override store(), hence it must be an abstract class since abstract classes do not need to implement methods from the interface it implements?

[kevinchua6]

@chengseong Yes, that is correct!

[damithc]

So to clarify, the reason why Moo needs to be an abstract class is because we are under the assumption that Goo did not have a default implementation of store() and Moo did not override store(), hence it must be an abstract class since abstract classes do not need to implement methods from the interface it implements?

Yes.

[kaixin-hc]

...given that UML diagrams should omit information that is not required, we should assume that all information shown is relevant. Methods can be omitted if they don't add relevant information, and we know it inherits. Referencing examples from the textbook, we can see that its valid to omit methods that aren't overridden, so it makes sense to assume the inclusion means that they could be overridden (example from Class inheritance under class diagrams in the UML section):

I think by human reading both the interpretation that Moo is abstract since it didn't implement store OR the interpretation that Moo is not abstract & store has a default method should be valid. I think one of the limitations of UML is that there are these sort of ambiguities that need to be resolved by referencing the code / documentation alongside the diagram.

Sorry prof @damithc , could I check that my understanding is correct (that both interpretations are valid if we don't make the above assumption)? Thank you!

[chengseong]

...given that UML diagrams should omit information that is not required, we should assume that all information shown is relevant. Methods can be omitted if they don't add relevant information, and we know it inherits. Referencing examples from the textbook, we can see that its valid to omit methods that aren't overridden, so it makes sense to assume the inclusion means that they could be overridden (example from Class inheritance under class diagrams in the UML section):

I think by human reading both the interpretation that Moo is abstract since it didn't implement store OR the interpretation that Moo is not abstract & store has a default method should be valid. I think one of the limitations of UML is that there are these sort of ambiguities that need to be resolved by referencing the code / documentation alongside the diagram.

Sorry prof @damithc , could I check that my understanding is correct? Thank you!

So my understanding is that in a UML diagram you omit the unimportant points, so to put it another way you always highlight the important points of the implementation. Which means that in this case, the fact that store() being overridden is important and hence should always be included in the diagram, whereas it will just be omitted when store() is not being overridden. Exactly like how process() appears in all 3 classes meaning that both Bar and Moo overrides the process() method.

[damithc]

...given that UML diagrams should omit information that is not required, we should assume that all information shown is relevant. Methods can be omitted if they don't add relevant information, and we know it inherits. Referencing examples from the textbook, we can see that its valid to omit methods that aren't overridden, so it makes sense to assume the inclusion means that they could be overridden (example from Class inheritance under class diagrams in the UML section):

I think by human reading both the interpretation that Moo is abstract since it didn't implement store OR the interpretation that Moo is not abstract & store has a default method should be valid. I think one of the limitations of UML is that there are these sort of ambiguities that need to be resolved by referencing the code / documentation alongside the diagram.

Sorry prof @damithc , could I check that my understanding is correct (that both interpretations are valid if we don't make the above assumption)? Thank you!

You are right @kaixin-hc If the child class repeats a method from the parent class, that means it is definitely overridden. Method that are simply inherited should not be repeated in the child class. However, even overridden methods can be omitted if not relevant to the purpose of the diagram.

[zhangchengchuan]

In this case, would the statement "Removing the process() from Moo class will not cause a compilation error" be wrong, because even though removing process() is totally fine (just not overriding bar's process() ), there will still be a compilation error because store() is not implemented in the first place?

[damithc]

In this case, would the statement "Removing the process() from Moo class will not cause a compilation error" be wrong, because even though removing process() is totally fine (just not overriding bar's process() ), there will still be a compilation error because store() is not implemented in the first place?

The removal will not cause a compilation error (i.e., the compilation error is caused by something else).