Develop Reference

Inheritance vs Composition: Does composition effectively solve dependency issues? [Effective Java]

I'm semi-familiar with Java and came across something in Effective Java(2017) that didn't make much sense to me.
Below is a piece from the book. (item 18)
Unlike method invocation, inheritance violates encapsulation. In other words, a subclass depends on the implementation details of its superclass for its proper function. The superclass's implementation may change from release to release, and if it does, the subclass may break, even though its code has not been touched. As a consequence, a subclass must evolve in tandem with its superclass, unless the superclass's authors have designed and documented it specifically for the purpose of being extended.
I understand composition may be favored over inheritance in some cases and understood other parts of item 18. However, I find it hard to understand how the composition method prevents the problem mentioned in the paragraph above(dependency on implementation details) - as the author speaks as though composition is better than inheritance because of this. Later in the chapter, Bloch gives an example of a custom Set implementation where he uses a Forwarding Class(which is obviously dependent on the Set interface details). One could argue the Set interface doesn't change as often but in practice changes in the interface may as well cause the Wrapper Class to break(note the book gives an example via Forwarding Class and Wrapper Class).
I guess it makes sense if Bloch meant composition is relatively safer than inheritance because class implementations change more often than interfaces. However, I think there is still a dependency issue between Wrapper Class and Interface, and am confused on why the author didn't mention this more clearly.
Am I mistaken in thinking like this?
(In addition, I'm not sure what encapsulation has to do with this. My understanding of encapsulation is hiding variables using private..)

You should actually provide more on the examples i.e. "Later in the chapter, Bloch gives an example of a custom Set implementation"
Basically the inheritance is that the child class will be affected by the change of parent class. See code below:
public class Baby extends Human{
}
In the code above, if Human implement another public or protected method, Baby will be forced to automatically inherit it. It is quite stringent.
But for composition, a change in the Owner object does not really require a change in the child object, and vice versa up to a certain degree.
public class Human{
private Baby baby;
}
In the code above, Human can have any implementation that may not impact Baby and vice versa. There is more leeway for designing what Baby and Human can do. They can be entirely having lots of different properties and methods.

Ok so I looked up what #LeiYang recommended and came to realize the my question wasn't valid. The given paragraph states "a subclass depends on the implementation details of its superclass for its proper function" - which Object Composition would have no problem with, as it merely makes use of provided methods as is(without overriding). Therefore Object Composition doesn't violate encapsulation and is relatively stable compared to Inheritance.

Polymorphism vs Strategy pattern

What is the difference between the Strategy pattern and Polymorphism in Java?
I'm confused that whatever is achieved via Strategy Pattern is basically possible by polymorphism. Correct me if I'm wrong in this regard.
Please, also provide me example to eradicate my confusion.

For me, the link from CKing post and the example in Wikipedia are clear enough, but I'll try to give you a new example. As they said, Strategy Pattern is mostly a way to change the behaviour of an algorithm at runtime. Of course you can achieve this in many different ways (such as holding a value and using switch-case, but it wouldn't be as nice as Strategy Pattern).
Let's say you're developing a turn-based strategy game with two kind of Units: Infantry and Tank (subclasses of Unit). Your terrain could be Plains, Railroad or Forests.
class Unit{
MovementStrategy ms;
final int baseMovement;
int x,y;
public Unit(int baseMovement){
this.baseMovement = baseMovement;
}
abstract void fire();
void moveForward(){
x = x + ms.getHexagonsToMove(baseMovement);
}
void setMovementStrategy(MovementStrategy ms){
this.ms = ms;
}
}
Any Unit subclass must implement fire() method because it's going to be completely different for them (Tank shots heavy long-distance round and Infantry shot several short distance light bullets). In this example we use normal polymorphism/inheritance since fire() method will be really different for any unit, and it won't change during the game.
class Infantry extends Unit{
public Infantry(){
super(2);
}
void fire(){
//whatever
}
}
class Tank extends Unit{
public Tank(){
super(5);
}
void fire(){
//whatever
}
}
Units also are able to move, and have a field baseMovement that holds the number of hexagons it can walk. We're developing a strategy game, not a real world simulation, so we don't care how they move, we just want to add a value to their coordinates (in my example I only use X coordinate in order to get a simpler code). If all the terrain was the same, we wouldn't need any Strategy object... but we need to change the behaviour of move() method at runtime!
So, we implement a different MovementStrategy class for each of our kinds of Terrain, and we program our game to trigger a setMovementStrategy() to any unit that move on each hexagon. And we don't even need to write anything else in our Unit subclasses.
interface MovementStrategy{
public int getHexagonsToMove(int base);
}
class PlainMovementStrategy implements MovementStrategy{
public int getHexagonsToMove(int base){
return base;
}
}
class RailroadMovementStrategy implements MovementStrategy{
public int getHexagonsToMove(int base){
return base*3;
}
}
class ForestMovementStrategy implements MovementStrategy{
public int getHexagonsToMove(int base){
return (int)(base/2);
}
}
Now, when any Unit move inside a Forest, we call
unit.setMovementStrategy(new ForestMovementStrategy());
And as soon it goes to a Plain, we do:
unit.setMovementStrategy(new PlainMovementStrategy());
Now we're able to change how far away our units move depending on the Terrain, and we don't need to rewrite in any of the subclasses.
I hope this helps you a better understanding of the difference.

