This discussion is archived
5 Replies Latest reply: Dec 21, 2012 10:02 AM by EJP RSS

Abstract class Polymorphism

RRSOra? Newbie
Currently Being Moderated
Hi,

I am learning Java and was going through Abstract classes and Polymorphism. Let's say

ArrayList<Course> courses = new ArrayList<Course>;

Let LearnAbstractClasses be an abstract method in Course class. Let DerivedCourse be derived from Course. If LearnAbstractClasses method is not implemented in DerivedCourse, then DerivedCourse is also an abstract class.

courses.add(new DerivedCourse()); Will this step error out? My question is in real-time scenario, I might be initially creating DerivedCourse as a concrete class by implementing LearnAbstractClasses method and would have added it in courses. Due to some reason if I remove LearnAbstractClasses method from DerivedCourse afterward and make DerivedCourse as a concrete class, won't this have a ripple effect on courses.add(new DerivedCourse()) step? I guess this is the ripple effect that OOPS is supposed to avoid.

Kindly indicate to me if such a scenario is quite common in real-time and if there is some other way out of this.
  • 1. Re: Abstract class Polymorphism
    gimbal2 Guru
    Currently Being Moderated
    RRSOra? wrote:
    courses.add(new DerivedCourse()); Will this step error out?
    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.

    You shouldn't be hanging around in a forum you should be experimenting with this stuff yourself to see first hand what happens. And please: stick to standardized Java naming rules. Method names start with a lowercase character, so its learnAbstractClasses(). As you write it now you can't really easily tell if you're talking about a class or a method.
  • 2. Re: Abstract class Polymorphism
    RRSOra? Newbie
    Currently Being Moderated
    Hi,

    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?
  • 3. Re: Abstract class Polymorphism
    aksarben Journeyer
    Currently Being Moderated
    If by "real time" you mean "run time," then what you're asking is impossible. You can't change a class' type at run time after the class loader has loaded it. On a different level, if you find yourself wanting to do this, it's prima facie evidence that your design is faulty & needs rethinking.
  • 4. Re: Abstract class Polymorphism
    EJP Guru
    Currently Being Moderated
    @OP Don't misuse standard terminology. 'Real-time' has a specific meaning in computing, and that isn't it. Electrical engineering wouldn't have got very far if some engineers said volt when they meant amp.
  • 5. Re: Abstract class Polymorphism
    jtahlborn Expert
    Currently Being Moderated
    RRSOra? wrote:
    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?
    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.

    however, in your case you are referring to the instantiation of a concrete Course instance. it would be silly to think that the code which actually cares which instance it is instantiating is not going to need to change if you change the concrete classes in the hierarchy. that said, there are ways of abstracting that away as well, if you need it. If you have code which needs to instantiate Course instances but doesn't need to know the ultimate runtime implementation class, then you can use the Factory pattern. regardless, you still get to a piece of code (in this case, the Factory implementation), which will need to change if you change the concrete classes in the class hierarchy.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points