We Keep Coding

What is the difference between these two codes regarding interface?

I am currently learning java. I just don't understand the use of interface and I am really confused about it.
These two codes return the same answer, then what is the use of interface here?
interface Jumpable {
abstract int maxDistance();
}
class Animal implements Jumpable {
public int maxDistance() {
return 100;
}
}
public class Forest {
public static void main(String args[]) {
Animal lion = new Animal();
System.out.println(lion.maxDistance());
}
}
class Animal {
public int maxDistance() {
return 100;
}
}
public class Forest {
public static void main(String args[]) {
Animal lion = new Animal();
System.out.println(lion.maxDistance());
}
}

In the state your code is in right now, there is no difference, but that is not what it is about. Further down the line you will need to do things with your animals, without knowing what animals you have or what they can do.
Suppose you want to subclass your animals, into mammals, birds and insects. Some of them can jump, but not others. It will be very ugly code if you create specific classes or attributes for mammals that can jump etc. If you instead create an interface, you have lots of options. You can create a list of animals that can jump, and then tell them to jump, regardless of their type.
Later, you might want to add screaming to your animals. Just add an interface for that.

Create a dynamic class in java

I'm working on a problem where different animal types implement the same talk() method from Animal interface.
If you look at getAnimal() method, you can see that, when a new kind of animal is added to the program, inside of that method has to be changed as well.
I want to add new animals just by subclassing Animal without changing anything in the already existing classes.
For example, add an animal "Dog", criteria="loyal"; talk="woof".
Could you tell me, how it is possible? Below is my code:
interface Animal {
public void talk();
}
class Lion implements Animal {
#Override
public void talk() {
System.out.println("ROARRRRR");
}
}
class Mouse implements Animal {
#Override
public void talk() {
System.out.println("SQUEEEEEAK");
}
}
class Bison implements Animal {
#Override
public void talk() {
System.out.println("BELLOWWWWW");
}
}
class AnimalType {
public static Animal getAnimal(String criteria) {
// I refactor this method
if (criteria.equals("small")) {
return new Mouse();
} else if (criteria.equals("big")) {
return new Bison();
} else if (criteria.equals("lazy")) {
return new Lion();
}
return null;
}
}
public class AnimalExamples {
public static void main(String[] args) {
AnimalType.getAnimal("small").talk();
AnimalType.getAnimal("big").talk();
AnimalType.getAnimal("lazy").talk();
// how to add an animal "Dog" here, criteria="loyal"; talk="woof"
AnimalType.getAnimal("loyal").talk();
try {
AnimalType.getAnimal("small").talk();
} catch (Exception ex) {
System.out.println("Animal does not exists");
}
}
}
I searched on google, understood it can be done by reflection. But do not know how. If possible, could you help me with this, please? Thanks in advance!

Just so you know runtime class generation is extremely complex and not something recommended for beginners to the language. This would be an excellent scenario to use a map an anonymous classes.
class AnimalType {
private static final Map<String, Animal> animals = new HashMap<String, Animal>();
static {
// Populating map with default animals
addAnimal("big","BELLOWWWWW"); // bison
addAnimal("small","SQUEEEEEAK"); // mouse
addAnimal("lazy","ROARRRRR"); // lion
addAnimal("loyal","WOOF "); // dog
}
public static void addAnimal(String criteria, final String sound) {
// Assigning a anonymous implementation of animal to the given criteria
animals.put(criteria, new Animal() {
#Override
public void talk() {
System.out.println(sound);
}
});
}
public static Animal getAnimal(String criteria) {
// Returning an animal from the animals map
return animals.get(criteria);
}
}
If you really do insist on true runtime class generation or if you're curious how it works, check out ByteBuddy.

Old question, but here is how to create class... For me the easy way is to use Javassist.
I created a small example here: http://hrabosch.com/2018/04/08/generate-class-during-runtime-with-javassist/
But here is main point:
public static Class generateClass(String className, String methodName, String methodBody)
throws CannotCompileException {
ClassPool pool = ClassPool.getDefault();
CtClass cc = pool.makeClass(className);
StringBuffer method = new StringBuffer();
method.append("public void ")
.append(methodName)
.append("() {")
.append(methodBody)
.append(";}");
cc.addMethod(CtMethod.make(method.toString(), cc));
return cc.toClass();
}
So what I did... Via Javassist I made a class in ClassPool. Also I added a method inside this class and via reflection I invoked it.
Hope it helps.
Just keep on mind whatever you want to use in generated class, there
are NOT imports, so you have to use fully-qualified names.