I'm confused that whatever is achieved via Strategy Pattern is basically possible by polymorphism.
You can't drive a car without a steering wheel. That does not mean that a steering wheel is a car. Similarly, the Strategy pattern relies on polymorphism but that does not mean that they are the same thing.
The purpose of the Strategy pattern is to promote the use of composition (has-a) over inheritance (is-a). Instead of your class inheriting behavior from a super class, you define the behavior in a separate class and your class has-a reference to it.
As far as an example goes, take a look at this answer that does a good job.

Basic difference : Polymorphism is programming language concept, and Strategy pattern is one of behavioral design pattern of GoF.
Polymorphism is the provision of a single interface for several different underlying data types.
Example: The steering wheel(i.e., the interface) is same no matter what type of actual steering mechanism is used. That is, the steering wheel works the same whether your car has manual steering, power steering, or rack-and-pinion steering. Therefore once you know how to operate the steering wheel, you can drive any type of car.
In programming, Polymorphism implemented in two ways:
Early-Binding/Static/Compile-Time Polymorphism (ex: function overloading)
Late-Binding/Dynamic/Run-Time Polymorphism (ex: function overriding)
A Strategy pattern defines a set of algorithms that can be used interchangeably.
The Strategy pattern is a dynamic pattern (How do you want run a behavior in software?).
Example of core java: java.util.Comparator#compare(), executed by among others Collections#sort().
Modes of transportation is analogous to strategy design pattern. We use car, bike, bus, local train and so on.. different strategies to go office day by day.

If you are establishing an analogy where:
in one case you have several overridable methods;
in the other case you have a Strategy interface with several implementations,
then the difference is the degree of coupling, which is very strong in the first case, whereas in the second case any foreign code can participate in your class's logic by contributing its Strategy implementation.

