-3

Not sure why I would need to, but would it be possible in Java to have an abstract super with a concrete subclass that has an abstract sub of its own? Presuming that abstract would eventually have concrete classes under it.

James Tatum
  • 1

2 Answers2

1

Yes, you can have both concrete class extending abstract class and vice versa - abstract class extending concrete class.

public abstract class A {

}

public class B extends A {

}

public abstract class C extends B {

}
lexicore
  • 42,748
  • 17
  • 132
  • 221
  • @JamesTatum If you feel that my answer helped you, you could [accept my answer](http://meta.stackexchange.com/a/5235). – lexicore May 07 '18 at 19:17
  • No that is really bad pratice ... It doesn't have any sense. Look for UML diagrams, you'll see that even if you can do it, you really shouldn't, especially if you want your structure to have actually a sense (i.e. help other people working with you to understand what you do). – Lutzi May 07 '18 at 19:19
  • @Lutzi First of all, the question was if this is possible in Java, not if it is a good practice or not. UML diagrams are not an argument at all as they simply communicate models. – lexicore May 07 '18 at 19:22
  • Yeah totally, and these kind of models should always have sense ! How can you justify the specialization of a concrete concept to be abstract ? A specialization of a concrete concept is concrete by definition. – Lutzi May 07 '18 at 19:25
  • @Lutzi If you're saying that an abstract class extending a concrete class is a bad practice, let me remind you that in most cases abstract classes extend a concrete class. – lexicore May 07 '18 at 19:25
  • I am saying that in the case of UML models, not about using concrete class of some packages. In UML diagram, a specialization of a concrete class should never be abstract, as it hasn't any sense. So yeah, you can do things that have no sense, Java doesn't forbid it, but you just shouldn't. As much as you should access fields in another way that with getters/setters, even if you could. – Lutzi May 07 '18 at 19:30
  • @Lutzi What's possible or not possible in UML class diagrams is absolutely irrelevant. *As much as you should access fields in another way that with getters/setters, even if you could* - it is absolutely OK to use fields directly. – lexicore May 07 '18 at 19:34
  • Here is some lecture for you, if you really think that accessing fields directly is a good practice : https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors – Lutzi May 07 '18 at 19:37
  • @Lutzi It's not like there's lack of criticism on accessors. https://softwareengineering.stackexchange.com/questions/21802/when-are-getters-and-setters-justified – lexicore May 07 '18 at 19:42
-1

No that is a really bad practice. Event if Java allows it, it doesn't have any sense from the point of view of UML diagrams.

A class is abstract if it doesn't implement all the behavior expected. Then in the concrete sub-class, it is concrete because it implements all the behavior needed. Then, having an abstract sub-sub-class doesn't make any sense. It is a specialization of a concrete class, meaning it has all the protocol needed for that object.

In other terms, a specialization of a concrete concept can't be abstract.

Lutzi
  • 416
  • 2
  • 13
  • In Java, most abstract classes extend a concrete class. Every abstract class has at least one concrete super*class up in the hierarchy. This somewhat invalidates the "bad practice" argument. – lexicore May 07 '18 at 19:30
  • You are talking about specialization of native classes, or classes from packages. I am talking about UML diagrams, about models that represent our world. Yeah I know that `Object` is not an abstract class, but it doesn't mean that you should take it as an argument. If he/she wants to model in his/her own way, okay, but UML and Java have convention the prevent building models that don't have any sense, and can't be extended in the future. – Lutzi May 07 '18 at 19:34
  • *but UML and Java have convention* - you have just invented this convention. What is *native classes*? *classes from packages* - all classes are from packages. – lexicore May 07 '18 at 19:36
  • @lexicore *Every abstract class has at least one concrete super*class up in the hierarchy.* - Do you really want to call it **every**? Does all abstract class have a *concrete* super class (though many abstract class extend other abstract class - like in Collections library) – Thiyagu May 07 '18 at 19:37
  • @lexicore Unless you meant **Object** (by implicit) – Thiyagu May 07 '18 at 19:38
  • *it doesn't mean that you should take it as an argument* - why not? This is how Java is built. I am sorry this does not fit your narrative, but this *directly* invalidates your argument about best practices. – lexicore May 07 '18 at 19:38
  • @user7 Yes, every, and I do mean `Object`. – lexicore May 07 '18 at 19:39
  • I just don't agree with you. UML diagrams (and Java hierarchy) should have sense about our world. For me it seems legit. You have your arguments, I have mine. I'll not go on as I'm probably more stubborn as you (I recognize it). For me the only legit question for a diagram is : does your diagram make sense ? Is it a senseful representation ? Asking this question leads to avoid specialize concrete classes into abstract classes. – Lutzi May 07 '18 at 19:49