AFreshmanSeminar.java |
package lectures.inheritance.abstract_classes; import util.annotations.WebDocuments; @WebDocuments({"Lectures/InheritanceAbstractClasses.pptx", "Lectures/InheritanceAbstractClasses.pdf", "Videos/InheritanceAbstractClasses.avi"}) public class AFreshmanSeminar extends ACourse implements FreshmanSeminar { public AFreshmanSeminar (String theTitle, String theDept) { super (theTitle, theDept); } @Override public int getNumber() { return SEMINAR_NUMBER; } } /* * (T/F) AFreshmanSeminar and AnotherFreshmanSeminar have identical runtime behaviors. * * Now consider the class ACourse, that both AFreshmanSeminar and ARegularCourse extended. * It allowed the reuse of code between the two classes the same way that the inheritance * hierarchy between AnotherRegularCourse and AnotherFreshmanSeminar did. However, * answer the following question: * * (T/F) It makes logical sense for ARegularCourse to extend ACourse. * * We can see the benefit of using this hierarchy rather than the previous one for reusing * code. Now let us think of why ACourse would be abstract. In our course scheme, is there * ever a course that is not either a freshman seminar or a regular course? * * (T/F) It makes logical sense to instantiate ACourse. * * (T/F) Abstract classes allow reuse of code while making only meaningful * subclass relationships and allowing only meaningful instantiations. */