Q: What is the difference between the Strategy pattern and Polymorphism
in Java?
The questions is certainly confusing since initially there seems not to be any relation between these two ideas.
Polymorphism is a much broader concept in programming and yes the strategy pattern in Java uses a form of polymorphism catalogued as inclusion polymorphism to accomplish its intent, but this is by no means the only type of polymorphism that exists, neither it is the only way to implement the strategy pattern as I will demonstrate soon.
Also polymorphism is not something that only exists in Java or in object-oriented programming languages. Different forms of polymorphism exist in all the programming paradigms and not in all languages you are forced to use polymorphism to implement a strategy pattern (e.g. functional languages).
For further discussion on this topic please read this other answer where we have discussed whether polymorphism is possible without inheritance and I provide interesting references and examples to other types of polymorphism like parametric and ad-hoc polymorphism.
Ideally this will reveal to you that polymorphism is a bigger concept that goes beyond the boundaries of object-oriented programming and even beyond inheritance and subtyping.
Q: I'm confused that whatever is achieved via Strategy Pattern is
basically possible by polymorphism. Correct me if I'm wrong in this
regard.
From my point of view the relations between these two concepts are: that the strategy pattern leverages the power of polymorphism available in languages like Java to implement its intent, and that polymorphism can be considered in itself a pattern.
For instance, consider this quote from the GoF book:
If we assumed procedural languages, we might have included design
patterns called 'inheritance', 'encapsulation' and 'polymorphism'.
It is just that we rarely think of polymorphism as a pattern, first because it implies many things and because it is implemented differently in different languages and also because it typically presents as some form of language feature.
In his book Elemental Design Patterns, Jason Mc C. Smith comments on the GoF quote above saying:
Pattern are language-independent concepts; they take form and become
concrete solutions when you implement them within a particular
language with a given set of language features and constructs [...]
This means that it is a bit strange to talk about "Java design
pattern", "C++ design patterns", "Websphere design pattern" and so on,
even though we all do it. It's a mildly lazy form of shorthand for
what we really mean, or should mean: design patterns as implemented in
Java, C++, WebSphere and so on, regardless of language or API.
So, as you can see, you are thinking in the Strategy pattern from the perspective of the Java implementation, but in other language paradigms such pattern may have been implemented in different ways, probably without using inheritance at all, for example, in pure functional programming languages this is most certainly implemented using high order functions and function composition.
As such, this would be an strategy pattern implementation without resorting to inclusion polymorphism at all. In a function composition strategy we may still be using other forms of polymorphism (e.g. parametric), but that is not a requirement for the strategy pattern
Q: Please, also provide me example to eradicate my confusion.
As discussed above, in Java we are probably forced to use inclusion polymorphism to implement a Strategy pattern, but as explained above as well, patterns are not something that belong to a specific language, so if we think of the strategy pattern as a concept living outside any language boundaries then you will easily see other languages implement this in different ways.
In some hypothetical functional language I may have a function that reads some data from a file, maybe the file is encrypted and you need to provide a decryption strategy:
function readFile(path: String, decrypt: string -> string) {
return decrypt(loadFromDisk(path));
}
And that decrypt argument is a function that serves the purpose of a strategy pattern, it encapsulates an interchangeable algorithm.
Now you can do
readFile("customers.txt", aes)
readFile("finance.txt", blowfish)
Where aes and blowfish are decryption function strategies.
There are dozens of languages that work like this, SML, Haskell, JavaScript, etc.

First of all. Polymorphism can mean two different things. Most commonly polymorphism refers to a polymorphic type. However, you are asking for the pattern.
Polymorphic code can change itself each time it runs while the function of the code stays the same. An easy example is to do 1+3=4 instead of 5-1=4. Both achieves the same result using different code. This is useful for code that does not want to be recognized i.e computer viruses or cryptographic code.
Strategy pattern on the other hand uses a family of algorithms that can be interchanged. This might be used when translating text. First some code determines the language. if the language is swedish or spanish the text will be processed by, different functions of the same family, translateSwedish() or translateSpanish().
To round things up. Polymorphic code uses different code that achieves the same result. While Strategy uses different code to achieve better results.

Consider this
we have animals and a strategy pattern object to describe how they move...
for instance
fly/swim/walk
Given the large number of animals that use any of these methods (ie thousands of different animals fly), we need to use the same code for many different animals. That code should only exist in one place, so that it is easily changed and doesn't take up any unneeded space.
In this example, a straightforward polymorphism approach will result in massive code duplication. A more complex approach which places a intermediate class between animal and say robin fail to take in to consideration that how a animal moves is not really what defines it. Furthermore, it is possible that a animal has other strategy objects and they cannot all be made polymorphic through intermediate classes.