Java doesn't support creating a class at runtime. However there are really better ways of achieving what you want here. I'll propose two.
Firstly, you could create an AnimalType class that contains all the shared behaviour about a species. You could then have an Animal class that takes an AnimalType as a constructor parameter.
Secondly, you could use a prototype design pattern. In this case the Animal class would need a clone method to create a new animal from the prototype. The factory class could then have a list of the prototypes and use whatever logic you desire to choose the correct prototype to clone.
Comment below if you want further details or sample code for either of these options.

you have to define the dog class
class Dog implements Animal {
#Override
public void talk() {
System.out.println("woof");
}
}
and add the if else to AnimalType
} else if ("loyal".equals(criteria)) {
return new Dog();
}

Calling methods from objects which implement an interface

I am trying to wrap my head around interfaces, and I was hoping they were the answer to my question.
I have made plugins and mods for different games, and sometimes classes have onUpdate or onTick or other methods that are overridable.
If I make an interface with a method, and I make other classes which implement the method, and I make instances of the classes, then how can I call that method from all the objects at once?

You'll be looking at the Observer pattern or something similar. The gist of it is this: somewhere you have to keep a list (ArrayList suffices) of type "your interface". Each time a new object is created, add it to this list. Afterwards you can perform a loop on the list and call the method on every object in it.
I'll edit in a moment with a code example.
public interface IMyInterface {
void DoSomething();
}
public class MyClass : IMyInterface {
public void DoSomething() {
Console.WriteLine("I'm inside MyClass");
}
}
public class AnotherClass : IMyInterface {
public void DoSomething() {
Console.WriteLine("I'm inside AnotherClass");
}
}
public class StartUp {
private ICollection<IMyInterface> _interfaces = new Collection<IMyInterface>();
private static void Main(string[] args) {
new StartUp();
}
public StartUp() {
AddToWatchlist(new AnotherClass());
AddToWatchlist(new MyClass());
AddToWatchlist(new MyClass());
AddToWatchlist(new AnotherClass());
Notify();
Console.ReadKey();
}
private void AddToWatchlist(IMyInterface obj) {
_interfaces.Add(obj);
}
private void Notify() {
foreach (var myInterface in _interfaces) {
myInterface.DoSomething();
}
}
}
Output:
I'm inside AnotherClass
I'm inside MyClass
I'm inside MyClass
I'm inside AnotherClass
Edit: I just realized you tagged it as Java. This is written in C#, but there is no real difference other than the use of ArrayList instead of Collection.

An interface defines a service contract. In simple terms, it defines what can you do with a class.
For example, let's use a simple interface called ICount. It defines a count method, so every class implementing it will have to provide an implementation.
public interface ICount {
public int count();
}
Any class implementing ICount, should override the method and give it a behaviour:
public class Counter1 implements ICount {
//Fields, Getters, Setters
#Overide
public int count() {
//I don't wanna count, so I return 4.
return 4;
}
}
On the other hand, Counter2 has a different oppinion of what should count do:
public class Counter2 implements ICount {
int counter; //Default initialization to 0
//Fields, Getters, Setters
#Overide
public int count() {
return ++count;
}
}
Now, you have two classes implementing the same interface, so, how do you treat them equally? Simple, by using the first common class/interface they share: ICount.
ICount count1 = new Counter1();
ICount count2 = new Counter2();
List<ICount> counterList = new ArrayList<ICount>();
counterList.add(count1);
counterList.add(count2);
Or, if you want to save some lines of code:
List<ICount> counterList = new ArrayList<ICount>();
counterList.add(new Counter1());
counterList.add(new Counter2());
Now, counterList contains two objects of different type but with the same interface in common(ICounter) in a list containing objects that implement that interface. You can iterave over them and invoke the method count. Counter1 will return 0 while Counter2 will return a result based on how many times did you invoke count:
for(ICount current : counterList)
System.out.println(current.count());

