{"id":293,"date":"2016-08-07T15:21:24","date_gmt":"2016-08-07T15:21:24","guid":{"rendered":"http:\/\/www.rangakrish.com\/?p=293"},"modified":"2016-08-08T01:51:17","modified_gmt":"2016-08-08T01:51:17","slug":"is-deriving-from-a-concrete-class-bad","status":"publish","type":"post","link":"https:\/\/www.rangakrish.com\/index.php\/2016\/08\/07\/is-deriving-from-a-concrete-class-bad\/","title":{"rendered":"Is Deriving from a Concrete Class Bad?"},"content":{"rendered":"

In my first post on Julia<\/a>, I noted that the language does not allow deriving from a concrete<\/strong><\/em> (i.e., non-abstract<\/strong><\/em>) class. It definitely came as a surprise because in most OO languages (C++, Java, Scala, C#, etc.) such a restriction does not exist.<\/p>\n

It is true that when you design an inheritance hierarchy, you have to satisfy the Liskov Substitution Principle<\/a>. For instance, it does not make sense to derive Car<\/strong><\/em> from SpaceShuttle<\/strong><\/em> because by no stretch of imagination can we say that a Car<\/strong><\/em>\u00a0is-a SpaceShuttle<\/strong><\/em>. By the way, this is a modelling issue and is not enforced by most programming languages (that I am familiar with). And as long as you model the world reasonably well<\/em> (remember that no model is perfect), your program is deemed good and fit for use.<\/p>\n

In the context of Julia, we are talking about deriving a class from a concrete<\/strong><\/em> class. A concrete class is one which can be instantiated to create objects of that type. A concrete<\/strong><\/em> class is supposed to have fully-defined behaviour and hence is independently usable. An abstract<\/strong><\/em> class is the opposite of concrete<\/strong><\/em> class. It has either no behaviour or partially-defined behaviour and so cannot be independently used, or instantiated directly. An example of abstract class would be Shape<\/strong><\/em>, whereas Rectangle<\/strong><\/em> is a concrete class. In a majority of cases, it probably makes sense to derive Rectangle<\/strong><\/em> from Shape<\/strong><\/em>. While you can create Rectangle<\/strong><\/em> objects, you cannot create Shape<\/strong><\/em> objects.<\/p>\n

What about Ellipse<\/strong><\/em> and Circle<\/strong><\/em>? If Ellipse<\/strong><\/em> is a concrete class, does it make sense to derive Circle<\/strong><\/em> from it? Or the other way? See this<\/a>\u00a0and this<\/a>\u00a0for some interesting discussion on this debate!<\/p>\n

In the book C++ Coding Standards: 101 Rules, Guidelines, and Best Practices<\/strong>, Herb Sutter and Andrei Alexandrescu propose several guidelines in this regard:<\/p>\n

Item 32. Be clear what kind of class you\u2019re writing<\/strong><\/em><\/p>\n

Item 34. Prefer composition to inheritance<\/strong><\/em><\/p>\n

Item 35. Avoid inheriting from classes that were not designed to be base classes<\/strong><\/em><\/p>\n

Item 37. Public inheritance is substitutability. Inherit, not to reuse, but to be reused<\/strong><\/em><\/p>\n

A careful reading of these sections will convey the idea that it is not wise to derive from a concrete class, reinforcing Julia\u2019s design choice.<\/p>\n

Are there acceptable examples where a class is derived from a concrete base class?\u00a0<\/strong><\/p>\n

I think it is fairly common in GUI frameworks. For example, in Java Swing, we have:<\/p>\n

javax.swing.JTextPane<\/strong><\/em> extends javax.swing.JEditorPane<\/strong><\/em><\/p>\n

javax.swing.JCheckBoxMenuItem<\/strong><\/em> extends javax.swing.JMenuItem<\/strong><\/em><\/p>\n

Another Java example outside the GUI framework is java.util.LinkedHashMap<Key, Val><\/strong><\/em> extending java.util.HashMap<Key, Val><\/strong><\/em><\/p>\n

An example where Colourpoint<\/strong><\/em> is derived from Point<\/strong><\/em> is discussed in this tutorial on Scala<\/a>.<\/p>\n

In his book C++ Programming Style<\/strong>, Tom Cargill discusses an interesting example of Constructor Specialization<\/strong><\/em> (Page 20). Here, the derived class exists merely to provide a convenient (specialized) constructor; it adds no extra functionality, nor overrides any parent behaviour.<\/p>\n

\/\/ Slightly modified for our discussion here.<\/strong><\/em><\/p>\n

class Component {<\/strong><\/em><\/p>\n

private:<\/strong><\/em><\/p>\n

char *name;<\/strong><\/em><\/p>\n

int price;<\/strong><\/em><\/p>\n

int rebate;<\/strong><\/em><\/p>\n

public:<\/strong><\/em><\/p>\n

Component(const char *nm, int pr, int reb) : name(nm), price(pr), rebate(reb) {}<\/strong><\/em><\/p>\n

\/\/ Other methods\u2026<\/strong><\/em><\/p>\n

};<\/strong><\/em><\/p>\n

class Monitor : public Component {<\/strong><\/em><\/p>\n

public:<\/strong><\/em><\/p>\n

Monitor(const char *nm, int pr, int reb = 0) : Component(nm, pr, reb) {}<\/strong><\/em><\/p>\n

};<\/strong><\/em><\/p>\n

Component cdrom(\u201cCD ROM\u201d, 1000, 10);<\/strong><\/em><\/p>\n

Monitor mono(\u201cMono\u201d, 2000);<\/strong><\/em><\/p>\n

Here, Monitor class exists only for providing a more convenient instantiation syntax.<\/p>\n

A common example discussed when teaching about inheritance is the Employee<\/strong><\/em> vs. Manager<\/strong><\/em> relationship. In his classic text, The C++ Programming Language (4th Edition)<\/strong><\/em>, Bjarne Stroustrup devotes several pages showing how it makes sense to derive Manager<\/strong><\/em> class from Employee<\/strong><\/em> class, and even shows how a Director<\/strong><\/em> can be derived from Manager<\/strong><\/em>. In his example, all of these are concrete classes. In Julia this is not valid!<\/p>\n

Since one of the main goals of inheritance is reuse<\/strong><\/em> of behaviour, I feel it should be left to the modeller\/developer to decide how such a reuse can be achieved (subject to the Liskov principle) in a programming language that he chooses for implementation. In my view, preventing legitimate cases of deriving from a concrete class would only force the developer to implement a contrived hierarchy (by introducing unnecessary abstract base classes), which can lead to difficult-to-maintain code and\/or inefficient code.<\/p>\n

I hope the designers of Julia take a re-look at this language restriction!<\/p>\n","protected":false},"excerpt":{"rendered":"

In my first post on Julia, I noted that the language does not allow deriving from a concrete (i.e., non-abstract) class. It definitely came as a surprise because in most OO languages (C++, Java, Scala, C#, etc.) such a restriction does not exist. It is true that when you design an inheritance hierarchy, you have […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[63,17],"tags":[67,66,69,70,68],"class_list":["post-293","post","type-post","status-publish","format-standard","hentry","category-julia","category-programming","tag-c","tag-inheritance","tag-java","tag-liskov-principle","tag-scala"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9OLnF-4J","jetpack-related-posts":[{"id":4012,"url":"https:\/\/www.rangakrish.com\/index.php\/2026\/01\/01\/common-lisp-metaobject-protocol-classes-are-just-objects\/","url_meta":{"origin":293,"position":0},"title":"Common Lisp Metaobject Protocol: Classes are Just Objects!","author":"admin","date":"January 1, 2026","format":false,"excerpt":"In today\u2019s popular languages such as C++, Java, Golang, Rust, Python, etc., classes are fixed constructs defined by the language. They have a definite syntax that can\u2019t be changed while programming. We are all used to this of course. But what makes Common Lisp stand out is that in that\u2026","rel":"","context":"In "LISP"","block_context":{"text":"LISP","link":"https:\/\/www.rangakrish.com\/index.php\/category\/lisp\/"},"img":{"alt_text":"A Simple Class","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2026\/01\/code1-300x42.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":278,"url":"https:\/\/www.rangakrish.com\/index.php\/2016\/07\/07\/multimethods-in-julia\/","url_meta":{"origin":293,"position":1},"title":"Multimethods in Julia","author":"admin","date":"July 7, 2016","format":false,"excerpt":"I got interested in Julia programming language quite recently, primarily because of a project involving image processing and machine learning. The language is still evolving, but already has a rich set of features and a good collection of external libraries\u00a0covering many areas. One of the highlights of the language is\u2026","rel":"","context":"In "Julia"","block_context":{"text":"Julia","link":"https:\/\/www.rangakrish.com\/index.php\/category\/julia\/"},"img":{"alt_text":"Multimethods Example","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2015\/10\/Multimethods.png?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":617,"url":"https:\/\/www.rangakrish.com\/index.php\/2017\/09\/13\/reuse-of-grammars-through-inheritance\/","url_meta":{"origin":293,"position":2},"title":"Reuse of Grammars Through Inheritance","author":"admin","date":"September 13, 2017","format":false,"excerpt":"We are familiar with the advantages of class inheritance in object-oriented languages such as C++, C#, Java, and Python. The ability to reuse functionality via inheritance allows us to express our software design optimally, without having to write redundant code. iLangGen encourages the reuse of grammars by supporting Grammar Inheritance,\u2026","rel":"","context":"In "LISP"","block_context":{"text":"LISP","link":"https:\/\/www.rangakrish.com\/index.php\/category\/lisp\/"},"img":{"alt_text":"Simple Grammar","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/09\/image1.png?resize=350%2C200","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/09\/image1.png?resize=350%2C200 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2017\/09\/image1.png?resize=525%2C300 1.5x"},"classes":[]},{"id":1946,"url":"https:\/\/www.rangakrish.com\/index.php\/2020\/03\/28\/stdis_empty\/","url_meta":{"origin":293,"position":3},"title":"std::is_empty","author":"admin","date":"March 28, 2020","format":false,"excerpt":"In the previous post, we looked at the std::is_destructible type trait. Today, let us try to understand another type trait std::is_empty. As per the specification, is_empty::value will return true in the following cases: - The class\/struct has no non-static data member - The class\/struct does not define a virtual function\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Example4: Union and Bit Field","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/03\/Example4-1.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/03\/Example4-1.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2020\/03\/Example4-1.jpg?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":3675,"url":"https:\/\/www.rangakrish.com\/index.php\/2025\/04\/24\/interfaces-without-inheritance-comparing-c-and-common-lisp\/","url_meta":{"origin":293,"position":4},"title":"Interfaces Without Inheritance: Comparing C++ and Common Lisp","author":"admin","date":"April 24, 2025","format":false,"excerpt":"Clean interface design is a crucial aspect of software engineering since it enables code flexibility, reuse, and maintainability. Developers who prefer an object-oriented approach typically rely on inheritance to define the interface and thus establish type relationships. While this can lead to a good design if approached carefully, detractors of\u2026","rel":"","context":"In "C++"","block_context":{"text":"C++","link":"https:\/\/www.rangakrish.com\/index.php\/category\/c\/"},"img":{"alt_text":"Rectangle and Circle Defined","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2025\/04\/cpp2-251x300.jpg?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1146,"url":"https:\/\/www.rangakrish.com\/index.php\/2018\/11\/04\/modeling-homeopathic-remedy-keynotes-in-flora-2\/","url_meta":{"origin":293,"position":5},"title":"Modeling Homeopathic Remedy Keynotes in Flora-2","author":"admin","date":"November 4, 2018","format":false,"excerpt":"In my last post, I got started with Flora-2 and showed how we can model homeopathic remedies from a therapeutics perspective. Although such a limited view of remedies can be helpful in treating acute ailments, for treating chronic diseases, a comprehensive understanding of the various remedies from the perspective of\u2026","rel":"","context":"In "Flora-2"","block_context":{"text":"Flora-2","link":"https:\/\/www.rangakrish.com\/index.php\/category\/flora-2\/"},"img":{"alt_text":"Multiple Frames for Same Remedy","src":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/11\/Multiple-defn.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/11\/Multiple-defn.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/www.rangakrish.com\/wp-content\/uploads\/2018\/11\/Multiple-defn.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts\/293","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/comments?post=293"}],"version-history":[{"count":0,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/posts\/293\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/media?parent=293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/categories?post=293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rangakrish.com\/index.php\/wp-json\/wp\/v2\/tags?post=293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}