One definition for Polymorphism is the provision of a single interface to entities of different types.
With that in mind say you have a “bird” interface and all of your bird classes must implement “laysEggs()” method, well no biggie that works. And as you keep coding your “bird paradise program” you now add the “fly()” and realize that overloading and overriding for penguin and kiwi is unnecessary as in real life they can't fly, yet you must still implement that method. This can become tedious and pointless as you are faced with Ostrich and others that can't fly. And even worst off when adding the method “swim()” because even fewer birds can swim. As you may already know, the strategy pattern solves this problem.
In lame-man’s terms you can think of Polymorphism as a conglomerate of practices, while the Strategy Pattern is the best practice for a specific case. Example: the Strategy Pattern is to be used when an algorithm's behavior needs to be selected at Runtime (via interchangeable algorithms). And although it is sort of true that whatever is achieved via Strategy Pattern is basically possible by polymorphism, without knowledge of the Strategy Pattern this would leave you with the “reinvent the wheel” problem to solve this specific problem. In conclusion, they are very different even if one is based on the other.
I'll leave you to see “Ender Muab'Dib” code as it is well explained if you still want a code example from me just ask, cheers and hope I helped.

Polymorphism is a principle and Strategy is a design pattern
From oracle documentation page
The dictionary definition of polymorphism refers to a principle in biology in which an organism or species can have many different forms or stages. This principle can also be applied to object-oriented programming and languages like the Java language. Subclasses of a class can define their own unique behaviors and yet share some of the same functionality of the parent class.
Polymorphism can be achieved in compile time ( method overloading) and run time (method overriding).
Strategy_pattern
Defines a family of algorithms,
Encapsulates each algorithm, and
Makes the algorithms interchangeable within that family.
Strategy can use run-time polymorphism principle to achieve the desired functionality.
Strategy pattern had one more component called Context in it's URL diagram.
Refer to below SE posts:
Real World Example of the Strategy Pattern
Does this Java Strategy pattern have a redundant Context class?
Few more useful articles:
strategy by sourcemaking

Here is the concise response:
Polymorphism is one of the fundamental characteristics of
object-oriented programming.
Strategy pattern is a language-independent pattern that can be implemented by all
programming languages paradigms, such as imperative, functional, and
object-oriented.
Therefore, if you are going to implement Strategy pattern by using Java, that is OOP, then you just need to use polymorphism.
In other words, Strategy pattern is one of many forms of polymorphism.

Which languages "have subclassing but no inheritance"?