You can't call a method from all the objects that happen to implement a certain interface at once. You wouldn't want that anyways. You can, however, use polymorphism to refer to all these objects by the interface name. For example, with
interface A { }
class B implements A { }
class C implements A { }
You can write
A b = new B();
A c = new C();

Interfaces don't work that way. They act like some kind of mask that several classes can use. For instance:
public interface Data {
public void doSomething();
}
public class SomeDataStructure implements Data {
public void doSomething()
{
// do something
}
}
public static void main(String[] args) {
Data mydataobject = new SomeDataStructure();
}
This uses the Data 'mask' that several classes can use and have certain functionality, but you can use different classes to actually implement that very functionality.

The crux would be to have a list that stores every time a class that implements the interface is instantiated. This list would have to be available at a level different that the interface and the class that implements it. In other words, the class that orchestrates or controls would have the list.
An interface is a contract that leaves the implementation to the classes that implements the interface. Classes implement the interface abide by that contract and implement the methods and not override them.
Taking the interface to be
public interface Model {
public void onUpdate();
public void onClick();
}
public class plugin implements Model {
#Override
public void onUpdate() {
System.out.println("Pluging updating");
}
#Override
public void onClick() {
System.out.println("Pluging doing click action");
}
}
Your controller class would be the one to instantiate and control the action
public class Controller {
public static void orchestrate(){
List<Model> modelList = new ArrayList<Model>();
Model pluginOne = new plugin();
Model plugTwo = new plugin();
modelList.add(pluginOne);
modelList.add(plugTwo);
for(Model model:modelList){
model.onUpdate();
model.onClick();
}
}
}
You can have another implementation called pluginTwo, instantiate it, add it to the list and call the methods specified by the interface on it.

Is this consider polymorphism?

I'm confused with polymorphism and I'm wondering if this is consider polymorphism?
I feel it looks kind of weird but it still compiles correctly.
public class Family {
void FamilyInfo() {
System.out.println("This is a family super class");
}
}
public class Grandparents extends Family {
void FamilyInfo() {
System.out.println("Graparents are the elders in the family and they are the sub class of family");
}
}
public class Parents extends Grandparents {
void FamilyInfo() {
System.out.println("The parents are the children of the grandparents and they are the sub sub class for family");
}
}
public class FamilyDemo {
public static void main(String ary[]) {
Grandparents Gp = new Grandparents();
Parents P1 = new Parents();
Gp.FamilyInfo();
P1.FamilyInfo();
}
}

Your method FamilyInfo is being overridden in all three classes in the hierarchy. This is one example of polymorphism.
When you call Gp.FamilyInfo();: It will call the method implemented in Grandparents class and print Graparents are the elders in the family and they are the sub class of family while P1.FamilyInfo(); will call the method in Parents class and print The parents are the children of the grandparents and they are the sub sub class for family.
Thus you can see that same method FamilyInfo() has two different behaviors, which is polymorphic behavior.
Your example is very similar to one mentioned in the tutorial here: Java Tutorial : Polymorphism. So don't get confused.

The example does not demonstrate polymorphism,rather i can just see simple object oriented inheritance.In order that the concept of polymorphism be used the code should be the following.
public class FamilyDemo
{
public static void main(String ary[])
{
Family Gp = new Grandparents();
Family P1 = new Parents();
Gp.FamilyInfo();
P1.FamilyInfo();
}
}
Even though Gp is of type Family, it behaves like type Grandparents because it is initialized with an object of that type.
Then,the following may be expected:
Graparents are the elders in the family and they are the sub class of family.
The parents are the children of the grandparents and they are the sub sub class for family.

Our trainer said that using extends is more of an example of inheritance. But if we use implements(interface), we can say that it is polymorphic because we can implement many interfaces.
e.g.
interface Horse {
void run();
}
interface Eagle {
void fly();
}
public class Pegasus implements Horse, Eagle {
// Implement methods
public void run() {
// do run
}
public void fly() {
// do fly
}
}

