RRSOra? wrote:If DerivedCourse is abstract, it will create a compile error. If you fail to implement an abstract method and you don't define the class as abstract, it will create a compile error. Really: Java is a well designed language; you'll have to do something REALLY dumb to fool the compiler.
courses.add(new DerivedCourse()); Will this step error out?
RRSOra? wrote:you are misapplying the features of OOP. if i have an instance of Course and call a method on it, then that code does not care what concrete subclass of Course it happens to be using. if in the future, i refactor the class hierarchy of Course and the actual instance at runtime changes, i still don't need to change that code.
Thanks. But my question was in relation to the real-time scenario I have mentioned. To rephrase, have you ever faced a situation in Java design where you had to convert a concrete class into an abstract class and in such scenarios did you face any ripple effects in your code? In my example, what will happen to courses.add(new DerivedCourse()) if it is converted from a concrete class to Abstract class? My knowledge of OOPS says that such changes to a class should not result in changes to the code involving courses.add(new DerivedCourse()). Is it mandatory to ensure that courses.add(new DerivedCourse()) must be removed?