From the pdf of a java course: http://www.ccs.neu.edu/home/riccardo/courses/csu370-fa07/lect4.pdf
It says:
For those of you that follow at home, let me emphasize that subclassing is not inheritance. We will see inheritance later in the course.
Of course, subclassing and inheritance are related. As we will see inheritance is a code reuse mechanism that lets you reuse code easily when defining subclasses. But subclassing makes sense even when you do not have inheritance.
(Indeed, some languages have subclassing but no inheritance, at least, not inheritance like Java implements.)
Subclassing is a property of classes, and is properly part of the type system of Java. Subclassing is used by Java to determine what methods can possibly be invoked on an object, and to return an error at compile-time when an object does not supply a given method.
I want to know which languages have subclassing but no inheritance, at least, not inheritance like Java implements? (Since I'm not quite understand the concepts, so if I can see it in some actual languages, that would make it clearer)

This is a distinction without a difference. Clearly he is talking about inheritance of methods only when he uses the word "inheritance". He isn't using the term in the canonical way introduced by Wegner87, which is inextricably entwined with subclassing:
Inheritance: A class may inherit operations from “superclasses” and may have its operations inherited by “subclasses”. An object of the class C created by the operation “C new” has C as its “base class” and may use operations defined in its base class as well as operations defined in superclasses.
CS teachers often have strange notions. This has been one of them.

Java - what is a a prototype?

In a lecture on Java, a computer science professor states that Java interfaces of a class are prototypes for public methods, plus descriptions of their behaviors.
(Source https://www.youtube.com/watch?v=-c4I3gFYe3w #8:47)
And at 8:13 in the video he says go to discussion section with teaching assistants to learn what he means by prototype.
What does "prototype" mean in Java in the above context?

I think the use of the word prototype in this context is unfortunate, some languages like JavaScript use something called prototypical inheritance which is totally different than what is being discussed in the lecture. I think the word 'contract' would be more appropriate. A Java interface is a language feature that allows the author of a class to declare that any concrete implementations of that class will provide implementations of all methods declared in any interfaces they implement.
It is used to allow Java classes to form several is-a relationships without resorting to multiple inheritance (not allowed in Java). You could have a Car class the inherits from a Vehicle class but implements a Product interface, therefor the Car is both a Vehicle and a Product.

What does "prototype" mean in Java in the above context?
The word "prototype" is not standard Java terminology. It is not used in the JLS, and it is not mentioned in the Java Tutorial Glossary. In short there is no Java specific meaning.
Your lecturer is using this word in a broader sense rather than a Java-specific sense. In fact, his usage matches "function prototype" as described in this Wikipedia page.
Unfortunately, the "IT English" language is full of examples where a word or phrase means different (and sometimes contradictory) things in different contexts. There are other meanings for "template" that you will come across in IT. For instance:
In C++ "template" refers to what Java calls a generic class or method.
In Javascript, an object has a "template" attribute that gives the objects methods.
More generally, template-based typing is an alternative (more dynamic) way of doing OO typing.
But the fact that these meanings exist does not mean that your lecturer was wrong to refer to interface method signatures as "templates".

"prototype" is not the the best/right terminus to be used. interfaces are more like "contracts", that implementing classes have to fulfill.
The method's heads/definitions will have to be implemented in the implementing class (using implements keyword in the class head/class definition/public class xy implements ...).
I guess this naming conventions leave much room for many ideological debates.
Or the author had some sort of a mental lapsus and mapped the construct of prototypical inheritance from javascript into java in his mind somehow.

Interfaces are not prototypes for classes in Java.
In languages like C & C++, which compiles to machine code sirectly, compiler should be aware of the nature of any identifier (variable/class/functions) before they are references anywhere in the program. That mean those languages require to know the nature of the identifier to generate a machine code output that is related to it.
In simple words, C++ compiler should be aware of methods and member of a class before that class is used anywhere in the code. To accomplish that, you should define the class before the code line where it is used, or you should at least declare its nature. Declaring only the nature of a function or a class creates a 'prototype'.
In Java, an 'interface' is something like description of a class. This defines what all methods a particular kind of class should mandatory have. You can then create classes that implements those interface. Main purpose that interfaces serve in java is the possibility that a Variable declared as of a particular interface type can hold objects of any class that implements the object.

He tells it in C/C++ way, let me explain, in C++ you can define prototypes for methods at the header files of classes so that other classes can recognize these methods, also in C where there is no class concept, you can define prototypes at the beginning of file and then at somewhere in same file you can implement these prototypes, so that methods can be used even before their implementation is provided. So in Java interfaces provide pretty much same way, you can define prototypes for methods(method headers) that will be implemented by classes that implement this interface.

In a lecture on Java, a computer science professor states that:
Java interfaces of a class are:
1. are prototypes for public methods,
2. plus descriptions of their behaviors.
For 1. Is ok: - yes, they are prototypes for implemented public methods of a class.
For 2. This part could be a little bit tricky. :)
why?
we know: interface definition (contain prototypes), but doesn't define (describe) methods behavior.
computer science professor states: "... plus descriptions of their behaviors.". This is correct only if we look inside class that implements that interface (interface implementation = prototype definitions or descriptions).
Yes, a little bit tricky to understand :)
Bibliography:
Definition vs Description
Context-dependent
Name visibility - C++ Tutorials
ExtraWork:
Note: not tested, just thinking! :)
C++:
// C++ namespace just with prototypes:
// could be used like interface similar with Java?
// hm, could we then define (describe) prototypes?
// could we then inherit namespace? :)
namespace anIntf{
void politeHello(char *msg);
void bigThankYou();
}

