Timeline for Convenience inheritance
Current License: CC BY-SA 4.0
41 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7 at 13:22 | answer | added | Martin Maat | timeline score: 0 | |
| Oct 7 at 11:18 | answer | added | Doc Brown | timeline score: 5 | |
| Sep 24 at 13:58 | comment | added | Doc Brown | Thanks a lot, now I think I understand much better what you are looking for. | |
| Sep 24 at 12:52 | comment | added | Sergey Zolotarev | @DocBrown I just did | |
| Sep 24 at 12:51 | history | edited | Sergey Zolotarev | CC BY-SA 4.0 |
added 474 characters in body; edited title
|
| Sep 24 at 12:31 | comment | added | Sergey Zolotarev | @DocBrown it's about "convenience inheritance" – inheriting from classes that have zero semantics on their own but ease your life as a developer | |
| Sep 24 at 11:25 | comment | added | Doc Brown | Ok, let me try to explain my concerns with this question a final time. "Extending a class" in Java is a synonym for inheriting from a class. "Extending a base class" is semantically not different - since a class becomes a base class (a.k.a. superclass) when inheriting from it. So literally you are asking "Is inheritance an antipattern?". And that's a far too general question, there have been whole essays written about the right and wrong usage of inheritance. I suspect you have a more special situation in mind, but so far I failed to understand what kind of "more special" this should be. | |
| Sep 23 at 21:04 | review | Suggested edits | |||
| Sep 23 at 23:08 | |||||
| Sep 22 at 10:16 | comment | added | Sergey Zolotarev | @DocBrown I meant that by adding an example, I would make the question too specific. I wanted it to be general | |
| Sep 22 at 9:30 | comment | added | Doc Brown | @SergeyZolotarev: I don't know what's wrong with your example, you were the one who wrote "That's why I didn't want to add an example", giving me the impression I misunderstood here something. | |
| Sep 22 at 8:31 | comment | added | Sergey Zolotarev | @DocBrown by the way, what's wrong with my example? | |
| Sep 22 at 8:31 | comment | added | Sergey Zolotarev | @DocBrown "you make the assumption your question has an answer which is independent of the context" One can always give an answer like "If X, do this; if , do that" | |
| Sep 22 at 5:38 | comment | added | Doc Brown | ... moreover, the fact you are opposed to examples shows you make the assumption your question has an answer which is independent of the context. Sorry, but this is most probably wrong. I think the best approach would here when you find us different examples for the kind of "base class extentions" you have in mind (together with their usage context), then we could find improvements for the issues you have with them. You might be looking for a general (anti-)pattern which is probably not so general as you think it is. | |
| Sep 22 at 5:27 | comment | added | Doc Brown | " That's why I didn't want to add an example" - when an example does not help to explain what you want to ask, the solution is not to add no example at all, the solution is to find a better example. | |
| Sep 21 at 13:17 | comment | added | Sergey Zolotarev |
@sfiss note there may be other ways to extract an Authentication, not necessarily involving request headers. If you declare extractAuthentication(HttpHeaders headers) in the interface directly, you would force implementers to do it in one specific way
|
|
| Sep 21 at 13:12 | comment | added | Sergey Zolotarev |
@sfiss why should it? Say, there's some AuthenticationExtractor interface that declares Authentication extractAuthentication(HttpRequest request). A base abstract HeadersAuthenticationExtractor would implement it by extracting the headers and then passing it to its own abstract Authentication extractAuthentication (HttpHeaders headers). Now, by extending the base class you can extract the authentication claim from the headers right away instead of first extracting the headers from the request (let's ignore the fact that accessing request headers is a trivial one-liner)
|
|
| Sep 21 at 12:19 | comment | added | sfiss | In that Case (Base.doEntireThing) it should be part of the entire API (and thus be public on the base class) and your points/questions in the post become irrelevant? | |
| Sep 21 at 9:19 | comment | added | Sergey Zolotarev |
@DocBrown not necessarily. That's why I didn't want to add an example. I hoped the discussion to be general instead of being about our architecture mess. You can extend a base class that implements an interface declaring five methods, four of which are implemented by the base class for you. Or you can extend BaseDoer implements Doer so that you implement doSmallEasyImplementationSpecificThing() instead of implementing doEntireThing() (the base class's implementation of the latter would invoke the former, which is declared abstract)
|
|
| Sep 21 at 9:14 | history | edited | Sergey Zolotarev | CC BY-SA 4.0 |
added 7 characters in body; edited title
|
| Sep 21 at 8:41 | comment | added | Sergey Zolotarev | @DocBrown did I misuse the phrase "convenience method"? Why should they be static? Those are methods that actually hit the DB and may require the non-ststic state | |
| Sep 21 at 8:38 | comment | added | Doc Brown | ... so what you are really asking is not whether extending an abstract base class is an antipattern, but extending a base class (abstract seems to be irrelevant) for the sole purpose of sharing some reusable methods? Please clarify. | |
| Sep 21 at 7:26 | comment | added | Doc Brown |
Not sure if I understand your example correctly, but shouldn't findWithAppSql (or the other convenience methods in that base class) be static methods?
|
|
| Sep 20 at 23:27 | history | reopened |
Sergey Zolotarev Doc Brown CPlus♦ |
||
| Sep 20 at 23:27 | history | edited | CPlus♦ | CC BY-SA 4.0 |
Keep out the meta-commentary
|
| Sep 20 at 18:24 | comment | added | Sergey Zolotarev | @DocBrown Is it bad? If so, what should be done instead? That's the question. The emphasis in the title question is not on the word "extending" but rather on the entire thing, "extending an abstract base class" | |
| Sep 20 at 13:36 | comment | added | Doc Brown | "However, Doc Brown forced my hand." - well, I was not the first one who asked for an example, and I was not the only one who voted to close this question as unclear. And I have still trouble with this question. "extending an abstract "base" class" - what else would you do with an abstract class if not extend it? Are you asking whether we should only extend non-abstract base classes? Or are you asking whether inheritance is an anti-pattern in general? Or are you talking about using inheritance to have a common place for some reusable methods? | |
| Sep 20 at 12:55 | history | edited | Sergey Zolotarev | CC BY-SA 4.0 |
added 2265 characters in body
|
| S Sep 20 at 12:48 | review | Reopen votes | |||
| Sep 20 at 23:27 | |||||
| S Sep 20 at 12:48 | history | edited | Sergey Zolotarev | CC BY-SA 4.0 |
added 2265 characters in body
Added to review
|
| Sep 20 at 8:38 | comment | added | Filip Milovanović | If you intend to use the base class only for its implementation but not for its API, then yes, generally prefer composition over inheritance. "Won't it be confusing?" - no. In fact it'll only make your intent more clear. Some frameworks might force you to use inheritance anyway or make composition impractical if you are required to extend their base classes. In other languages there may be other reuse mechanisms available, e.g C++ has private inheritance in C++ which doesn't expose the base class API and does not result in an is-a relationship. | |
| Sep 19 at 21:29 | history | closed |
gnat Doc Brown Peter K. |
Needs details or clarity | |
| Sep 19 at 11:16 | history | edited | Sergey Zolotarev | CC BY-SA 4.0 |
deleted 15 characters in body
|
| Sep 19 at 10:06 | comment | added | Neil | I think the mistake would be to make an abstract base class in your library, and then expect the client to know what to override to make it work. If you're writing an abstract base class for yourself, so long as you're respecting LSP, you're probably fine. Just be sure to define an interface to distance your implementation from where you're using it. | |
| Sep 19 at 3:57 | answer | added | candied_orange | timeline score: 2 | |
| Sep 18 at 21:03 | comment | added | Ewan | Also... I have called the software police | |
| Sep 18 at 21:03 | comment | added | Ewan | can you add examples of what you mean by "extending a base class" etc im not following your objection | |
| Sep 18 at 20:17 | review | Close votes | |||
| Sep 19 at 21:33 | |||||
| Sep 18 at 19:42 | comment | added | sfiss | Also, i dont think the software police actually strictly forbids anything, but merely gives advice and guidelines. | |
| Sep 18 at 19:40 | comment | added | sfiss | "Since the "base" class does not define semantics of the class and is only extended to get access to certain implementation decisions, it's an implementation detail." What makes you say that? Inheritance for code reuse only is why its often criticised, but that is not the only way to use that mighty tool. | |
| Sep 18 at 18:49 | history | edited | Sergey Zolotarev | CC BY-SA 4.0 |
added 213 characters in body
|
| Sep 18 at 18:29 | history | asked | Sergey Zolotarev | CC BY-SA 4.0 |