Develop Reference

type casting when objects are of interface references in Java

I am familiar with type casting in inheritance model.
Let SuperClass and SubClass be parent and child classes;
SuperClass superClass = new SubClass(); -- Here the object instantiated is a subclass object;
but its reference type is SuperClass; that is only those methods of SuperClass can be called on the subclass object; Any methods that are not inherited/overridden in subclass cannot be called (that is any unique methods of subclass).
I observed same behavior as above if SuperClass is an interface and SubClass implements it. That is only those methods declared in SuperClass interface are available to be called on the SubClass object. Is my understanding correct? But with some casting, I can call methods that is not part of the interface, which I have observed in my sample code below;
I have made some comments on my understanding as how it works;
but I would like to know if that make sense or if my interpretation is wrong;
class Animals {
public void bark(){
System.out.println("animal is barking");
}
}
interface catIF {
public void catting();
}
interface dogIF {
public void dogging();
}
class Dog extends Animals implements dogIF {
public void bark(){
System.out.println("dog is barking");
}
public void dogging() {
System.out.println("dogging");
}
}
class Cat extends Animals implements catIF {
public void bark(){
System.out.println("cat is barking");
}
public void catting() {
System.out.println("catting");
}
}
public class Animal {
public static void main(String[] args){
dogIF dog = new Dog();
//dog.bark(); this fails
//This method actually actually exists;
//but it is not available or hidden because dogIF reference
//limits its availability; (this is similar to inheritance)
Dog dog2 = new Dog();
dog2.bark();
////prints dog is barking
Animals an =(Animals) dog;
an.bark();
//prints dog is barking
//by casting we mean, treat the dog as an animals reference
//but the object itself is a dog.
//call the bark() method of dog
//but dog did not have this method in the beginning (see first line
// in main - when instantiated with interface type)
}
}

Inheritance of interfaces really isn't "flaky" or complicated. They behave exactly the way abstract classes do, with the exceptions that you reference them differently (implements rather than extends) and that you're allowed to inherit as many interfaces as you like but can only have one superclass (abstract or not).
As with other inheritance: If all you know about an object is that it implements an interface, then you can only access it through that interface. If you know that it implements another interface, or a specific superclass, or is an instance of a particular class, then you can cast it to those and access it through the exposed members of those.
So, yes: If all your program knows is that the object is an instance of Animals, then all you can do is call what's declared on Animals. That means bark() plus whatever methods it inherits from Object (since everything is an Object directly or indirectly even if that isn't explicitly stated).
If your program knows that the object is an implementation of dogIF or catIF -- because the variable type says it is, or because you've successfully typecast it to one of those interfaces -- you can also call the method(s) declared by those interfaces. By the way, the usual convention for interfaces is to name them like classes, with UppercasedFirstLetter... since in many cases the difference between an interface and a class really isn't significant to the folks using it.
If your program happens to know that the object is a Dog, you can call anything it inherits from either Animals or dogIF, or that is provided directly by Dog. Of course it could actually be a Chihuahua (subclass of dog), but that's OK, the subclass will respond to anything the superclass would have responded to, in "the right way to maintain the semantics". (That is, a Chihuahua may respond to bark() by saying "yip yip yip grr yip!", but that method really shouldn't cause it to try to bite your ankle.)
Hope that helps. It really isn't that complicated.

What is the use of passing object to another class reference in java?

For example: Foo ab=new Dog();
Saving object of another type class to reference of another class!

It's not always necessary to do something like Foo foo = new Bar() but it's often recommendable to refer to the interface and not the implementation.
This way you can change your implementation without needing to change other code.
For example if you're doing something with Lists and you use ArrayLists you might do:
ArrayList<Integer> numbers = new ArrayList<>();
//Do stuff with numbers
However you might not care what kind of list it is so you're probably better off with
List<Integer> numbers = new ArrayList<>();
//Do stuff with numbers
Now it doesn't matter what kind of List you've got and maybe you find that you'll get better performance with a LinkedList and you can just use that instead of changing any other code.
I would say that polymorphism is most important when receiving objects by other callers though.