Prototypes provide the signatures of the functions you will use
within your code. They are somewhat optional, if you can order
your code such that you only use functions that are previously
defined then you can get away without defining them
Below a prototype for a function that sums two integers is given.
int add(int a, int b);

I found this question because i have the same impression as that teacher.
In early C (and C++ i think) a function, for example "a" (something around lexic analysis or syntactic, whatever) can not be called, for example inside main, before it's declaration, because the compiler doesn't know it (yet).
The way to solve it was, either to declare it before it's usage (before main in the example), or to create a prototype of it (before main in the example) which just specifies the name, return values and parameters; but not the code of the function itself, leaving this last one for wherever now is placed even after it's called.
These prototypes are basically the contents of the include (.h) files
So I think is a way to understand interfaces or the way they say in java "a contract" which states the "header" but not the real body, in this case of a class or methods

Core difference between object oriented and object based language

I want to know what is the core difference between
Object Oriented and Object based languages
I have read many post all of them are saying two things
Object-oriented language supports all the features of OOPs and Object-based language doesn't support all the features of OOPs like Polymorphism and Inheritance.
They are giving example of javascript as object based and java as object oriented
Like this post of stackoverflow
Difference between object oriented and object based language
But I want to know what is the core difference between both the concept regardless of any language.
Got the answer
Finally got the thing
thanks to Matías Fidemraizer
Answer which is not dependent on any language, not dependent on any feature, the core differnce for which I am loooking that is
The language which itself contains objects is called as object based language and the language with follows object oriented concepts is known as object oriented language

