I noticed in the “Observer Pattern: Solution video” Mosh mentioned the Subject class (DataSource class) is an abstract class. But in the following “Implementation” video he does not make the Subject class abstract, none of the methods in the Subject class are abstract, he actually defines an implementation for them.
Am I correct or did I miss anything? I just want to make sure I understood what was said on the video.
I took a look. I also find your question in line with some of my confusion during this course. What has been most difficult in this Design Patterns Part One course for me has been understanding the relationships between these various classes, especially seeing the way the code itself relates to the three types of lines drawn to show distinct types of relationships in the UML. I am not positive this is accurate every time.
With this specific design pattern, I think that Mosh chose to make Subject a parent of DataSource. So here, Subject is at a “higher-level of abstraction,” and then DataSource inherits from Subject. He does mark this as an Abstract Class in the design pattern for sure. And usually, whenever he says that or marks it that way, he implements a Java abstract class.
The difference I believe would be determined by whether you need those methods to be the same or unique among the classes this “more abstract” class extends. I think that whenever he uses an abstract class, he overrides at least some methods held in common from that abstract class definition with specific implementations of those methods. When he overrides all of the methods held in common (none shared in terms of their actual implementation), then he uses an interface.
Hopefully, Mosh or someone with more substantial Java and OOP experience can add more to say if this is getting at what’s going on here…
There are multiple reasons to make a class abstract. I believe Mosh just wanted to prevent clients from directly instantiating the Subject class, but forgot to do it in the implementation.
While it is true that having an abstract method in a class forces you to mark that class as abstract, it is not the case that using an abstract class forces you to have an abstract method. Making a class abstract does a few other things, for example:
In this case, I think Mosh was simply marking the Subject class as abstract because he would want to prevent clients from creating a literal instance of the Subject class (forcing them to use the concrete classes that extend Subject). So clients cannot use new Subject() and are instead forced to instantiate the subclasses.
Now, Mosh did forget to mark it as abstract in the implementation video which I think is an innocent mistake, but I believe that was his intention. After all, what would you do with a new Subject()? Robust, production-ready code would have marked the Subject class as abstract to prevent that sort of thing.
So, you are correct that he did not mark it as abstract, but he probably should have done so. This is the sort of thing that should have been flagged in code review.