Yes if Foo is an interface then this approach gives you more control on your code. You achieve Polymorphism, Plug-ability, Maintainability and Loose coupling characteristics of java programming language.
Let's say if you are supposed to connect to oracle from your application and written the code like this
OracleDrive driver= new OracleDriver()
driver.connect();
it will solve your problem. But will make your code tightly coupled with OracleDriver. Your application won't compile at all if you remove Oracle related jar from your classpath. And if someone ask you make your app connect to different DBs based on their configuration then you end up with multiple ifs based on your application supported DBs. which is bad practice as per programming standards.
If you all DB drives implements an interface Driver then you can load driver based on configuration without tightly coupling your code to any specific driver class like this
Driver driver = properties.get(db.driver.class)
driver.connect()
Now you see that you need to change you application to connect to MySql you just need to set that class in your configuration file.
Hope you got my point!

It's more useful with method parameters.
class Animal {
public boolean hasHair = true;
public void speak() {}
}
class Dog extends Animal {
public void speak() {
System.out.println("Woof!");
}
}
class Person {
public void shave(Animal a) {
a.hasHair = false;
a.speak();
}
}
class Main {
public static void main(String[] args) {
Person joe = new Person();
Dog fido = new Dog();
joe.shave(fido);
}
}
In this case a Person can shave any Animal, but we pass it a Dog.
Animal fido = new Dog(); would be less useful, because we know fido is a dog, but consider this:
Animal pet;
if(joe.prefersCats)
pet = new Cat();
else
pet = new Dog();

Simple answer, You cannot do that.
More Complicated Answer, You would be able to do that only if 'Dog' is type of 'Foo'.
When will we say Dog is type of 'Foo' is if Dog implements Foo (If an interface) or extends Foo (If another Class or Abstract Class)
Now, coming to advantages of Coding to Interfaces (Technical name of your question) is
1) Java's Polymorphism is based on this (Polymorphism makes runtime change in behaviour possible, Please google polymorphism in java for more information)
2) You are making interfaces independent of implementations by this approach.
hope this answered your question.

