{"id":73391,"date":"2019-11-27T04:17:47","date_gmt":"2019-11-27T11:17:47","guid":{"rendered":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/"},"modified":"2019-11-27T04:17:47","modified_gmt":"2019-11-27T11:17:47","slug":"mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes","status":"publish","type":"post","link":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/","title":{"rendered":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes"},"content":{"rendered":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes<\/title><\/p>\n<article>\n<header>\n<h1>Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes<\/h1>\n<address>Ryan Kay<\/address>\n<p> <time datetime=\"2019-11-27T11:00:00+00:00\">2019-11-27T11:00:00+00:00<\/time><time datetime=\"2019-11-27T11:00:00+00:00\">2019-11-27T11:07:08+00:00<\/time><\/header>\n<p>So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I was to guess why, I assume it is because individuals who focus on theory tend to get into teaching, and individuals who focus on practical information tend to get paid to solve specific problems, using specific languages and tools.<\/p>\n<p>This is, of course, a broad generalization, but if we accept it briefly for arguments sake, it follows that many people (by no means all people) who take on the role of teacher, tend to be either poor at, or utterly incapable of explaining the practical knowledge relevant to a particular concept.<\/p>\n<p>In this article, I will do my best to discuss three core mechanisms which you will find in most Object Oriented Programming (OOP) languages: <em>Inheritance<\/em>, <em>interfaces<\/em> (a.k.a. <em>protocols<\/em>), and <em>abstract classes<\/em>. Rather than giving you technical and complex verbal explanations of what each mechanism <strong>is<\/strong>, I will do my best to focus on what they <strong>do<\/strong>, and <strong>when<\/strong> to use them.<\/p>\n<p>However, before addressing them individually, I would like to briefly discuss what it means to give a theoretically sound, yet practically useless explanation. My hope is that you can use this information to help you sift through different educational resources and to avoid blaming yourself when things do not make sense.<\/p>\n<div data-component=\"FeaturePanel\" data-audience=\"non-subscriber\" data-remove=\"true\"><\/div>\n<h3>Different Degrees Of Knowing<\/h3>\n<h4>Knowing Names<\/h4>\n<p>Knowing the name of something is arguably the most shallow form of knowing. In fact, a name is only generally useful to the extent that it either is commonly used by many people to refer to the same thing and\/or it helps to describe the thing. Unfortunately, as anyone who has spent time in this field has discovered, many people use different names for the same thing (e.g. <em>interfaces<\/em> and <em>protocols<\/em>), the same names for different things (e.g. <em>modules<\/em> and <em>components<\/em>), or names which are esoteric to the point of being absurd (e.g. <em>Either Monad<\/em>). Ultimately, names are just pointers (or references) to mental models, and they can be of varying degrees of usefulness.<\/p>\n<p>To make this field even more difficult to study, I would hazard a guess that for most individuals, writing code is (or at least was) a very unique experience. Even more complicated is understanding how that code is ultimately compiled into machine language, and represented in physical reality as a series of electrical impulses changing over time. Even if one can recall the names of the processes, concepts, and mechanisms that are employed in a program, there is no guarantee that the mental models which one creates for such things are consistent with the models another individual; let alone whether they are objectively accurate.<\/p>\n<p>It is for these reasons, alongside the fact that I do not have a naturally good memory for jargon, that I consider names to be the least important aspect of knowing something. That is not to say that names are useless, but I have in the past learned and employed many design patterns in my projects, only to learn of the commonly used name months, or even years later.<\/p>\n<h4>Knowing Verbal Definitions And Analogies<\/h4>\n<p>Verbal definitions are the natural starting point for describing a new concept. However, as with names, they can be of varying degrees of usefulness and relevance; much of that depending on what the end goals of the learner are. The most common problem I see in verbal definitions is assumed knowledge typically in the form of jargon.<\/p>\n<p>Suppose for example, that I was to explain that a <em>thread<\/em> is very much like a <em>process<\/em>, except that <em>threads<\/em> occupy the same <em>address space<\/em> of a given <em>process<\/em>. To someone who is already familiar with <em>processes<\/em> and <em>address spaces<\/em>, I have essentially stated that <em>threads<\/em> can be associated with their understanding of a <em>process<\/em> (i.e. they possess many of the same characteristics), but they can be differentiated based on a distinct characteristic.<\/p>\n<p>To someone who does not possess that knowledge, I have at best not made any sense, and at worst caused the learner to feel inadequate in some way for not knowing the things <strong>I have assumed<\/strong> they should know. In fairness, this is acceptable if your learners really ought to possess such knowledge (such as teaching graduate students or experienced developers), but I consider it to be a monumental failure to do so in any introductory level material.<\/p>\n<p>Often it is very difficult to provide a good verbal definition of a concept when it is unlike anything else the learner has seen before. In this case, it is very important for the teacher to select an analogy which is likely to be familiar to the average person, and also relevant insofar as it conveys many of the same qualities of the concept.<\/p>\n<p>For example, it is critically important for a software developer to understand what it means when software entities (different parts of a program) are <em>tightly-coupled<\/em> or <em>loosely-coupled<\/em>. When building a garden shed, a junior carpenter may think that it is <em>faster<\/em> and <em>easier<\/em> to put it together using nails instead of screws. This is true up until the point at which a mistake is made, or a change in the design of the garden shed necessitates rebuilding part of the shed.<\/p>\n<p>At this point, the decision to use nails to <em>tightly-couple<\/em> the parts of the garden shed together, has made the construction process as a whole more difficult, likely slower, and extracting nails with a hammer runs the risk of damaging the structure. Conversely, screws can take a bit of extra time to assemble, but they are easy to remove and pose little risk of damaging nearby parts of the shed. This is what I mean by <em>loosely-coupled<\/em>. Naturally, there are cases where you really just need a nail, but that decision ought to be guided by critical thinking and experience.<\/p>\n<p>As I will discuss in detail later on, there are different mechanisms for connecting parts of a program together which provide varying degrees of <em>coupling<\/em>; just like <em>nails<\/em> and <em>screws<\/em>. While my analogy may have helped you understand what this critically important term means, I have not given you any idea of how to apply it outside of the context of building a garden shed. This leads me to the most important kind of knowing, and the key to deeply understanding vague and difficult concepts in any field of inquiry; although we will stick to writing code in this article.<\/p>\n<div><\/div>\n<h4>Knowing In Code<\/h4>\n<p>In my opinion, strictly regarding software development, the most import form of knowing a concept comes from being able to use it in the working application code. This form of knowing can be attained simply by writing lots of code and solving many different problems; jargon names and verbal definitions need not be included.<\/p>\n<p>In my own experience, I recall solving the problem of communicating with a remote database, and a local database through a single <em>interface<\/em> (you will know what that means soon if you do not already); rather than the client (whatever class which talks to the <em>interface<\/em>) needing to call the remote and local (or even a test database) explicitly. In fact, the client had no idea what was behind the interface, so I did not need to change it regardless of if it was running in a production app or a test environment. About a year after I solved this problem, I came across the term \u201cFacade Pattern\u201d, and not long after the term \u201cRepository Pattern\u201d, which are both names that people use for the solution described prior.<\/p>\n<p>All of this preamble is to hopefully illuminate some of the flaws which are most often made in explaining topics such as <em>inheritance<\/em>, <em>interfaces<\/em>, and <em>abstract classes<\/em>. Of the three, <em>inheritance<\/em> is likely the simplest one to both use and understand. In my experience both as a student of programming, and a teacher, the other two are almost invariably an issue to learners unless very special attention is paid to avoiding the mistakes discussed earlier. From this point on, I will do my best to make these topics as simple as they should be, but no simpler.<\/p>\n<h4>A Note On The Examples<\/h4>\n<p>Being most fluent in Android mobile application development myself, I will use examples taken from that platform so that I may teach you about building GUI applications at the same time as introducing language features of Java. However, I will not be going into so much detail that the examples ought to be unintelligible by someone with a cursory understanding of Java EE, Swing or JavaFX. My ultimate goal in discussing these topics is to help you to understand what they mean in the context of solving a problem in just about any sort of application.<\/p>\n<p>I would also like to warn you, dear reader, that at times it may seem like I am being needlessly philosophical and pedantic about specific words and their definitions. The reason for this is that there truly is a deep philosophical underpinning required to understand the difference between something which is <em>concrete<\/em> (real), and something which is <em>abstract<\/em> (less detailed than a real thing). This understanding applies to many things outside of the field of computing, but it is of particularly high importance for any software developer to grasp the nature of <em>abstractions<\/em>. In any case, if my words fail you, the examples in code will hopefully not.<\/p>\n<div><\/div>\n<h3>Inheritance And Implementation<\/h3>\n<p>When it comes to building applications with a graphical user interface (GUI), <em>inheritance<\/em> is arguably the most important mechanism for making it possible to quickly build an application.<\/p>\n<p>Although there is a lesser understood benefit to using <em>inheritance<\/em> to be discussed later, <strong>the primary benefit is to share implementation between classes<\/strong>. This word \u201cimplementation\u201d, at least for the purposes of this article, has a distinct meaning. To give a general definition of the word in English, I might say that to <em>implement<\/em> something, is to <em>make it real<\/em>.<\/p>\n<p>To give a technical definition specific to software development, I might say that to <em>implement<\/em> a piece of software, is to write <em>concrete<\/em> lines of code which satisfy the requirements of said piece of software. For example, suppose I am writing a <em>sum method<\/em>:<br \/>\n<code>private double sum(double first, double second){<\/code><\/p>\n<pre><code>private double sum(double first, double second){\n \/\/TODO: implement\n}\n<\/code><\/pre>\n<p>The snippet above, even though I have made it as far as writing a return type (<code>double<\/code>) and a <em>method declaration<\/em> which specifies the arguments (<code>first, second<\/code>) and the name which can be used to call said <em>method<\/em> (<code>sum<\/code>), it has <strong>not been <em>implemented<\/em><\/strong>. In order to <em>implement<\/em> it, we must complete the <em>method body<\/em> like so:<\/p>\n<pre><code>private double sum(double first, double second){\n return first + second;\n}\n<\/code><\/pre>\n<p>Naturally, the first example would not compile, but we will see momentarily that <em>interfaces<\/em> are a way in which we can write these sorts of <strong>unimplemented<\/strong> functions without errors.<\/p>\n<h4>Inheritance In Java<\/h4>\n<p>Presumably, if you are reading this article, you have used the <code>extends<\/code> Java keyword at least once. The mechanics of this keyword are simple and most often described using examples to do with different kinds of animals or geometric shapes; <code>Dog<\/code>and <code>Cat<\/code>extend <code>Animal<\/code>, and so forth. I will assume that I do not need to explain rudimentary type theory to you, so let us get right into the primary benefit of <em>inheritance<\/em> in Java, via the <code>extends<\/code>keyword.<\/p>\n<p>Building a console-based \u201cHello World\u201d application in Java is very simple. Assuming you possess a Java Compiler (<em>javac<\/em>) and runtime environment (<em>jre<\/em>), you can write a class which contains a <em>main<\/em> function like so:<\/p>\n<pre><code>public class JavaApp{\n public static void main(String []args){\n System.out.println(\"Hello World\");\n }\n}\n<\/code><\/pre>\n<p>Building a GUI application in Java on almost any of its main platforms (Android, Enterprise\/Web, Desktop), with a bit of help from an IDE to generate the skeleton\/boilerplate code of a new app, is also relatively easy thanks to the <code>extends<\/code>keyword.<\/p>\n<p>Suppose that we have an XML Layout called <code>activity_main.xml<\/code> (we typically build user interfaces declaratively in Android, via Layout files) containing a <code>TextView<\/code>(like a text label) called <code>tvDisplay<\/code>:<\/p>\n<pre><code><?xml version=\"1.0\" encoding=\"utf-8\"?>\n<FrameLayout xmlns:android=\"http:\/\/schemas.android.com\/apk\/res\/android\"\n android:layout_width=\"match_parent\" android:layout_height=\"match_parent\">\n\n <TextView\n android:id=\"@+id\/tvDisplay\"\n android:layout_width=\"wrap_content\"\n android:layout_height=\"wrap_content\"\n android:layout_gravity=\"center\"\n \/>\n\n\n<\/FrameLayout>\n<\/code><\/pre>\n<p>Also, suppose that we would like <code>tvDisplay<\/code>to say \u201cHello World!\u201d To do so, we simply need to write a class which uses the <code>extends<\/code>keyword to inherit from the <code>Activity<\/code>class:<\/p>\n<pre><code>import android.app.Activity;\nimport android.os.Bundle;\nimport android.widget.TextView;\n\npublic class MainActivity extends Activity {\n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n\n ((TextView)findViewById(R.id.tvDisplay)).setText(\"Hello World\");\n }\n<\/code><\/pre>\n<p>The effect of inheriting the implementation of the <code>Activity<\/code>class can be best appreciated by taking a quick look at its <a href=\"https:\/\/android.googlesource.com\/platform\/frameworks\/base\/+\/master\/core\/java\/android\/app\/Activity.java\">source code<\/a>. I highly doubt that Android would have become the dominant mobile platform if one needed to <em>implement<\/em> even a small portion of the 8000+ lines necessary to interact with the system, just to generate a simple window with some text. <em>Inheritance<\/em> is what allows us to not have to rebuild the <em>Android framework<\/em>, or whatever platform you happen to be working with, from scratch.<\/p>\n<h4>Inheritance Can Be Used For Abstraction<\/h4>\n<p>Insofar as it can be used to share implementation across classes, <em>inheritance<\/em> is relatively simple to understand. However, there is another important way in which <em>inheritance<\/em> can be used, which is conceptually related to the <em>interfaces<\/em> and <em>abstract classes<\/em> which we will be discussing soon.<\/p>\n<p>If you please, suppose for the next little while that an abstraction, used in the most general sense, is <em>a less detailed representation of a thing<\/em>. Instead of qualifying that with a lengthy philosophical definition, I will try to point out how <em>abstractions<\/em> work in daily life, and shortly thereafter discuss them expressly in terms of software development.<\/p>\n<p>Suppose you are traveling to Australia, and you are aware that the region you are visiting is host to a particularly high density of inland taipan snakes (they are apparently quite poisonous). You decide to consult Wikipedia to learn more about them by looking at images and other information. By doing so, you are now acutely aware of a particular kind of snake which you have never seen before.<\/p>\n<p>Abstractions, ideas, models, or whatever else you want to call them, are less detailed representations of a thing. It is important that they are less detailed than the real thing because a real snake can bite you; images on Wikipedia pages typically do not. <em>Abstractions<\/em> are also important because both computers and human brains have a limited capacity to store, communicate, and process information. Having enough detail to use this information in a practical way, without taking up too much space in memory, is what makes it possible for computers and human brains alike to solve problems.<\/p>\n<p>To tie this back into <em>inheritance<\/em>, all of the three main topics I am discussing here can be used as <em>abstractions<\/em>, or mechanisms of <em>abstraction<\/em>. Suppose that in our \u201cHello World\u201d app\u2019s layout file, we decide to add an <code>ImageView<\/code>, <code>Button<\/code>, and <code>ImageButton<\/code>:<\/p>\n<div>\n<pre><code><?xml version=\"1.0\" encoding=\"utf-8\"?>\n<LinearLayout xmlns:android=\"http:\/\/schemas.android.com\/apk\/res\/android\"\n android:layout_width=\"match_parent\" android:layout_height=\"match_parent\">\n <Button\n android:id=\"@+id\/btnDisplay\"\n android:layout_width=\"wrap_content\"\n android:layout_height=\"wrap_content\"\/>\n\n <ImageButton\n android:id=\"@+id\/imbDisplay\"\n android:layout_width=\"wrap_content\"\n android:layout_height=\"wrap_content\"\/>\n\n <ImageView\n android:id=\"@+id\/imvDisplay\"\n android:layout_width=\"wrap_content\"\n android:layout_height=\"wrap_content\"\/>\n<\/LinearLayout>\n<\/code><\/pre>\n<\/div>\n<p>Also suppose that our Activity has implemented <code>View.OnClickListener<\/code> to handle clicks:<\/p>\n<div>\n<pre><code>public class MainActivity extends Activity implements View.OnClickListener {\n private Button b;\n private ImageButton ib;\n private ImageView iv; \n\n\n @Override\n protected void onCreate(Bundle savedInstanceState) {\n super.onCreate(savedInstanceState);\n setContentView(R.layout.activity_main);\n\n \/\/...\n b = findViewById(R.id.imvDisplay).setOnClickListener(this);\n ib = findViewById(R.id.btnDisplay).setOnClickListener(this);\n iv = findViewById(R.id.imbDisplay).setOnClickListener(this);\n }\n\n @Override\n public void onClick(View view) {\n final int id = view.getId();\n \/\/handle click based on id...\n }\n}\n<\/code><\/pre>\n<\/div>\n<p>The key principle here is that <code>Button<\/code>, <code>ImageButton<\/code>, and <code>ImageView<\/code>inherit from the <code>View<\/code>class. The result is that this function <code>onClick<\/code>can receive click events from disparate (though hierarchically related) UI elements by referencing them as their less detailed parent class. This is far more convenient than having to write a distinct <em>method<\/em> for handling every kind of widget on the <em>Android platform<\/em> (not to mention custom widgets).<\/p>\n<h3>Interfaces And Abstraction<\/h3>\n<p>You may have found the previous code example to be a bit uninspiring, even if you understood why I chose it. Being able to share <em>implementation<\/em> across a hierarchy of classes is incredibly useful, and I would argue that to be the primary utility of <em>inheritance<\/em>. As for allowing us to treat a set of classes that have a common <em>parent class<\/em> as equal in <em>type<\/em> (i.e. as the <em>parent class<\/em>), that feature of <em>inheritance<\/em> has limited use.<\/p>\n<p>By limited, I am speaking of the requirement of child classes to be within the same class hierarchy in order to be referenced via, or known as the parent class. In other words, <em>inheritance<\/em> is a very restrictive mechanism for <em>abstraction<\/em>. In fact, if I suppose that <em>abstraction<\/em> is a spectrum that moves between different levels of detail (or information), I might say that <em>inheritance<\/em> is <strong>the least abstract<\/strong> mechanism for <em>abstraction<\/em> in Java.<\/p>\n<p>Before I proceed to discussing <em>interfaces<\/em>, I would like to mention that as of <em>Java 8<\/em>, two features called <em>Default Methods<\/em> and <em>Static Methods<\/em> have been added to <em>interfaces<\/em>. I will discuss them eventually, but for the moment I would like us to pretend that they do not exist. This is in order for me to make it easier to explain the primary purpose of using an <em>interface<\/em>, which was initially, and arguably still is, <strong>the most abstract mechanism for abstraction in Java<\/strong>.<\/p>\n<h4>Less Detail Means More Freedom<\/h4>\n<p>In the section on <em>inheritance<\/em>, I gave a definition of the word <em>implementation<\/em>, which was meant to contrast with another term we will now go into. To be clear, I do not care about the words themselves, or whether you agree with their usage; only that you understand what they conceptually point to.<\/p>\n<p>Whereas <em>inheritance<\/em> is primarily a tool to share <em>implementation<\/em> across a set of classes, we might say that <em>interfaces<\/em> are primarily a mechanism to share <em>behavior<\/em> across a set of classes. <em>Behavior<\/em> used in this sense is truly just a non-technical word for <em>abstract methods<\/em>. An <em>abstract method<\/em> is a <em>method<\/em> which does not, in fact cannot, contain a <em>method body<\/em>:<\/p>\n<pre><code>public interface OnClickListener {\n void onClick(View v);\n}\n<\/code><\/pre>\n<p>The natural reaction for me, and a number of individuals whom I have tutored, after first looking at an <em>interface<\/em>, was to wonder what the utility of sharing only a <em>return type<\/em>, <em>method name<\/em>, and <em>parameter list<\/em> might be. On the surface, it looks like a great way to create extra work for yourself, or whoever else might be writing the class which <code>implements<\/code>the <em>interface<\/em>. The answer, is that <em>interfaces<\/em> are perfect for situations where you want a set of classes to <em>behave<\/em> in the same manner (i.e. they possess the same public <em>abstract methods<\/em>), but you expect them to <em>implement<\/em> that <em>behavior<\/em> in different ways.<\/p>\n<p>To take a simple but relevant example, the Android platform possesses two classes which are primarily in the business of creating and managing part of the user interface: <code>Activity<\/code> and <code>Fragment<\/code>. It follows that these classes will very often have the requirement of listening to events which pop up when a widget is clicked (or otherwise interacted with by a user). For argument\u2019s sake, let us take a moment to appreciate why <em>inheritance<\/em> will almost never solve such a problem:<\/p>\n<pre><code>public class OnClickManager {\n public void onClick(View view){\n \/\/Wait a minute... Activities and Fragments almost never \n \/\/handle click events exactly the same way...\n }\n}\n<\/code><\/pre>\n<p>Not only would making our <em>Activities<\/em> and <em>Fragments<\/em> inherit from <code>OnClickManager<\/code>make it impossible to handle events in a different manner, but the kicker is that we could not even do that if we wanted to. Both <em>Activity<\/em> and <em>Fragment<\/em> already extend a <em>parent class<\/em>, and Java does not allow multiple <em>parent classes<\/em>. So our problem is that we want a set of classes to <em>behave<\/em> the same way, but <strong>we must<\/strong> have flexibility on how the class <em>implements<\/em> that <em>behavior<\/em>. This brings us back to the earlier example of the <code>View.OnClickListener<\/code>:<\/p>\n<pre><code>public interface OnClickListener {\n void onClick(View v);\n}\n<\/code><\/pre>\n<p>This is the actual source code (which is nested in the <code>View<\/code>class), and these few lines allow us to ensure consistent <em>behavior<\/em> across different widgets (<em>Views<\/em>) and UI controllers (<em>Activities, Fragments, etc.<\/em>).<\/p>\n<h4>Abstraction Promotes Loose-Coupling<\/h4>\n<p>I have hopefully answered the general question about why interfaces exist in Java; among many other languages. From one perspective, they are just a means of sharing code between classes, but they are deliberately less detailed in order to allow for different <em>implementations<\/em>. But just as <em>inheritance<\/em> can be used both as a mechanism for sharing code and <em>abstraction<\/em> (albeit with restrictions on class hierarchy), it follows that <em>interfaces<\/em> provide a more flexible mechanism for <em>abstraction<\/em>.<\/p>\n<p>In an earlier section of this article, I introduced the topic of <em>loose\/tight-coupling<\/em> by analogy of the difference between using <em>nails<\/em> and <em>screws<\/em> to build some kind of structure. To recap, the basic idea is that you will want to use <em>screws<\/em> in situations where changing the existing structure (which can be a result of fixing mistakes, design changes, and so forth) is likely to happen. <em>Nails<\/em> are fine to use when you just need to fasten parts of the structure together and are not particularly worried about taking them apart in the near future.<\/p>\n<p><em>Nails<\/em> and <em>screws<\/em> are meant to be analogous to <em>concrete<\/em> and <em>abstract references<\/em> (the term <em>dependencies<\/em> also applies) between classes. Just so there is no confusion, the following sample will demonstrate what I mean:<\/p>\n<pre><code>class Client {\n private Validator validator;\n private INetworkAdapter networkAdapter;\n\n void sendNetworkRequest(String input){\n if (validator.validateInput(input)) {\n try {\n networkAdapter.sendRequest(input);\n } catch (IOException e){\n \/\/handle exception\n }\n }\n }\n}\n\nclass Validator {\n \/\/...validation logic\n boolean validateInput(String input){\n boolean isValid = true;\n \/\/...change isValid to false based on validation logic\n return isValid;\n }\n}\n\ninterface INetworkAdapter {\n \/\/...\n void sendRequest(String input) throws IOException;\n}\n<\/code><\/pre>\n<p>Here, we have a class called <code>Client<\/code> which possesses two kinds of <em>references<\/em>. Notice that, assuming <code>Client<\/code>does not have anything to do with creating its <em>references<\/em> (it really should not), it is decoupled from the implementation details of any particular network adapter.<\/p>\n<p>There are a few important implications of this <em>loose coupling<\/em>. For starters, I can build <code>Client<\/code>in absolute isolation of any <em>implementation<\/em> of <code>INetworkAdapter<\/code>. Imagine for a moment that you are working in a team of two developers; one to build the front end, one to build the back end. As long as both developers are kept aware of the <em>interfaces<\/em> which couple their respective classes together, they can carry on with the work virtually independently of one another.<\/p>\n<p>Secondly, what if I were to tell you that both developers could verify that their respective <em>implementations<\/em> functioned properly, also independently of each other\u2019s progress? This is very easy with interfaces; just build a <em>Test Double<\/em> which <code>implements<\/code>the appropriate <em>interface<\/em>:<\/p>\n<pre><code>class FakeNetworkAdapter implements INetworkAdapter {\n public boolean throwError = false;\n\n\n @Override\n public void sendRequest(String input) throws IOException {\n if (throwError) throw new IOException(\"Test Exception\");\n }\n}\n<\/code><\/pre>\n<p>In principle, what can be observed is that working with <em>abstract references<\/em> opens the door to increased modularity, testability, and some very powerful design patterns such as the <em>Facade Pattern<\/em>, <em>Observer Pattern<\/em>, and more. They can also allow developers to find a happy balance of designing different parts of a system based on <em>behavior<\/em> (<em>Program To An Interface<\/em>), without getting bogged down in <em>implementation<\/em> details.<\/p>\n<h4>A Final Point On Abstractions<\/h4>\n<p><em>Abstractions<\/em> do not exist in the same way as a <em>concrete<\/em> thing. This is reflected in the Java Programming language by the fact that <em>abstract classes<\/em> and <em>interfaces<\/em> may not be instantiated.<\/p>\n<p>For example, this would definitely not compile:<\/p>\n<pre><code>public class Main extends Application {\n public static void main(String[] args) {\n launch(args);\n }\n\n @Override\n public void start(Stage primaryStage) {\n \/\/ERROR x2:\n Foo f = new Foo();\n Bar b = new Bar()\n\n }\n\n\n private abstract class Foo{}\n private interface Bar{}\n\n\n}\n<\/code><\/pre>\n<p>In fact, the idea of expecting an unimplemented <em>interface<\/em> or <em>abstract class<\/em> to function at runtime makes as much sense as expecting a UPS uniform to float around delivering packages. Something concrete must be behind the <em>abstraction<\/em> for it to be of utility; even if the calling class does not need to know what is actually behind <em>abstract references<\/em>.<\/p>\n<h3>Abstract Classes: Putting It All Together<\/h3>\n<p>If you have made it this far, then I am happy to tell you that I have no more philosophical tangents or jargon phrases to translate. Simply put, <em>abstract classes<\/em> are a mechanism for sharing <em>implementation<\/em> and <em>behavior<\/em> across a set of classes. Now, I will admit straight away that I do not find myself using <em>abstract classes<\/em> all that often. Even so, my hope is that by the end of this section you will know exactly when they are called for.<\/p>\n<h4>Workout Log Case Study<\/h4>\n<p>Roughly a year into building Android apps in Java, I was rebuilding my first Android app from scratch. The first version was the kind of horrendous mass of code that you would expect from a self-taught developer with little guidance. By the time I wanted to add new functionality, it became clear that the <em>tightly coupled<\/em> structure I had built exclusively with <em>nails<\/em>, was so impossible to maintain that I must rebuild it entirely.<\/p>\n<p>The app was a workout log that was designed to allow easy recording of your workouts, and the ability to output the data of a past workout as a text or image file. Without getting into too much detail, I structured the data models of the app such that there was a <code>Workout<\/code>object, which comprised of a collection of <code>Exercise<\/code>objects (among other fields which are irrelevant to this discussion).<\/p>\n<p>As I was implementing the feature for outputting workout data to some kind of visual medium, I realized that I had to deal with a problem: Different kinds of exercises would require different kinds of text outputs.<\/p>\n<p>To give you a rough idea, I wanted to change the outputs depending on the type of exercise like so:<\/p>\n<ul>\n<li>Barbell: 10 REPS @ 100 LBS<\/li>\n<li>Dumbbell: 10 REPS @ 50 LBS x2<\/li>\n<li>Bodyweight: 10 REPS @ Bodyweight<\/li>\n<li>Bodyweight +: 10 REPS @ Bodyweight + 45 LBS<\/li>\n<li>Timed: 60 SEC @ 100 LBS<\/li>\n<\/ul>\n<p>Before I proceed, note that there were other types (working out can become complicated) and that the code I will be showing has been trimmed down and changed to fit nicely into an article.<\/p>\n<p>In keeping with my definition from before, the goal of writing an <em>abstract class<\/em>, is to <em>implement<\/em> everything (even <em>state<\/em> such as <em>variables<\/em> and <em>constants<\/em>) which is shared across all <em>child classes<\/em> in the <em>abstract class<\/em>. Then, for anything which changes across said <em>child classes<\/em>, create an <em>abstract method<\/em>:<\/p>\n<div>\n<pre><code>abstract class Exercise {\n private final String type;\n protected final String name;\n protected final int[] repetitionsOrTime;\n protected final double[] weight;\n\n protected static final String POUNDS = \"LBS\";\n protected static final String SECONDS = \"SEC \";\n protected static final String REPETITIONS = \"REPS \";\n\n public Exercise(String type, String name, int[] repetitionsOrTime, double[] weight) {\n this.type = type;\n this.name = name;\n this.repetitionsOrTime = repetitionsOrTime;\n this.weight = weight;\n }\n\n public String getFormattedOutput(){\n StringBuilder sb = new StringBuilder();\n sb.append(name);\n sb.append(\"n\");\n getSetData(sb);\n sb.append(\"n\");\n return sb.toString();\n }\n\n \/**\n * Append data appropriately based on Exercise type\n * @param sb - StringBuilder to Append data to\n *\/\n protected abstract void getSetData(StringBuilder sb);\n \n \/\/...Getters\n}\n\n<\/code><\/pre>\n<\/div>\n<p>I may be stating the obvious, but if you have any questions about what should or should not be <em>implemented<\/em> in the <em>abstract class<\/em>, the key is to look at any part of the <em>implementation<\/em> which has been repeated in all child classes.<\/p>\n<p>Now that we have established what is common amongst all exercises, we can begin to create child classes with specializations for each kind of String output:<\/p>\n<h5>Barbell Exercise:<\/h5>\n<div>\n<pre><code>class BarbellExercise extends Exercise {\n public BarbellExercise(String type, String name, int[] repetitionsOrTime, double[] weight) {\n super(type, name, repetitionsOrTime, weight);\n }\n\n @Override\n protected void getSetData(StringBuilder sb) {\n for (int i = 0; i <\/code><\/pre>\n<\/div>\n<h5>Dumbbell Exercise:<\/h5>\n<div>\n<pre><code>class DumbbellExercise extends Exercise {\n private static final String TIMES_TWO = \"x2\";\n\n public DumbbellExercise(String type, String name, int[] repetitionsOrTime, double[] weight) {\n super(type, name, repetitionsOrTime, weight);\n }\n\n @Override\n protected void getSetData(StringBuilder sb) {\n\n for (int i = 0; i <\/code><\/pre>\n<\/div>\n<h5>Bodyweight Exercise:<\/h5>\n<div>\n<pre><code>class BodyweightExercise extends Exercise {\n private static final String BODYWEIGHT = \"Bodyweight\";\n\n public BodyweightExercise(String type, String name, int[] repetitionsOrTime, double[] weight) {\n super(type, name, repetitionsOrTime, weight);\n }\n\n @Override\n protected void getSetData(StringBuilder sb) {\n\n for (int i = 0; i <\/code><\/pre>\n<\/div>\n<p>I am certain that some astute readers will find things which could have been <em>abstracted out<\/em> in a more efficient manner, but the purpose of this example (which has been simplified from the original source) is to demonstrate the general approach. Of course, no programming article would be complete without something which can be executed. There are several online Java compilers which you may use to run this code if you want to test it out (unless you already have an IDE):<\/p>\n<pre><code>public class Main {\n public static void main(String[] args) {\n \/\/Note: I actually used another nested class called a \"Set\" instead of an Array\n \/\/to represent each Set of an Exercise.\n int[] reps = {10, 10, 8};\n double[] weight = {70.0, 70.0, 70.0};\n\n Exercise e1 = new BarbellExercise(\n \"Barbell\",\n \"Barbell Bench Press\",\n reps,\n weight\n );\n\n Exercise e2 = new DumbbellExercise(\n \"Dumbbell\",\n \"Dumbbell Bench Press\",\n reps,\n weight\n );\n\n Exercise e3 = new BodyweightExercise(\n \"Bodyweight\",\n \"Push Up\",\n reps,\n weight\n );\n\n System.out.println(\n e1.getFormattedOutput()\n + e2.getFormattedOutput()\n + e3.getFormattedOutput()\n );\n }\n}\n<\/code><\/pre>\n<p>Executing this toy application yields the following output:<br \/>\n<code>Barbell Bench Press<\/code><\/p>\n<pre><code>10 REPS @ 70.0LBS\n10 REPS @ 70.0LBS\n8 REPS @ 70.0LBS\n\nDumbbell Bench Press\n10 REPS @ 70.0LBSx2\n10 REPS @ 70.0LBSx2\n8 REPS @ 70.0LBSx2\n\nPush Up\n10 REPS @ Bodyweight\n10 REPS @ Bodyweight\n8 REPS @ Bodyweight\n<\/code><\/pre>\n<h4>Further Considerations<\/h4>\n<p>Earlier, I mentioned that there are two features of Java <em>interfaces<\/em> (as of Java 8) which are decidedly geared towards sharing <em>implementation<\/em>, as opposed to <em>behavior<\/em>. These features are known as <em>Default Methods<\/em> and <em>Static Methods<\/em>.<\/p>\n<p>I have decided not to go into detail on these features for the reason that they are most typically used in mature and\/or large code bases where a given <em>interface<\/em> has many <em>inheritors.<\/em> Despite the fact that this is meant to be an introductory article, and I still encourage you to take a look at these features eventually, even though I am confident that you will not need to worry about them just yet.<\/p>\n<p>I would also like to mention that there are other ways to share <em>implementation<\/em> across a set of classes (or even <em>static methods<\/em>) in a Java application that does not require <em>inheritance<\/em> or <em>abstraction<\/em> at all. For example, suppose you have some <em>implementation<\/em> which you expect to use in a variety of different classes, but does not necessarily make sense to share via <em>inheritance<\/em>. A common pattern in Java is to write what is known as a <em>Utility<\/em> class, which is a simple <code>class<\/code>containing the requisite <em>implementation<\/em> in a <em>static method<\/em>:<\/p>\n<div>\n<pre><code>public class TimeConverterUtil {\n\n \/**\n * Accepts an hour (0-23) and minute (0-59), then attempts to format them into an appropriate\n * format such as 12, 30 -> 12:30 pm\n *\/ \n public static String convertTime (int hour, int minute){\n String unformattedTime = Integer.toString(hour) + \":\" + Integer.toString(minute);\n DateFormat f1 = new SimpleDateFormat(\"HH:mm\");\n\n Date d = null;\n try { d = f1.parse(unformattedTime); } \n catch (ParseException e) { e.printStackTrace(); }\n DateFormat f2 = new SimpleDateFormat(\"h:mm a\");\n return f2.format(d).toLowerCase();\n }\n}\n<\/code><\/pre>\n<\/div>\n<p>Using this <em>static method<\/em> in an external class (or another <em>static method<\/em>) looks like this:<\/p>\n<pre><code>\npublic class Main {\n public static void main(String[] args){\n \/\/...\n String time = TimeConverterUtil.convertTime(12, 30);\n \/\/...\n }\n}\n<\/code><\/pre>\n<h3>Cheat Sheet<\/h3>\n<p>We have covered a lot of ground in this article, so I would like to spend a moment summarizing the three main mechanisms based on what problems they solve. Since you should possess a sufficient understanding of the terms and ideas I have either introduced or redefined for the purposes of this article, I will keep the summaries brief.<\/p>\n<h5>I Want A Set Of Child Classes To Share Implementation<\/h5>\n<p>Classic <em>inheritance<\/em>, which requires a <em>child class<\/em> to <em>inherit<\/em> from a <em>parent class<\/em>, is a very simple mechanism for sharing <em>implementation<\/em> across a set of classes. An easy way to decide if some <em>implementation<\/em> should be pulled into a <em>parent class<\/em>, is to see whether it is repeated in a number of different classes line for line. The acronym <strong>DRY<\/strong> (<em>Don\u2019t Repeat Yourself<\/em>) is a good mnemonic device to watch out for this situation.<\/p>\n<p>While coupling <em>child classes<\/em> together with a common <em>parent class<\/em> can present some limitations, a side benefit is that they can all be referenced as the <em>parent class<\/em>, which provides a limited degree of <em>abstraction<\/em>.<\/p>\n<h5>I Want A Set Of Classes To Share Behavior<\/h5>\n<p>Sometimes, you want a set of classes to be capable of possessing certain <em>abstract methods<\/em> (referred to as <em>behavior<\/em>), but you do not expect the <em>implementation<\/em> of that <em>behavior<\/em> to be repeated across inheritors.<\/p>\n<p>By definition, Java interfaces may not contain any implementation (except for <em>Default<\/em> and <em>Static Methods<\/em>), but any class which implements an <em>interface<\/em>, must supply an <em>implementation<\/em> for all abstract methods, otherwise, the code will not compile. This provides a healthy measure of flexibility and restriction on what is actually shared and does not require the inheritors to be of the same <em>class hierarchy<\/em>.<\/p>\n<h5>I Want A Set Of Child Classes To Share Behavior And Implementation<\/h5>\n<p>Although I do not find myself using <em>abstract classes<\/em> all over the place, they are perfect for situations when you require a mechanism for sharing both <em>behavior<\/em> and <em>implementation<\/em> across a set of classes. Anything which will be repeated across <em>inheritors<\/em> may be <em>implemented<\/em> directly in the <code>abstract class<\/code>, and anything which requires flexibility may be specified as an <em>abstract method<\/em>.<\/p>\n<div>\n <img data-recalc-dims=\"1\" decoding=\"async\" src=\"https:\/\/i0.wp.com\/www.taterboy.com\/blog\/wp-content\/uploads\/2019\/11\/logo-red-22.png?w=900&ssl=1\" alt=\"Smashing Editorial\"><span>(dm, il)<\/span>\n<\/div>\n<\/article>\n<p class=\"wpematico_credit\"><small>Powered by <a href=\"http:\/\/www.wpematico.com\" target=\"_blank\" rel=\"noopener noreferrer\">WPeMatico<\/a><\/small><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00 So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information….<a class=\"moretag\" href=\"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/\"> Read the full article…<\/a><\/p>\n","protected":false},"author":4,"featured_media":73392,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[371],"tags":[],"class_list":["post-73391","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-user-experience"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Guest Contribution\"\/>\n\t<meta name=\"keywords\" content=\"user experience\" \/>\n\t<link rel=\"canonical\" href=\"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"Design for Immersive Technologies | User Experience for Games, Virtual Reality (VR) and Augmented\/Mixed Reality (AR\/MR)\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies\" \/>\n\t\t<meta property=\"og:description\" content=\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-27T11:17:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-11-27T11:17:47+00:00\" \/>\n\t\t<meta name=\"twitter:card\" content=\"summary\" \/>\n\t\t<meta name=\"twitter:title\" content=\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies\" \/>\n\t\t<meta name=\"twitter:description\" content=\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I\" \/>\n\t\t<script type=\"application\/ld+json\" class=\"aioseo-schema\">\n\t\t\t{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#article\",\"name\":\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies\",\"headline\":\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes\",\"author\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/author\\\/guestcontribution\\\/#author\"},\"publisher\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/#organization\"},\"image\":{\"@type\":\"ImageObject\",\"url\":\"https:\\\/\\\/i0.wp.com\\\/www.taterboy.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/11\\\/logo-red-22.png?fit=60%2C80&ssl=1\",\"width\":60,\"height\":80},\"datePublished\":\"2019-11-27T04:17:47-07:00\",\"dateModified\":\"2019-11-27T04:17:47-07:00\",\"inLanguage\":\"en-US\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#webpage\"},\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#webpage\"},\"articleSection\":\"User Experience\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#breadcrumblist\",\"itemListElement\":[{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog#listItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.taterboy.com\\\/blog\",\"nextItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/category\\\/user-experience\\\/#listItem\",\"name\":\"User Experience\"}},{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/category\\\/user-experience\\\/#listItem\",\"position\":2,\"name\":\"User Experience\",\"item\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/category\\\/user-experience\\\/\",\"nextItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#listItem\",\"name\":\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes\"},\"previousItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog#listItem\",\"name\":\"Home\"}},{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#listItem\",\"position\":3,\"name\":\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes\",\"previousItem\":{\"@type\":\"ListItem\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/category\\\/user-experience\\\/#listItem\",\"name\":\"User Experience\"}}]},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/#organization\",\"name\":\"Design for Immersive Technologies\",\"description\":\"User Experience for Games, Virtual Reality (VR) and Augmented\\\/Mixed Reality (AR\\\/MR)\",\"url\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/author\\\/guestcontribution\\\/#author\",\"url\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/author\\\/guestcontribution\\\/\",\"name\":\"Guest Contribution\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#authorImage\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d2aad73eb0f48c67b141e9fc978a0e498969791ed623346e361d02d19775b0bb?s=96&d=mm&r=g\",\"width\":96,\"height\":96,\"caption\":\"Guest Contribution\"}},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#webpage\",\"url\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/\",\"name\":\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies\",\"description\":\"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I\",\"inLanguage\":\"en-US\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/#website\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#breadcrumblist\"},\"author\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/author\\\/guestcontribution\\\/#author\"},\"creator\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/author\\\/guestcontribution\\\/#author\"},\"image\":{\"@type\":\"ImageObject\",\"url\":\"https:\\\/\\\/i0.wp.com\\\/www.taterboy.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/11\\\/logo-red-22.png?fit=60%2C80&ssl=1\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#mainImage\",\"width\":60,\"height\":80},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/2019\\\/11\\\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\\\/#mainImage\"},\"datePublished\":\"2019-11-27T04:17:47-07:00\",\"dateModified\":\"2019-11-27T04:17:47-07:00\"},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/\",\"name\":\"Design for Immersive Technologies\",\"description\":\"User Experience for Games, Virtual Reality (VR) and Augmented\\\/Mixed Reality (AR\\\/MR)\",\"inLanguage\":\"en-US\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.taterboy.com\\\/blog\\\/#organization\"}}]}\n\t\t<\/script>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies","description":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I","canonical_url":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/","robots":"max-image-preview:large","keywords":"user experience","webmasterTools":{"miscellaneous":""},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#article","name":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies","headline":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes","author":{"@id":"https:\/\/www.taterboy.com\/blog\/author\/guestcontribution\/#author"},"publisher":{"@id":"https:\/\/www.taterboy.com\/blog\/#organization"},"image":{"@type":"ImageObject","url":"https:\/\/i0.wp.com\/www.taterboy.com\/blog\/wp-content\/uploads\/2019\/11\/logo-red-22.png?fit=60%2C80&ssl=1","width":60,"height":80},"datePublished":"2019-11-27T04:17:47-07:00","dateModified":"2019-11-27T04:17:47-07:00","inLanguage":"en-US","mainEntityOfPage":{"@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#webpage"},"isPartOf":{"@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#webpage"},"articleSection":"User Experience"},{"@type":"BreadcrumbList","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#breadcrumblist","itemListElement":[{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog#listItem","position":1,"name":"Home","item":"https:\/\/www.taterboy.com\/blog","nextItem":{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog\/category\/user-experience\/#listItem","name":"User Experience"}},{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog\/category\/user-experience\/#listItem","position":2,"name":"User Experience","item":"https:\/\/www.taterboy.com\/blog\/category\/user-experience\/","nextItem":{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#listItem","name":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes"},"previousItem":{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog#listItem","name":"Home"}},{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#listItem","position":3,"name":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes","previousItem":{"@type":"ListItem","@id":"https:\/\/www.taterboy.com\/blog\/category\/user-experience\/#listItem","name":"User Experience"}}]},{"@type":"Organization","@id":"https:\/\/www.taterboy.com\/blog\/#organization","name":"Design for Immersive Technologies","description":"User Experience for Games, Virtual Reality (VR) and Augmented\/Mixed Reality (AR\/MR)","url":"https:\/\/www.taterboy.com\/blog\/"},{"@type":"Person","@id":"https:\/\/www.taterboy.com\/blog\/author\/guestcontribution\/#author","url":"https:\/\/www.taterboy.com\/blog\/author\/guestcontribution\/","name":"Guest Contribution","image":{"@type":"ImageObject","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#authorImage","url":"https:\/\/secure.gravatar.com\/avatar\/d2aad73eb0f48c67b141e9fc978a0e498969791ed623346e361d02d19775b0bb?s=96&d=mm&r=g","width":96,"height":96,"caption":"Guest Contribution"}},{"@type":"WebPage","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#webpage","url":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/","name":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies","description":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I","inLanguage":"en-US","isPartOf":{"@id":"https:\/\/www.taterboy.com\/blog\/#website"},"breadcrumb":{"@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#breadcrumblist"},"author":{"@id":"https:\/\/www.taterboy.com\/blog\/author\/guestcontribution\/#author"},"creator":{"@id":"https:\/\/www.taterboy.com\/blog\/author\/guestcontribution\/#author"},"image":{"@type":"ImageObject","url":"https:\/\/i0.wp.com\/www.taterboy.com\/blog\/wp-content\/uploads\/2019\/11\/logo-red-22.png?fit=60%2C80&ssl=1","@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#mainImage","width":60,"height":80},"primaryImageOfPage":{"@id":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/#mainImage"},"datePublished":"2019-11-27T04:17:47-07:00","dateModified":"2019-11-27T04:17:47-07:00"},{"@type":"WebSite","@id":"https:\/\/www.taterboy.com\/blog\/#website","url":"https:\/\/www.taterboy.com\/blog\/","name":"Design for Immersive Technologies","description":"User Experience for Games, Virtual Reality (VR) and Augmented\/Mixed Reality (AR\/MR)","inLanguage":"en-US","publisher":{"@id":"https:\/\/www.taterboy.com\/blog\/#organization"}}]},"og:locale":"en_US","og:site_name":"Design for Immersive Technologies | User Experience for Games, Virtual Reality (VR) and Augmented\/Mixed Reality (AR\/MR)","og:type":"article","og:title":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies","og:description":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I","og:url":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/","article:published_time":"2019-11-27T11:17:47+00:00","article:modified_time":"2019-11-27T11:17:47+00:00","twitter:card":"summary","twitter:title":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes | Design for Immersive Technologies","twitter:description":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract ClassesMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes Ryan Kay 2019-11-27T11:00:00+00:002019-11-27T11:07:08+00:00So far as I can tell, it is uncommon to come across educational content in the field of software development which provides an appropriate mixture of theoretical and practical information. If I"},"aioseo_meta_data":{"post_id":"73391","title":null,"description":null,"keywords":null,"keyphrases":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_custom_url":null,"og_image_custom_fields":null,"og_custom_image_width":null,"og_custom_image_height":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"location":null,"local_seo":null,"created":"2021-02-07 16:37:31","updated":"2026-09-02 14:04:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null,"primary_term":null,"og_image_url":null,"og_image_width":null,"og_image_height":null,"twitter_image_url":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"Article","isEnabled":true},"graphs":[]},"limit_modified_date":false,"ai":null,"breadcrumb_settings":null,"seo_analyzer_scan_date":null},"aioseo_breadcrumb":"<div class=\"aioseo-breadcrumbs\"><span class=\"aioseo-breadcrumb\">\n\t\t\t<a href=\"https:\/\/www.taterboy.com\/blog\" title=\"Home\">Home<\/a>\n\t\t<\/span><span class=\"aioseo-breadcrumb-separator\">»<\/span><span class=\"aioseo-breadcrumb\">\n\t\t\t<a href=\"https:\/\/www.taterboy.com\/blog\/category\/user-experience\/\" title=\"User Experience\">User Experience<\/a>\n\t\t<\/span><span class=\"aioseo-breadcrumb-separator\">»<\/span><span class=\"aioseo-breadcrumb\">\n\t\t\tMastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes\n\t\t<\/span><\/div>","aioseo_breadcrumb_json":[{"label":"Home","link":"https:\/\/www.taterboy.com\/blog"},{"label":"User Experience","link":"https:\/\/www.taterboy.com\/blog\/category\/user-experience\/"},{"label":"Mastering OOP: A Practical Guide To Inheritance, Interfaces, And Abstract Classes","link":"https:\/\/www.taterboy.com\/blog\/2019\/11\/mastering-oop-a-practical-guide-to-inheritance-interfaces-and-abstract-classes\/"}],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p8wzr5-j5J","jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.taterboy.com\/blog\/wp-content\/uploads\/2019\/11\/logo-red-22.png?fit=60%2C80&ssl=1","_links":{"self":[{"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/posts\/73391","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/comments?post=73391"}],"version-history":[{"count":0,"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/posts\/73391\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/media\/73392"}],"wp:attachment":[{"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/media?parent=73391"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/categories?post=73391"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.taterboy.com\/blog\/wp-json\/wp\/v2\/tags?post=73391"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}