[helpme18]

So there is a bunch of classes that inherit an abstract method called pay(), and the child classes have diffrent versions of the pay method. These classes inherit the pay method from the StaffMember class. My driver is the firm class and now i have to accomplish polymorphism using an interface called payable containing the pay(), i have to implement the interface before i can use pay().


Please explain how i am suppose to use an interface of the pay() if each class has a diffrent body of code for the pay(), please hint me into the direction i should take to accomplish this task.

[KYA]

The whole point of an interface is for classes to inherit certain methods and such, but they have to define it themselves. Interfaces can do many, many things, but they also simulate multiple inheritance.

Anyhoo, I digress:

public interface payable{
	int pay();
}

public class SomeClass implements payable{
   //overwrite pay() here
}

[EdwinNameless]

You use it this way:

Payable emp = new StaffMember();
Payable contractor = new Contractor();

emp.pay();
contractor.pay();

The interface ensures the pay method is present in the classes that implement in this interface.

[helpme18]

helpme18, on 20 Nov, 2009 - 09:18 AM, said:

So there is a bunch of classes that inherit an abstract method called pay(), and the child classes have diffrent versions of the pay method. These classes inherit the pay method from the StaffMember class. My driver is the firm class and now i have to accomplish polymorphism using an interface called payable containing the pay(), i have to implement the interface before i can use pay().


Please explain how i am suppose to use an interface of the pay() if each class has a diffrent body of code for the pay(), please hint me into the direction i should take to accomplish this task.

thanks so much but where should i put the body of code for the pay method that differ depending on the class?

[EdwinNameless]

helpme18, on 20 Nov, 2009 - 11:49 AM, said:

thanks so much but where should i put the body of code for the pay method that differ depending on the class?

In the implementing classes.

public class Employee implements Payable {
  public void pay() {
	System.out.println("pay employee");
  }
}

public class Contractor implements Payable {
  public void pay() {
	System.out.println("pay contractor");
  }
}

In this case,

Payable employee = new Employee();
employee.pay();
Payable contractor = new Contractor();
contractor.pay();

prints

pay employee
pay contractor

Does that make sense ?

[KYA]

Employee is not a payable, it implements payable. Why are you defining the object to be a Payable? This isn't C++.

Employee emp = new Employee();
//not Payable employee = new Employee();

[EdwinNameless]

KYA, on 20 Nov, 2009 - 01:05 PM, said:

Employee is not a payable, it implements payable. Why are you defining the object to be a Payable? This isn't C++.

Before dismissing valid *Java* code, I'd recommend actually trying to fire up a JVM:

// Payable.java
interface Payable {
	public void pay();
}

// Employee.java
public class Employee implements Payable {
	public void pay() {
	System.out.println("test");
	}

public static void main(String args[]) {
	Payable employee = new Employee();
	employee.pay();
}
}

That's actually the whole point of interfaces in Java, btw.

[KYA]

Sure it's valid, but it gives the notion that Employee is a Payable, i.e. a base class pointer that points to a derived class, which it is not.

I have never seen anyone define a java object like that before.

Employee emp = new Employee(); //this makes sense
emp.pay();
   	
Payable emp2 = new Employee(); //this doesn't
emp2.pay();

Payable pay = new Payable(); //and this won't work

Payable is not a class it is an interface.


Let's take an actual class inheritance example:

//interface
public interface Payable {
	public void pay();  
}

//base class
public class Employee implements Payable {
	public Employee() {}
	public void pay() {System.out.println("Employee pay");}
}

//derived class
public class Janitor extends Employee {
	public Janitor() {} 
	public void pay() {System.out.println("Janitor Pay");} //not necessary since it will take employee's pay() if this wasn't defined
}

//sample main
public static void main(String[] args){
	   Employee emp = new Employee(); //makes sense
	   emp.pay();
	   //payable is not an object
	   Payable emp2 = new Employee(); //makes no sense
	   emp2.pay();
	   //should be Janitor, but this is acceptable
	   Employee bob = new Janitor(); //acceptable
	   bob.pay();
}

edit: One of the best examples to use a base class definition that points to a derived class is when you need to dynamically store objects. The user may pick several, all of which derive from Employee (or Account, etc...) and you'd store them like so:

vector<Employee> roster;
//user picks janitor
Employee temp = new Janitor();
roster.add(temp);

Problem solved. You wouldn't have a vector of Payables as that would make zero sense.

This post has been edited by KYA: 20 November 2009 - 02:28 PM

[xclite]

I do that all of the time - for example, I have a loop that iterates over a command script for a project of mine - the parser returns some kind of Command - I have several classes that implement the Command interface, which enforces some kind of execute method. As a result, I can just do something like:

Command nextCommand = parser.nextCommand();
nextCommand.execute();

Nothing wrong with using a reference to the base class - that's actually encouraged and probably the basis of the particular assignment/problem this individual is working on. Sure, in the context of creating a single item within main, you would need a good reason to use the base rather than the derived, but the point of the assignment is probably to show what polymorphism can do.

If you're defining objects in the context that you need to return something that is Payable, declaring an object Payable and sticking in an Employee is fine, because Employee IS-A Payable object.

This post has been edited by xclite: 20 November 2009 - 05:09 PM

[KYA]