The dictionary definition of polymorphism refers to a principle in
biology in which an organism or species can have many different forms
or stages
The basic concept is for a given object to act like another. This is achieved through the use of interfaces and inheritance in Java.
A better example of this would be (with you code as a base)
public class FamilyDemo {
public static void main(String ary[]) {
Family gp = new Grandparents();
Family p1 = new Parents();
dump(gp);
dump(p1);
}
public static void dump(Family family) {
family.FamilyInfo();
}
}
This basically allows Gradparents and Parents to "act" as they are Family

1.What is polymorphism?
In object-oriented programming, polymorphism (from the Greek meaning "having multiple forms") is the characteristic of being able to assign a different meaning or usage to something in different contexts - specifically, to allow an entity such as a variable, a function, or an object to have more than one form.
2. Two Types of polymorphism
a) Static or Compile time Polymorphism
Which method is to be called is decided at compile-time only. Method overloading is an example of this.for example
public class calculation
{
public int add(int x, int y)
{
return x + y;
}
public int add(int x, int y, int z)
{
return x + y + z;
}
}
here you can see there are two functions with the same name but different signatures
b)Dynamic or Runtime Polymorphism.
Run time polymorphism is also known as method overriding. In this mechanism by which a call to an overridden function is resolved at a Run-Time (not at Compile-time) if a base Class contains a method that is overridden.
Class BaseClass
{
Public void show ()
{
Console.WriteLine("From base class show method");
}
}
Public Class DynamicDemo : BaseClass
{
Public void show()
{
Console.WriteLine("From Derived Class show method");
}
Public static void main(String args[])
{
DynamicDemo dpd=new DynamicDemo ();
Dpd.show();
}
}

Technically speaking, this is polymorphism. However, you have chosen a poor example and it seems like you are not quite understanding the idea behind polymorphism. A better example would be something like this.
public abstract class Shape {
public abstract void drawShape();
}
public class Rectangle extends Shape {
public void drawShape() {
// code for drawing rectangle
}
}
public class Circle extends Shape {
public void drawShape() {
// code for drawing circle
}
}
public class FilledRectangle extends Rectangle {
public void drawShape() {
super.drawShape();
// code for filling rectangle
}
}
Then a class that is responsible for the drawing doesn't need to know how to draw each individual shape. Instead, it can do this
public void drawAllShapes(Shape[] myShapes) {
for (int i = 0; i < myShapes.length; ++i) {
myShapes[i].drawShape();
}
}
The goal is to abstract away the concrete implementation and all the details that go with and instead only present a common interface. This makes it a lot easier to work with different classes, as you can see in the last method above.

A good example for polymorphism would be:
public static void print(Family[] family){
for(int i=0; i< family.length; i++){
family[i].FamilyInfo();
}
}
public static void main(String args[])
{
Family[] family = new Family[2];
Grandparents Gp = new Grandparents();
Parents P1 = new Parents();
family[0] = Gp;
family[1] = P1;
//and then send the array to another method which
//doesn't "know" which entry in the array is a parent and which is grandparent
//and there you can loop the array calling family[i].FamilyInfo();
//THIS is the whole idea of polymorphism in a nutshell
print(family);
}

Yes, in your example program you are using inherit and polimorphism, infact both are closed related.
You are using inherit because you extend once Family from Grandparents class, and once Parents class extending Grandparents and you are also using polimorphism because you are writing in your subclasses a method void FamilyInfo which is written in the super class.
You should use #Override in this way:
public class Parents extends Grandparents {
#Override
void FamilyInfo() {
System.out.println("The parents are the children of the grandparents and they are the sub sub class for family");
}
}

Why do we start Visitor by calling Acceptor.accept(), and not Visitor.visit()?

