spring annotation inheritance

@Autowired/@Inject (method)

When you use @Inherited on a class annotation, this means that when that annotation is queried on a non-annotated subclass, the Java will look for it in the superclass.

When you use @Inherited on a method annotation, this means that when that annotation is queried on a non-annotated method overridden in subclass, Java will look for it in the superclass.

If your setter method is annotated with @Autowired on the superclass, but the setter method is not overridden in subclass (which is usually the case), the annotation does not need to be @Inherited to be found when you look for annotated methods into the subclass.

Spring looks for all annotated setter methods in the class hierarchy. If a setter is annotated with @Autowired in the superclass and is overridden in the subclass without the @Autowired annotation, then Spring will not detect it and will not inject the dependency.

class A {
  @Autowired setFirst(First f) {}
  @Autowired setSecond(Second s) {}

class B extends A {
  @Overrides setFirst(First f) {}

In a bean definition declared as A, both setFirst() and setSecond() will be invoked, while in a bean definition declared as B, only setSecond() will be invoked, because setFirst() is overridden without @Autowired.
This behaviour is not spring-related, but java-related.


the @Transactionalannotation has @Inherited.

From the docs:

Indicates that an annotation type is automatically inherited. If an Inherited meta-annotation is present on an annotation type declaration, and the user queries the annotation type on a class declaration, and the class declaration has no annotation for this type, then the class’s superclass will automatically be queried for the annotation type. This process will be repeated until an annotation for this type is found, or the top of the class hierarchy (Object) is reached. If no superclass has an annotation for this type, then the query will indicate that the class in question has no such annotation.

Note that this meta-annotation type has no effect if the annotated type is used to annotate anything other than a class. Note also that this meta-annotation only causes annotations to be inherited from superclasses; annotations on implemented interfaces have no effect.

Docs of @Transactional:

public @interface Transactional

angularjs scope inheritence primitive object

JavaScript Prototypal Inheritance

It is important to first have a solid understanding of JavaScript prototypal inheritance, especially if you are coming from a server-side background and you are more familiar with classical inheritance. So let’s review that first.

Suppose parentScope has properties aString, aNumber, anArray, anObject, and aFunction. If childScope prototypically inherits from parentScope, we have:

normal prototypal inheritance

(Note that to save space, I show the anArray object as a single blue object with its three values, rather than an single blue object with three separate gray literals.)

If we try to access a property defined on the parentScope from the child scope, JavaScript will first look in the child scope, not find the property, then look in the inherited scope, and find the property. (If it didn’t find the property in the parentScope, it would continue up the prototype chain… all the way up to the root scope). So, these are all true:

childScope.aString === 'parent string'
childScope.anArray[1] === 20
childScope.anObject.property1 === 'parent prop1'
childScope.aFunction() === 'parent output'

Suppose we then do this:

childScope.aString = 'child string'

The prototype chain is not consulted, and a new aString property is added to the childScope. This new property hides/shadows the parentScope property with the same name. This will become very important when we discuss ng-repeat and ng-include below.


Suppose we then do this:

childScope.anArray[1] = '22'
childScope.anObject.property1 = 'child prop1'

The prototype chain is consulted because the objects (anArray and anObject) are not found in the childScope. The objects are found in the parentScope, and the property values are updated on the original objects. No new properties are added to the childScope; no new objects are created. (Note that in JavaScript arrays and functions are also objects.)

follow the chain

Suppose we then do this:

childScope.anArray = [100, 555]
childScope.anObject = { name: 'Mark', country: 'USA' }

The prototype chain is not consulted, and child scope gets two new object properties that hide/shadow the parentScope object properties with the same names.

not following the chain


  • If we read childScope.propertyX, and childScope has propertyX, then the prototype chain is not consulted.
  • If we set childScope.propertyX, the prototype chain is not consulted.

One last scenario:

delete childScope.anArray
childScope.anArray[1] === 22  // true

We deleted the childScope property first, then when we try to access the property again, the prototype chain is consulted.

after deleting a property

Here is a jsfiddle where you can see the above javascript prototypical inheritance examples being modified and their result (open up your browser’s console to see the output. The console output can be viewed as what the ‘RootScope’ would see).

Angular Scope Inheritance

The contenders:

  • The following create new scopes, and inherit prototypically: ng-repeat, ng-include, ng-switch, ng-view, ng-controller, directive with scope: true, directive with transclude: true.
  • The following creates a new scope which does not inherit prototypically: directive withscope: { ... }. This creates an “isolate” scope instead.

Note, by default, directives do not create new scope — i.e., the default is scope: false.


Suppose we have in our controller:

$scope.myPrimitive = 50;
$scope.myObject    = {aNumber: 11};

And in our HTML:

<script type="text/ng-template" id="/tpl1.html">
    <input ng-model="myPrimitive">
<div ng-include src="'/tpl1.html'"></div>

<script type="text/ng-template" id="/tpl2.html">
    <input ng-model="myObject.aNumber">
<div ng-include src="'/tpl2.html'"></div>

Each ng-include generates a new child scope, which prototypically inherits from the parent scope.


Typing (say, “77”) into the first input textbox causes the child scope to get a new myPrimitive scope property that hides/shadows the parent scope property of the same name. This is probably not what you want/expect.

ng-include primitive

Typing (say, “99”) into the second input textbox does not result in a new child property. Because tpl2.html binds the model to an object property, prototypal inheritance kicks in when the ngModel looks for object myObject — it finds it in the parent scope.

ng-include object

We can rewrite the first template to use $parent, if we don’t want to change our model from a primitive to an object:

<input ng-model="$parent.myPrimitive">

Typing (say, “22”) into this input textbox does not result in a new child property. The model is now bound to a property of the parent scope (because $parent is a child scope property that references the parent scope).

ng-include $parent

For all scopes (prototypal or not), Angular always tracks a parent-child relationship (i.e., a hierarchy), via scope properties $parent, $$childHead and $$childTail. I normally don’t show these scope properties in the diagrams.

For scenarios where form elements are not involved, another solution is to define a function on the parent scope to modify the primitive. Then ensure the child always calls this function, which will be available to the child scope due to prototypal inheritance. E.g.,

// in the parent scope
$scope.setMyPrimitive = function(value) {
    $scope.myPrimitive = value;

Here is a sample fiddle that uses this “parent function” approach. (This was part of a Stack Overflow post.)

See also http://stackoverflow.com/a/13782671/215945 and


ng-switch scope inheritance works just like ng-include. So if you need 2-way data binding to a primitive in the parent scope, use $parent, or change the model to be an object and then bind to a property of that object. This will avoid child scope hiding/shadowing of parent scope properties.

See also AngularJS, bind scope of a switch-case?


Ng-repeat works a little differently. Suppose we have in our controller:

$scope.myArrayOfPrimitives = [ 11, 22 ];
$scope.myArrayOfObjects    = [{num: 101}, {num: 202}]

And in our HTML:

<ul><li ng-repeat="num in myArrayOfPrimitives">
       <input ng-model="num"></input>
<ul><li ng-repeat="obj in myArrayOfObjects">
       <input ng-model="obj.num"></input>

For each item/iteration, ng-repeat creates a new scope, which prototypically inherits from the parent scope, but it also assigns the item’s value to a new property on the new child scope. (The name of the new property is the loop variable’s name.) Here’s what the Angular source code for ng-repeat actually is:

childScope = scope.$new(); // child scope prototypically inherits from parent scope ...     
childScope[valueIdent] = value; // creates a new childScope property

If item is a primitive (as in myArrayOfPrimitives), essentially a copy of the value is assigned to the new child scope property. Changing the child scope property’s value (i.e., using ng-model, hence child scope property num) does not change the array the parent scope references. So in the first ng-repeat above, each child scope gets a num property that is independent of the myArrayOfPrimitives array:

ng-repeat primitive

This ng-repeat will not work (like you want/expect it to). In Angular 1.0.2 or earlier, typing into the textboxes changes the values in the gray boxes, which are only visible in the child scopes. In Angular 1.0.3+, typing into the text boxes has no effect. (See Artem’s explanation as to why on StackOverflow.) What we want is for the inputs to affect the myArrayOfPrimitives array, not a child scope primitive property. To accomplish this, we need to change the model to be an array of objects.

So, if item is an object, a reference to the original object (not a copy) is assigned to the new child scope property. Changing the child scope property’s value (i.e., using ng-model, hence obj.num) does change the object the parent scope references. So in the second ng-repeat above, we have:

ng-repeat object

(I colored one line gray just so that it is clear where it is going.)

This works as expected. Typing into the textboxes changes the values in the gray boxes, which are visible to both the child and parent scopes.

See also Difficulty with ng-model, ng-repeat, and inputs and
ng-repeat and databinding


TBD, but I think it acts just like ng-include.


Nesting controllers using ng-controller results in normal prototypal inheritance, just like ng-include and ng-switch, so the same techniques apply. However, “it is considered bad form for two controllers to share information via $scope inheritance” —http://onehungrymind.com/angularjs-sticky-notes-pt-1-architecture/ A service should be used to share data between controllers instead.

(If you really want to share data via controllers scope inheritance, there is nothing you need to do. The child scope will have access to all of the parent scope properties. See also Controller load order differs when loading or navigating)


  1. default (scope: false) – the directive does not create a new scope, so there is no inheritance here. This is easy, but also dangerous because, e.g., a directive might think it is creating a new property on the scope, when in fact it is clobbering an existing property. This is not a good choice for writing directives that are intended as reusable components.
  2. scope: true – the directive creates a new child scope that prototypically inherits from the parent scope. If more than one directive (on the same DOM element) requests a new scope, only one new child scope is created. Since we have “normal” prototypal inheritance, this is like ng-include and ng-switch, so be wary of 2-way data binding to parent scope primitives, and child scope hiding/shadowing of parent scope properties.
  3. scope: { ... } – the directive creates a new isolate/isolated scope. It does not prototypically inherit. This is usually your best choice when creating reusable components, since the directive cannot accidentally read or modify the parent scope. However, such directives often need access to a few parent scope properties. The object hash is used to set up two-way binding (using ‘=’) or one-way binding (using ‘@’) between the parent scope and the isolate scope. There is also ‘&’ to bind to parent scope expressions. So, these all create local scope properties that are derived from the parent scope. Note that attributes are used to help set up the binding — you can’t just reference parent scope property names in the object hash, you have to use an attribute. E.g., this won’t work if you want to bind to parent property parentProp in the isolated scope: <div my-directive> and scope: { localProp: '@parentProp' }. An attribute must be used to specify each parent property that the directive wants to bind to: <div my-directive the-Parent-Prop=parentProp> and scope: { localProp: '@theParentProp' }.
    Isolate scope’s __proto__ references a Scope object. Isolate scope’s $parent references the parent scope, so although it is isolated and doesn’t inherit prototypically from the parent scope, it is still a child scope.
    For the picture below we have
    <my-directive interpolated="{{parentProp1}}" twowayBinding="parentProp2"> and
    scope: { interpolatedProp: '@interpolated', twowayBindingProp: '=twowayBinding' }
    Also, assume the directive does this in its linking function: scope.someIsolateProp = "I'm isolated"
    isolate scope
    One final note: use attrs.$observe('attr_name', function(value) { ... }) in the linking function to get the interpolated value of isolate scope properties that use the ‘@’ notation. E.g., if we have this in the linking function —attrs.$observe('interpolated', function(value) { ... })value would be set to 11. (scope.interpolatedProp is undefined in the linking function. In contrast,scope.twowayBindingProp is defined in the linking function, since it uses the ‘=’ notation.)
    For more information on isolate scopes see http://onehungrymind.com/angularjs-sticky-notes-pt-2-isolated-scope/
  4. transclude: true – the directive creates a new “transcluded” child scope, which prototypically inherits from the parent scope. So if your transcluded content (i.e., the stuff that ng-transclude will be replaced with) requires 2-way data binding to a primitive in the parent scope, use $parent, or change the model to be an object and then bind to a property of that object. This will avoid child scope hiding/shadowing of parent scope properties.
    The transcluded and the isolated scope (if any) are siblings — the $parent property of each scope references the same parent scope. When a transcluded and an isolate scope both exist, isolate scope property $$nextSibling will reference the transcluded scope.
    For more information on transcluded scopes, see AngularJS two way binding not working in directive with transcluded scope
    For the picture below, assume the same directive as above with this addition:transclude: true
    transcluded scope

This fiddle has a showScope() function that can be used to examine an isolate scope and its associated transcluded scope. See the instructions in the comments in the fiddle.


There are four types of scopes:

  1. normal prototypal scope inheritance — ng-include, ng-switch, ng-controller, directive with scope: true
  2. normal prototypal scope inheritance with a copy/assignment — ng-repeat. Each iteration of ng-repeat creates a new child scope, and that new child scope always gets a new property.
  3. isolate scope — directive with scope: {...}. This one is not prototypal, but ‘=’, ‘@’, and ‘&’ provide a mechanism to access parent scope properties, via attributes.
  4. transcluded scope — directive with transclude: true. This one is also normal prototypal scope inheritance, but it is also a sibling of any isolate scope.

For all scopes (prototypal or not), Angular always tracks a parent-child relationship (i.e., a hierarchy), via properties $parent and $$childHead and $$childTail.

Diagrams were generated with GraphViz “*.dot” files, which are on github. Tim Caswell’s“Learning JavaScript with Object Graphs” was the inspiration for using GraphViz for the diagrams.

The above was originally posted on StackOverflow.

prototype vs __proto__ in js

short version

__proto__ is the actual object that is used in the lookup chain to resolve methods, etc. prototypeis the object that is used to build __proto__ when you create an object with new


long version

prototype is a property of a Function object. It is the prototype of objects constructed by that function.

__proto__ is internal property of an object, pointing to its prototype. Current standards provide an equivalent Object.getPrototypeOf(O) method, though de facto standard __proto__ is quicker.


longer version

prototype is used by constructor() functions. It should’ve really been called something like, "prototypeToInstall", since that’s what it is.

and __proto__ is that “installed prototype” on an object (that was created/installed upon the object from said constructor() function)


longest version (from here)

Prerequisite: Understanding JavaScript Objects

Before diving into this post on prototypes, it will be helpful if you have a basic understanding of what objects are in JavaScript, how they work, and how to create them. If you aren’t familiar with these concepts, I highly recommend you read my post on Understanding JavaScript Objects.

In Understanding JavaScript Objects, I used the following examples of creating objects:

Example A

var catA = {name: "Fluffy", color: "White", age: 0};

Example B

var catB = Object.create(new Object());
catB.name = "Fluffy";
catB.color = "White";
catB.age = 0;

Example C

function Cat(name, color) {
  this.name = name;
  this.color = color;
Cat.prototype.age = 0;

var catC = new Cat("Fluffy", "White");

In these examples, A and B produce identical results while example C produces a something different. Example B is not very commonly used since Example A is much less verbose and equally useful. While example A is very common and quite useful, it doesn’t apply much to this blog post so I will be almost solely working with example C, which uses function Cat, for the remainder of this post.

Why is Cat a function instead of a class?

We know from Understanding JavaScript Objects that Cat is a constructor function. A constructor function really is no different than any other function, in fact the term “constructor function” is just a common nomenclature that suggests that the function will create properties on the object being created (represented by this). In other words, when we say var catC = new Cat("Fluffy", "White"), all that really is happening is the catC object is created and assigned to this for the duration of the call to the Cat function. Therefore, inside the function, this.name = name; is the same as sayingcatC.name = name. Hopefully, that helps to clarify that constructor functions are not doing anything magic, they are just normal functions that are creating properties on this — even though we use them in a way that is similar to how classes work in other languages. In fact, using the new keyword, you can create an object out of any function (it just doesn’t make sense with other functions).

Cat.prototype.age? What’s that all about?

Ok, first of all, notice that Cat.prototype.age isn’t really part of the Cat function. It’s also helpful to realize when this code gets executed. Seeing the code all lumped together like that might fool you into thinking thatCat.prototype.age = 0; is being called when a new cat is created, which of course, on closer inspection is obviously not true. Usually this code (including the creation of the Cat function above it) is called when a web page is first loaded; thus making the Cat function available to be called. So think about what is happening there. The Cat function is being created and then the age property is being created (with a value of 0) on the Cat function’s prototype.

Wait, functions have a prototype? What’s a prototype?

Functions can be used to create class-like functionality in JavaScript; and all functions have a prototype property. That prototype property is somewhat like a class definition in other object-oriented langauge; but it is more than that. It is actually an instance of an object and every function in JavaScript has one whether you use it or not. Every function (constructor function or not) has a prototype object instance hanging off of it, interesting, huh?

So, let’s talk about how this prototype object is actually used. When you create an object using the new keyword, it creates a new object, passes it in as this to the constructor function (letting that function do to it whatever it wants) and then, and this is the important part, it takes the object instance that is pointed to by that function’s prototype property and assigns it as the prototype for that object.

So objects have a prototype property too?

Well, yes but you don’t access it the same way and it isn’t used for the same purpose as a function’s prototype. And this is where a lot of confusion usually begins with prototypes (don’t worry if your confusion began long before this, that’s normal too). Objects do not have a prototype property, but they do have a prototype. Only, the word prototype means something different when talking about objects than it does when talking about functions. It would be nice if we had a different word, for now, let’s call it proto (you’ll understand why in a minute). So functions have prototypes and objects have protos. They are very similar, in fact, a function’s prototype and an object’s proto often (in fact, usually) point to the same object in memory.

An object’s proto is the object from which it is inheriting properties. Notice I said it is the object from which it is inheriting properties, not the function orclass, it really is an object instance in memory. This differs from a function’s prototype which is used as the object to be assigned as the proto for new objects’ created using this function as a constructor function. An object’s proto can be retrieved by calling myObject.__proto__ in most browsers (thanks IE) and by calling Object.getPrototypeOf(myObject) in all browsers — I’ll use __proto__ going forward for simplicity.

So let’s give an actual definition to each of these terms:

  • A function’s prototype: A function’s prototype is the object instance that will become the prototype for all objects created using this function as a constructor.
  • An object’s prototype: An object prototype is the object instance from which the object is inherited.

Back to the examples

All that explanation can be confusing without showing some examples, so let’s dive in. If you inspect the prototype of the cats in Examples A and B you get the following result:

Object { }

But, if you inspect the cat in Example C you get this result:

Cat {age: 0}

Side note: I am using chrome’s developer console to execute these statements and I will be displaying the results shown by chrome in grey textas shown above.

Note that in examples A and B, they do have a prototype (__proto__) even though they were not created using a constructor function. Since we didn’t specify a prototype for these, they have a prototype of Object. It is possible to create objects without a prototype using this syntax: var myObject = Object.create(null);, but that is very rare and I’ve never seen a use for it. So barring that example, I think it is safe to say that all objects eventually inherit from Object.

This is even true of catC; look what happens when we inspect catC further:

Cat {age: 0}

Object { }


Notice that catC has a prototype (__proto__) of Cat. Actually, to say it that way is not really accurate. Cat is a function, so it cannot be a prototype; remember in the definitions above that a prototype is not a function it is anobject instance. This is important to remember when thinking about prototypes — an object’s prototype is not the function that created it but an instance of an object. Since this is important, let’s explore it a bit further:

function Cat(name, color) {
  this.name = name;
  this.color = color;

Cat {age: 0}

Cat {name: "Fluffy", color: "White", age: 0}

Look at the difference between Cat, Cat.prototype and catC. What this is showing is that Cat is a function but Cat.prototype and catC are objects. It further shows that Cat.prototype has an age property (set to 0) and catC has three properties — including age…sort of (stay tuned). When you define a function, it creates more than just the function, it also creates a new objectwith that function as it’s type and assigns that new object to the function’s prototype property. When we first created the Cat function, before we executed the line Cat.prototype.age = 0;, if we would have inspected Cat’s prototype it would have looked like this: Cat {}, an object with no properties, but of type Cat. It was only after we called Cat.prototype.age = 0; that it looked like this: Cat {age: 0}.

Inherited properties vs. native properties

In the above paragraph, I stated that catC had “three properties — including age…sort of (stay tuned)”…thanks for sticking with me. Age really isn’t a direct property of catC. You can see this by executing these statements:




This is because age, actually belongs to catC’s prototype; and yet, if I execute the statement catC.age;, it does indeed return 0. What is actually happening here, is when we ask for catC.age, it checks to see if catC has a property named age, and if it does it returns it, if not, it asks catC’s prototype if it has an age property. It continues doing this all the way up the prototype chain until it finds the matching property or finds an object with a null prototype and if it doesn’t find the property in the prototype chain it will return undefined.

So that’s what prototype chaining is?

Yep. You may have heard of prototype chaining before. It is really quite simple to understand now that you (hopefully) understand a little more about how prototypes work. A prototype chain is basically a linked-list of objects pointing backwards to the object from which each one inherits.

Changing an function’s prototype

Remember that a function’s prototype is just an object, so what would happen if we started changing the properties of a function’s prototype after we created objects from it? Consider the following examples:

function Cat(name, color) {
  this.name = name;
  this.color = color;
Cat.prototype.age = 3;

var fluffy = new Cat("Fluffy", "White");
var scratchy = new Cat("Scratchy", "Black");



Cat.prototype.age = 4;



So, notice that changing the age of the Cat function’s prototype property also changed the age of the cats that had inherited from it. This is because when the Cat function was created so was it’s prototype object; and every object that inherited from it inherited this instance of the prototype object as their prototype. Consider the following example:

function Cat(name, color) {
  this.name = name;
  this.color = color;
Cat.prototype.age = 3;

var fluffy = new Cat("Fluffy", "White");
var scratchy = new Cat("Scratchy", "Black");



Cat.prototype = {age: 4};



var muffin = new Cat("Muffin", "Brown");


First, notice that I did not just change the value of the prototype.age property to 4, I actually changed the Cat function’s prototype to point to a new object. So while Muffin inherited the new prototype object, Fluffy’s and Scratchy’s prototypes are still pointing to their original prototype object, which they originally inherited from the Cat function. This illustrates the point that a function’s prototype property “is the object instance which will become the prototype (or __proto__) for objects created using this function as a constructor.”

One more example to illustrate this point. What would happen if I changed the value of the age property of fluffy’s prototype? Would this be different than simply changing fluffy’s age? Yes, it would be different. Think about the examples above, and about how age is not actually a property on fluffy, it is a property of fluffy’s prototype.

So, given this setup:

function Cat(name, color) {
  this.name = name;
  this.color = color;
Cat.prototype.age = 3;

var fluffy = new Cat("Fluffy", "White");
var scratchy = new Cat("Scratchy", "Black");

Compare this example:

fluffy.age = 4;



To this example:

fluffy.__proto__.age = 4;



These produce different results because in the first example, we are just adding a new age property to the fluffy. So in the first example both fluffy and fluffy.__proto__ have age properties with the vales 4 and 3, respectively. When you ask for fluffy.age, it finds the property on the fluffy object so returns it immediately without ever looking up the prototype chain.

Whereas in the second example, fluffy still does not have an age property, but it’s prototype (which is the same instance in memory as scratchy’s prototype) now has a the new value 4 thus affecting both fluffy’s and scratchy’s ages.

Multiple Levels of Inheritance

I have to confess, this is not something I use often because I tend to prefer composition over inheritance; but that is not to say it is without a place. Say you want to create a constructor function that “inherits” from another constructor function, much like you would do in other languages when you create one class that inherits from another. Let’s look at an example of how you may do this:

function Animal(name) {
  this.name = name;

function Cat(name, color) {
  Animal.call(this, name);
  this.color = color;
Cat.prototype = new Animal(null);

var catC = new Cat("Fluffy", "White");







Notice that age is the only property that is not a direct property of catC. This is because when we called the Cat constructor function, it passed in our new object (catC/this) to the Animal function which created the name property on the object. The Cat function then also added the color property to catC/this. But the age property was added to the Animal function’s prototype, it was never added directly to catC.

Inheriting Functions

In all the examples above, I used properties like name, color, and age to illustrate objects and inheritance. However, everything that I have done above with properties can be done with functions. If we were to create a speak() function on the Cat Function like this: Cat.prototype.speak = function() { alert('meow'); };, that function would be inherited by all objects that have Cat as their prototype, just like with the name, color and age properties.





java OOP basic vocabularies

What is a Class?

Class is a template for a set of objects that share a common structure and a common behavior.

What is an Object?

Object is an instance of a class. It has state,behaviour and identity. It is also called as an instance of a class.

What are the core OOP’s concepts?

Abstraction, Encapsulation,Inheritance and Polymorphism are the core OOP’s concepts.

What is meant by abstraction?

Abstraction defines the essential characteristics of an object that distinguish it from all other kinds of objects. Abstraction provides crisply-defined conceptual boundaries relative to the perspective of the viewer. Its the process of focussing on the essential characteristics of an object. Abstraction is one of the fundamental elements of the object model.

What is meant by Encapsulation?

Encapsulation is the process of compartmentalising the elements of an abtraction that defines the structure and behaviour. Encapsulation helps to separate the contractual interface of an abstraction and implementation.

What is meant by Inheritance?

Inheritance is a relationship among classes, wherein one class shares the structure or behaviour defined in another class. This is called Single Inheritance. If a class shares the structure or behaviour from multiple classes, then it is called Multiple Inheritance. Inheritance defines “is-a” hierarchy among classes in which one subclass inherits from one or more generalised superclasses.

What is meant by Polymorphism?

Polymorphism literally means taking more than one form. Polymorphism is a characteristic of being able to assign a different behavior or value in a subclass, to something that was declared in a parent class.

What is an Abstract Class?

Abstract class is a class that has no instances. An abstract class is written with the expectation that its concrete subclasses will add to its structure and behaviour, typically by implementing its abstract operations.

What is an Interface?

Interface is an outside view of a class or object which emphaizes its abstraction while hiding its structure and secrets of its behaviour.

What is meant by Binding?

Binding denotes association of a name with a class.

What is meant by static binding?

Static binding is a binding in which the class association is made during compile time. This is also called as Early binding.

What is meant by Dynamic binding?

Dynamic binding is a binding in which the class association is not made until the object is created at execution time. It is also called as Late binding.