You guys need to revisit your OOP book. An interface is NOT a class. It cannot be an object because it cannot be instantiated on its own.


Specifically:

Quote

Object references in Java may be specified to be of an interface type; in which case they must either be null, or be bound to an object which implements the interface.

Which concurs that what you're doing is legal, but:

Quote

Interfaces are used to encode similarities which classes of various types share, but do not necessarily constitute a class relationship.

Again, its legal and you can do it, but there is no 'has a' or 'is a' relationship involved since it is an interface not a class or abstract class.


The best example I can find is from Sun's Java tutorial:

Quote

When you define a new interface, you are defining a new reference data type. You can use interface names anywhere you can use any other data type name. If you define a reference variable whose type is an interface, any object you assign to it must be an instance of a class that implements the interface.

It's a type, not an object.

Quote

An interface defines a protocol of communication between two objects.

An interface declaration contains signatures, but no implementations, for a set of methods, and might also contain constant definitions.

A class that implements an interface must implement all the methods declared in the interface.

An interface name can be used anywhere a type can be used.

True: An employee is payable.
False: An employee is a payable
False: An employee has a payable

This post has been edited by KYA: 20 November 2009 - 05:20 PM

[xclite]

Sorry, but Employee is a Payable. Just because you can't instantiate a class doesn't mean that it cannot be part of an IS-A relationship.

I especially like this:

Quote

Again, its legal and you can do it, but there is no 'has a' or 'is a' relationship involved since it is an interface not a class or abstract class.

An interface is an abstract class. It's just a fully abstract class.

Quote

When you define a new interface, you are defining a new reference data type. You can use interface names anywhere you can use any other data type name. If you define a reference variable whose type is an interface, any object you assign to it must be an instance of a class that implements the interface.

Nothing in that entire quote says that it's bad practice to do so, in fact, it seems to imply that there are no problems with this.

Nobody is saying an interface is an object. It IS entirely acceptable to have interface references. You can take arguments of type Comparable, return arguments of type List, Map, Queue, etc etc.

As for OOP books, I just opened two separate books by two separate authors. The first discusses that Comparable establishes an IS-A relationship. Comparable is an interface.

The second states, and I quote:

Quote

Because an interface is an abstract class, all the rules of inheritance apply.
Specifically,

1) The IS-A relationship holds. If class C implements interface I, then C IS-A I and is type-compatible with I.

[japanir]

Quote

An interface is an abstract class. It's just a fully abstract class.

where did this come from?

Here is a nice tutorial i have written, with a whole section devoted to the differences between abstract class and an interface.
http://www.dreaminco...topic130490.htm

[KYA]

Quote

CAN-DO and IS-A relationship are a major difference between Interface and abstract classes

Quote

Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.

This post has been edited by KYA: 20 November 2009 - 06:21 PM

[xclite]

1) I fail to see how those quotes are any more or less credible than mine. The first directly contradicts both of my sources.
2) Any objects implementing the same interface can be otherwise unrelated and still have an IS-A relationship with the interface. An automobile is a recyclable, so is a tin can. They can both fulfill any role within a program where you require a recyclable object. They are both recyclable. Just because they are both not containers of food does not mean they can't share some inheritance. They are both made of a material that can be recycled, and actually are therefore related, anyway.

Finally, even if we somehow agree that an interface does or does not provide an IS-A relationship, that does nothing to establish nor demolish the viability/correctness of using an interface reference type. There is absolutely nothing wrong with an interface type in practice - I can think of nothing more elegant than being able to say "I'll take an item that can perform such-and-such an action" instead of having to say "I'll take an item that has as its abstract parent..."

Interestingly, I found posts while looking deeper into this that suggest not only an IS-A relationship, but a distinction between that and an IS-AN-OBJECT relationship. That would be a whole new can of worms.

[KYA]

If you read up, I never said what you guys were doing was illegal. In this particular context it makes no sense, payable is not a noun.

I can see where the confusion arises, especially is the interface name was a noun, i.e. Whistler. Humans and Parrots can both whistle. Therefore they are Whistlers. This still isn't a IS A relationship, even though in an English sentence it makes sense.

Java allows you to use the Interface name as a type, we've already beat the dead dog on that one.


IS A and IS AN OBJECT are not anywhere near the same thing. The former represents a principle in inheritance and object oriented programming, the latter is simply a state of being in OOP. You can have an object with an interface and still not have a IS A relationship.

Quote

In knowledge representation and object-oriented programming and design, is-a is a relationship where one class D is a subclass of another class B (and so B is a superclass of D).

In other words, "D is a B" usually means that concept D is a specialization of concept B, and concept B is a generalization of concept D. For instance, a "fruit" is a generalization of "apple", "orange", "mango" and many others. One can say that an apple is a fruit.

Employee inherits [purest definition of the word] nothing from payable. It has to implement all of its own versions of methods contained in the interface. Whereas, if payable was a superclass or even an abstract class, some functionality could be provided and ultimately inherited by Employee.

Fundamental difference:

public interface Payable {
	public void pay();  
}

//makes sense
public class Employee implements payable{
}

public abstract class Payable{
	//stuff
}

//makes no sense, what is a Payable? 
public class Employee extends Payable{
}

This post has been edited by KYA: 20 November 2009 - 06:42 PM