JavaScript is a prototype-oriented language.
It can build actual objects from a constructor function and it has almost any feature that any object could have:
Constructor.
Methods (i.e. functions in JavaScript).
Properties (since ECMA-Script 5, "getters/setters").
Instances.
In JavaScript, any object has a prototype, including functions. The prototype itself is a rudimentary way of adding object members to any newly created instance of the whole object.
var constructor = function() { };
constructor.prototype.text = "hello world";
alert(new constructor().text); // This alerts hello world
Why JavaScript isn't an object-oriented programming (scripting) language? Because it has no feature that fits the requirements of the definition of object-oriented programming:
Polymorphism: No. You can change the behavior of a prototype member, but this is just reusing the identifier. You aren't able to access the previous implementation of the member in a pseudo-derived object.
Inheritance: Not at all. Maybe prototype chain might be comparable to inheritance but JavaScript (ECMA-Script 5.x or earlier versions) has no syntax-based inheritance like other OOP-based languages (i.e. Java, C#, Ruby, Python, VisualBasic.NET, ...).
Encapsulation. Yes, of course, but there's no way to create actual private or internal object members.
Perhaps I forgot to mention some other detail, but I honestly believe that this is a good summary.
Update and summary
The core difference is an object-oriented programming language has the features that an object-oriented paradigm must have in order to be considered an object-oriented programming language. Thus, JavaScript, for now, isn't an actual object-oriented programming language because it lacks actual polymorphism and inheritance.
Update: Does ES2015 and above changed the situation?
Esthetically speaking yes, ES2015 and above has a major improvement that let consider a not fully but more closer to an object-oriented programming: syntactic sugar to call to the super class.
For example:
class A {
doStuff() {
console.log("hello world");
}
}
class B extends A {
doStuff() {
super.doStuff();
console.log("...and goodbye!");
}
}
This is polymorphism. A more specialized class can override its base class to both completely change a function behavior or do what the base was already doing, adding new code to the function.
BTW, ES2015 and above still lacks true encapsulation: where are access modifiers like private or public here? Nowhere.
And, at the end of the day, ES2015 and above implement class-based OOP but it's still a syntactic sugar layer on top of ECMAScript 5.x... The above code still works with prototypes under the hoods and it works the same way as if you would code it in ECMAScript 5.x:
function A() {
}
A.prototype.doStuff = function() {
console.log("hello world");
};
function B() {
}
B.prototype = Object.create(A.prototype);
B.prototype.doStuff = function() {
A.prototype.doStuff.call(this);
console.log("...and goodbye!");
};
Let's hope I'll need to update this answer again because ES2020 has already proposed access modifiers and we'll be able to consider JavaScript another language which fully-supports object-oriented programming!

Object-based languages include basically any language that offers the built-in ability to easily create and use objects. There is one major criterion:
Encapsulation. Objects have an API attached to them, typically in such a way that you work with the object more by telling it what to do than by running some function on it.
Most object-based languages define objects in terms of "classes", which are basically blueprints for an object. The class lays out the internal structure of the object and defines the API.
This is not the only way, though. In JavaScript, for example, objects don't really have "classes". Any object can have any properties it wants. And since functions are first-class values in JavaScript, they can be set as properties on the object, and serve as the object's API.
As far as object-based-but-not-object-oriented languages go, a good example would be Visual Basic (not the .net stuff; i'm talking about VB6 and VBA). Classes exist, but can't inherit from each other.
Object-oriented languages are object-based languages that take things a step further. They have built-in support for the two other pillars of OOP:
Inheritance. Objects must have the ability to be (and be viewed as) specializations of some other object. This means, for example, being able to define "Dog" as "Animal that can bark and fetch sticks".
In modern languages, it typically takes the form of one object's class inheriting from another object's class. This is not a requirement, though; contrary to what some people will try to tell you, the definition of OOP does not require classes at all.
Polymorphism.  Code must be able to use an object without knowing or caring exactly what type it is.
Most languages (especially statically typed ones) define polymorphism in terms of classes and inheritance. If you have a class B that inherits from A, code that requires a reference to an A can typically take a B instead, but not some class C that isn't related to A. Java also has the interface keyword, which lets you define a set of behaviors a class must implement. Any object whose class explicitly implements X, and thus implements the functions defined on interface X, qualifies as an instance of type X.
 Other languages, like JavaScript, let you pass any object you like. As long as the object presents the right interface, it doesn't matter exactly what kind of object it is. This is called "duck typing", and it is very nearly the purest form of polymorphism there is.

Just using objects does not mean you are doing OOP, even in a fully OO language if you are not implementing OO techniques it is simply object-based programming.

There are 4 major elements that a Programming Language must conforms to in order to be a true object-oriented language. These are: Abstraction, Encapsulation, Modularity & Hierarchy.
However, we can call a Language Object based if that supports the first there elements. As soon as a programming language supports the concept of Object, inherently it supports the first three elements as they are inherent feature of an Object.
JavaScript as a language can not be said a Object Oriented but Object Based Language as it doesn't support Hierarchy (especially Inheritance).

OOP and OBP are types of programming languages follows different principles.
OOP : follows Polymorphism, Inheritance and Encapsulation(PIE).
Examples: Java, .Net so on. OOP is new comparing with OBP
OBP : follows Polymorphism and Encapsulation.
Examples: Ada, Visual Basic (VB), and Fortran 90. OBP is old

crudely...
object-oriented: supports encapsulation, inheritance, polymorphism
object-based: supports encapsulation
Wikipedia - Object-Based Language

Object oriented programming languages follow all concepts belonging to OOP.
Object based programming language has objects ibuilt so there's no need to create objects and it also follows OOP concepts except inheritence,

Object orientd language
Object-orientd language supports all the features of OOPs
Object-orientd language does not has in-built object
Object-orientd languages are C++, C#, Java etc
Object based language
Object-based language doesn't support all the features of OOPs like Polymorphism and Inheritance
Object-based language has in-built object like JavaScript has window object.
Object-based languages are JavaScript, VB etc.
Hope, this will clarify your doubt.