In Wikipedia sample and in GoF book, usage of Visitor pattern is started by calling accept method on some acceptor. But why is it this way? Why can't we start calling visit method with desired acceptor as an argument? We can still make visitor behavior depend on 2 types -- of visitor and of acceptor (double dispatch) -- and we can eliminate redundant call (as it seems to me).
Here's sample code to illustrate this:
public interface Visitor {
void visit(AcceptorA acceptor);
void visit(AcceptorB acceptor);
}
//
// Visitor which sings
//
class SingingVisitor implements Visitor {
public void visit(AcceptorA acceptor) {
System.out.println("sing A");
}
public void visit(AcceptorB acceptor) {
System.out.println("sing B");
}
}
//
// Visitor which talks
//
class TalkingVisitor implements Visitor {
public void visit(AcceptorA acceptor) {
System.out.println("talk A");
}
public void visit(AcceptorB acceptor) {
System.out.println("talk B");
}
}
//
// Acceptor subclasses
//
class AcceptorA implements BaseAcceptor {
}
class AcceptorB implements BaseAcceptor {
}
//
// Launcher class
//
class VisitorMain {
public static void main(String[] args) {
Visitor v = new TalkingVisitor();
AcceptorA a = new AcceptorA();
AcceptorB b = new AcceptorB();
v.visit(a);
v.visit(b);
v = new SingingVisitor();
v.visit(a);
v.visit(b);
}
}

Consider:
class House implements HouseAcceptor {
HouseAcceptor kitchen;
HouseAcceptor livingRoom;
void accept(HouseVisitor visitor) {
visitor.visit(this);
kitchen.accept(visitor);
livingRoom.accept(visitor);
}
}
class Kitchen implements HouseAcceptor {
void accept(HouseVisitor visitor) {
visitor.visit(this);
}
}
class LivingRoom implements HouseAcceptor {
void accept(HouseVisitor visitor) {
visitor.visit(this);
}
}
class SpeakingHouseVisitor implements HouseVisitor {
void visit(HouseAcceptor acceptor) {
System.out.println("Inside a HouseAcceptor");
}
void visit(House acceptor) {
System.out.println("Inside a House");
}
void visit(Kitchen acceptor) {
System.out.println("Inside a Kitchen");
}
void visit(LivingRoom acceptor) {
System.out.println("Inside a LivingRoom");
}
}
...
HouseAcceptor acceptor = new House();
HouseVisitor visitor = new SpeakingHouseVisitor();
...
// Doing it your way
visitor.visit(acceptor);
// Output: Inside a HouseAcceptor
// Doing it the right way
acceptor.accept(visitor);
// Output:
// Inside a House
// Inside a Kitchen
// Inside a LivingRoom
Note that if you do it your way, the runtime type of your acceptor will not make a difference: the static type will be used. By doing double dispatch you ensure that both runtime types are used.

Using your version, the following will not compile:
List<BaseAcceptor> list = ...
for(BaseAcceptor ba: list)
vi.visit(ba)
The java compiler cannot determine (statically) what ba will be, so it cannot decide at compile time which visit method to call. You would need to write an additional method:
public void visit(BaseAcceptor ba){
if(ba instanceof AcceptorA)
visit((AcceptorA)ba);
else if(ba instanceof AcceptorB)
visit((AcceptorB)ba);
}
This is not necessary using the visitor pattern.

Because Visitors have no knowledge of how to navigate the private internal fields of a composed Object.
If you called Visitor.visit(something) then it would have to figure out if that something had private fields which needed transversal. To do that, you need that something to accept your Visitor. Once you decide that navigation must be in the visited objects (and not the Visitor), then you realize that you need a call back to the Visitor to tell it what the next element in the navigation path is. Typically that's the accept(...) method; however, if you attempted to make accept(...) just a wrapper to initiate navigation (by delegation to the parameter), then you need a second set of methods to tell the Visitor you're entering X now, your entering Y now.
By using the GOF approach, one can safely subclass an item being visited and modify the visiting path to include or skip additional fields. This would not impact the existing Visitors because their interface would not change. One wouldn't need to recompile subclasses of the Visitor either.
By using your suggested approach, when one added a new type into the hierarchy of to-be-visited items, one would then need to recompile all the visitors, even the visitors had no interest in the new type.
A good compromise would be:
public interface Visitable {
public void accept(Visitor v);
}
were all your "data hierarchy" implements Visitable, and your Visitor has a "convenience method" like so
public abstract class Visitor {
public void initiate(Visitable v) {
v.accept(this);
}
public abstract void accept(...);
public abstract void accept(...);
public abstract void accept(...);
}
But it's up to you if having an interface is preferable to such a base class. To me I'd favor the more loosely coupled interface, but opinions differ.

you have no double dispatch. accept usually takes an abstract visitor as an argument.