This type of declaration is only possible
Foo ab=new Dog();
if Dog class extends class Foo or Foo is an interface which is implemented by Dog class as
class Dog extends Foo { .... }
or
class Dog implements Foo { ... } //Here Foo is an interface
I think so there is no use if you initialize class objects with inherited interface or inherited class as all the base class functions, properties will be available in your derived class object. This type of declaration will come handy if you are initializing multiple objects having same base class with different derived classes.
For Example,
public class MyObject
{
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
public class MyFile extends MyObject
{
private String extension;
public String getExtension() {
return extension;
}
public void setExtension(String extension) {
this.extension = extension;
}
}
public class MyFolder extends MyObject
{
}
If you are initializing
MyObject file = new MyFile();
This is really of no use but it will be useful when we want to initialize
List<MyObject> listOfFilesFolders = new ArrayList<MyObject>();
listOfFilesFolders.add(new MyFile());
listOfFilesFolders.add(new MyFolder());
This 'listOfFilesFolders' can be private variable of another class which keeps list of files/folders present.
Or we want to have function as
private void SomeFunction(MyObject obj)
{
}
which can take all the objects which are derived from base class and perform operation according to base class properties or functions.

See one of my old answers here:
What is the advantage of using interfaces
It's an anecdote about an anecdote that one of my professors once told us.
Long story short, when you get into more complex systems, the reason that you would want this becomes more clear. The ability to separate specification (interface/abstract class and its contract) from implementation (concrete class) is a powerful tool that makes it very easy to write new implementations without having to change code elsewhere in your application. You use the specification in your code, e.g. the specification:
public interface Animal { ... }
Your implementation:
public class Dog implements Animal { ... }
Then in code, you use the specification whenever possible:
Animal a = new Dog();
a.eat(); // All animals eat, so eat() is on the Animal interface
Unless you absolutely need to use the implementation itself:
Dog d = new Dog();
d.bark(); // Other animals don't bark, so we need to have the Dog here
This makes your code cleaner. For example, say I have a method feedAndGroom. If I didn't have an interface, I would need to create a new method for each animal I want to support:
public static void feedAndGroom(Cat c) { ... }
public static void feedAndGroom(Dog d) { ... }
public static void feedAndGroom(Turtle t) { ... }
Each code block might even look exactly the same, depending on the situation. Even worse, what happens when someone discovers a new animal? We'd have to add a new method each time, which would result in a huge number of methods. The solution to all this duplication is to create an interface around the functionality, then have a single method:
public static void feedAndGroom(Animal a) { ... }
This will take anything that implements the Animal interface. All these method calls are legal:
feedAndGroom(new Cat());
feedAndGroom(new Dog());
feedAndGroom(new Turtle());
However, these method calls are legal too:
feedAndGroom(new Hyena());
feedAndGroom(new Lion());
feedAndGroom(new Panther());
We may not want to try and feed and groom these animals, at least not wild ones, so we can add a new interface called DomesticatedAnimal that extends Animal:
public interface `DomesticatedAnimal` extends `Animal` { ... }
And change our method to:
public static void feedAndGroom(DomesticatedAnimal da) { ... }
Then instead of implementing Animal, the Dog, Cat, and Turtle classes will implement DomesticatedAnimal. For example:
public class Dog implements DomesticatedAnimal { ... }
This means that Dog is both a DomesticatedAnimal because it directly implements it, and an Animal by inheritance since DomesticatedAnimal extends Animal. The other animals, Hyena, Lion, and Panther, just implement the Animal interface. This means that our new method won't take just any Animal like our original one, but instead restricts it down to a specific kind of Animal object. Meanwhile, any methods written to use the original Animal interface would still work for all the objects involved.

You can always substitute a reference to a subclass in place of a base class.
In other words, you can always use something more specific in place of something more general—so if you have got a line of code that asks for a Canine, you can send it a reference to a Dog.
So this line of code:
Foo ab=new Dog();
means that you are instantiating a new Dog object, and then creating a
Foo reference called ab and pointing it at that object.

How do I enforce a child class from an abstract class to implement a static method

I have the abstract class Animal, and then I have classes like Dog and Cat, wich extend the class Animal.
I would like to make sure that all child classes of the parent class Animal have a static method: getProperties. Even when someone else, who doesn't have access to my code, implements a new Animal child class.
I want it to be static since all Animals of class Dog have the exact same properties (or you don't need a Dog to know how a Dog looks like genericly), and therefor it makes sense that it's a method called on the classtype, rather then a class instance.
Is this possible?

A static in Java means that the method (for example) in not related to any of the instances of the class. It's common to all the instances and it's implementation is just nested within the class.
As I read you problem, I believe you need an abstract method in the Animal class.
public abstract class Animal {
public abstract <some-return-type> getProperties();
}
In this case, every class which inherits Animal will have to provide an implementation of the getProperties method (which is not static in this case).
If you want it to be static, just make it so (within the Animal class), but then you will have a single and shared implementation.

The Java Object model doesn't support class-side inheritance (unlike Smalltalk or Ruby).
You have to explicitly implement a meta model of your domain, for instance, like this:
public abstract class AnimalDescriptor<T> { // or <T extends Animal>
public abstract List<String> getProperties();
public abstract T newAnimal();
}
public class DogDescriptor extends AnimalDescriptor<Dog> {
public static final DogDescriptor INSTANCE = new DogDescriptor();
public List<String> getProperties() { ... }
public Dog newAnimal() { return new Dog(); }
}
void doStuff(AnimalDescriptor<?> desc) {
desc.getProperties();
}
doStuff(DogDescriptor.INSTANCE);
This is just an example, you will have to adapt it to suit your needs. For instance, you might want to add a getDescriptor() method on the animal side.

No, not possible. There's no inheritance in static contexts. And no, there's no way to enforce a class to implement a static method.

That's not possible in Java, at much you could "hide" a static method, but not "override" it.

If you want to have each Animal class provide metadata about it, give it instance methods like getProperties, getNumberOfLegs, getLocomotionType, etc. You can implement these using static constants:
public abstract class Animal {
public abstract int getNumberOfLegs();
}
public class Dog {
private static final NUMBER_OF_LEGS = 4;
public int getNumberOfLegs() {
return NUMBER_OF_LEGS;
}
// ...
}
I suppose you wanted a Map of some sort for the getProperties method. The problem with that is that you must be very careful to make the map you return immutable. One mistake, and someone can change the static instance for everyone. making the method an instance method costs you almost nothing.

Static methods need to be able to run without you explicitly creating a new instance of the Animal class. You will have to fully implement Animal.getProperties().

How to wrap different type of object in one single wrapper object

i have a condition where i need to use a fixed Method signature which may accept different type of object. one solution i think is to use a super class and let all as a subclasses. however is there any good elegant design pattern kind of solution where we solve this
also once method gets an object of certain type can we know the type of instance without instanceof check ?
please suggest.

Your question is a little bit vaque, and can be interpreted in two different ways:
Implementing different behavior in one class
Let's assume you have two different classes: Cat and Dog. Then you have a class Animals and want to do something like this:
Cat cat = new Cat();
Dog dog = new Dog();
Animals animals = new Animals();
animals.feed(cat);
animals.feed(dog);
Here feed() executes different code, depending on the parameter type:
public class Animals {
public void feed(Cat cat) {
// ... feed the cat
}
public void feed(Dog dog) {
// ... feed the dog
}
}
This is called method overloading.
Implementing different behavior in different classes
On the other hand, you could define an interface Pet which provides a method, let's say eat():
public interface Pet {
void eat();
}
Then Cat and Dog should implement Pet to get different behavior:
public class Cat implements Pet {
public void eat() {
//...
}
}
public class Dog implements Pet {
public void eat() {
//...
}
}
Then your class Animals would look like this:
public class Animals {
public void feed(Pet pet) {
pet.eat();
}
}

Implementing an interface is a better pattern than inhering a super class. in that way your classes retain their one-inheritance capacity.
regarding the other question about instanceOf, there is rarely a genuine need to determine the actual class of the object. you can always resort to polymorphism. put all methods that you need to invoke on the object in the interface itself. in that way you will never need to know the actual type.

Instantiating interfaces in Java

I have this interface:
public interface Animal {
void Eat(String name);
}
And this code here implements the interface:
public class Dog implements Animal {
public void Eat(String food_name) {
System.out.printf(food_name);
}
public static void main(String args[]) {
Animal baby2 = new Dog(); // <- this line
baby2.Eat("Meat");
}
}
My question is, why does the code work? An interface cannot be instantiated. Yet in this case, interface was instantiated (marked with the comment).
What is happening here?

No it is not - you are instantiating a Dog, but since a Dog is an Animal, you can declare the variable to be an Animal. If you try to instantiate the interface Animal it would be:
Animal baby2 = new Animal();
Try that, and watch the compiler scream in horror :)

Dog is not an interface: Dog is a class that implements the Animal interface.
There's nothing untoward going on here.
Note that you can instantiate an anonymous implementation of an interface, like so:
Animal animal = new Animal() {
public void Eat(String food_name) {
System.out.printf("Someone ate " + food_name);
}
};

Let's consider below code:
interface Cookable {
public void cook();
}
class Food {
Cookable c = new Cookable() {
public void cook() {
System.out.println("anonymous cookable implementer");
}
};
}
The preceding code creates an instance of an anonymous inner class, but here, the new just-in-time class is an implementer of the Cookable interface. And note that this is the only time you will ever see the syntax:
new Cookable()
where Cookable is an interface rather than a nonabstract class type. Think about it:
You can't instantiate an interface, yet that's what the code looks like it's doing. But, of course, it's not instantiating a Cookable object-- it's creating an instance of a new anonymous implementer of Cookable.
You can read this line:
Cookable c = new Cookable(){}
as "Declare a reference variable of type Cookable that, obviously, will refer to an object from a class
that implements the Cookable interface. But, oh yes, we don't yet have
a class that implements Cookable, so we're going to make one right
here, right now. We don't need a name for the class, but it will be a
class that implements Cookable, and this curly brace starts the
definition of the new implementing class."
Important to remember for anonymous interface implementers-- they can implement only one interface. There simply isn't any mechanism to say that your anonymous inner class is going to implement multiple interfaces. In fact, an anonymous inner class can't even extend a class and implement an interface at the same time. The innve class has to choose either to be a subclass of a named class and not directly implement any interface at all or to implement a single interface.
So don't be fooled by any attempts to instantiate an interface except in the case of an anonymous inner class. The following is not legal:
Runnable r = new Runnable(); // can't instantiate interface
whereas the following is legal, because it's instantiating an implementer of the Runnable interface(an anonymous implementation class):
Runnable r = new Runnable() {
public void run(){ }
};
You can read my article here.

What you're observing here is the Dependency inversion aspect of SOLID.
Your code is depending on the abstraction of the Animal contract by instantiating a concrete implementation of it. You're merely stating, "I'm instantating some object, but regardless of what that object actually is, it will be bound to the contract of the Animal interface."
Take, for instance, these sorts of declarations:
List<String> wordList = new LinkedList<>();
Map<Integer, String> mapping = new HashMap<>();
In both of those cases, the primary aspect of the list and map is that they follow the generic contract for a List and Map.

Animal baby2 = new Dog(); //HERE!!!!!!!!!!!!!!!!!!!!!!
Surely you are not instantiating the Animal. You are only referring the Dog instance to it.
In java we can take the super class reference.

This is a case of polymorphism, It looks like you are creating 'Animal' object but it is not. You are creating 'Dog' object which is calculated on run time.'Animal' acts as contract. Interface can not be instantiated directly but can be used as type by upcasting its subclass. You can also use anonymous class to instantiate an object as 'Animal' type.
Animal baby2 = new Dog(); //upcasting polymorphically
Animal baby3=new Animal(){
public void Eat(String food){System.out.println("fdkfdfk"); }
}
//You can instantiate directly as anonymous class by implementing all the method of interface

The interface Animal is not be intantiated but be implemented by Dog.And a Dog is intantiated

When you say:
Animal baby2 = new Dog();
the reference type is Animal(the interface) which points to a concrete implementations (Dog). The object type Dog is concrete and can be instantiated. In this case, as long as Dog hasanimal point to Dog. a concrete implementation of all the methods in the interface, you can make a reference type of
If you did something like,
Animal baby2 = new Animal(); // here you are actually instantiating
this would be invalid because now you are trying to create a concrete object from an abstract implementation.

The Interface Animal acts as the data type to the class Dog. You're actually instantiating the Dog class not the interface or it's data type.

To have a wider picture :
Animal [] Zoo = new Animal[10] ; // is also correct
but why ?
The whole idea is that in the table above you can put 10 animals of different types. The only conditions for this is that all the animals entering the Zoo must implement the interface Animal .
public interface Animal {
void Eat();
}
class Wolf implements Animal { void Eat (){
System.out.println("Wolf eats meat ") ;}}
Class Zebra implements Animal{ void Eat (){
System.out.println("Zebra eats the grass ") ;}}
class test {
public static void main (String args []) {
Animal [] Zoo = new Animal[2] ;
Zoo[0] = new Wolf() ;
Zoo[1] = new Zebra() ;
//so you can feed your animals in Zoo like this
for (int i=0 ; i<Zoo.lenght;i++) {Zoo[i].Eat();}
}
}

You can't instantiate an interface. The functionality can be considered similar to that of an abstract class. You can have a reference to the interface but you don't create an object of interface. If you do something like this....
Animal a = new Animal();
The compiler will show an error- "Cannnot instantiate the type Animal".

Actually you can instantiate the interface. Here is the code you can try
public static void main(String args[]) {
System.out.println(new Animal() {
public String toString() {
return "test";
}
});
}
This program runs successfully and prints test
Try it.

Here it is just referencing to the interface but instantiation is done by the class only.
for e.g
Animanl a = new Dog
Animal a - variable is referenced
new Dog - now Memory is allocated

Java 8 let you use, the functional interface,
#FunctionalInterface // this is not mandatory
interface A{
void m1(); // only one abstract method allowed for functional interface
}
class Main{
public static void main(String a[]){
// old usage
A a1 = new A(){
#Override
public void m1(){
System.out.println("Call Me normally");
}
};
a1.m1();
// new in java 8, functional interface
A a2 = ()-> System.out.println("Call Me as functional interface");
a2.m1();
}
}

What have you done is type casting. You have created an instance of class dog and has type caste it to interface animal.It is an example of runtime polymorphosim. But yes an interface can be implemented and I have reached here while searching for this.
i.e.
public class demo16{
interface cardio{
void run();
}
static void foo(){
cardio c = new cardio(){ //HENCE instance of "interface cardio" is being created inside a method foo
public void run(){
System.out.println("How you doing ! ");
}; //HENCE observe the ";" beside }
}; //HENCE observe the ";" beside }
c.run();
}
public static void main(String [] args){
foo();
}
}