Overclock.net banner

1 - 19 of 19 Posts

·
Registered
Joined
·
1,009 Posts
Discussion Starter #1
Hey I know this sounds bad and super noobish. For the life of me I can not understand where an interface line would go. Maybe to make things easier let me explain where I am. I am at the beginning stages of my learning. I am able to compile classes and that is about it. It is possible I am doing all of this completely wrong. When using the sample classes from oracles website I can compile those (just using the command javac) but beyond that I am stuck. My main question is:
Where do I put the text for my interface? Does it go into a .Java file? Do I compile it? If so how?
Any more information anyone can give me on this would be great. Thanks!!!
 

·
Premium Member
Joined
·
5,282 Posts
You can either put an interface into its own .java file or you can write a nested interface which is defined inside of another class or interface as below

Code:
Code:
public class SomeClass{
    public interface SomeInterface{
            public void someFunction();
    }
}
 

·
Registered
Joined
·
1,009 Posts
Discussion Starter #5
Quote:


Originally Posted by rabidgnome229
View Post

You can either put an interface into its own .java file or you can write a nested interface which is defined inside of another class or interface as below

Code:
Code:
public class SomeClass{
    public interface SomeInterface{
            public void someFunction();
    }
}
Now in doing this it seems I cannot have the same class name and interface name correct?
 

·
Registered
Joined
·
491 Posts
That is true, regardless if the interface and class are embedded within each other or in separate files. The name of the file should be the same name as the class. So, if you had a separate file for the class and a separate file for the interface, and you tried to name them the same, you'd end up with two files with the same name, which doesn't work.

If you tried it with the embedded class/interface, you'd get a duplicate class error.

EDIT: Hm, I seem to be confusing myself. What I said above applies to separate classes, but I am not sure how it applies to a class and an interface.
 

·
Registered
Joined
·
1,009 Posts
Discussion Starter #7
Got ya. Coming from Oracle's website maybe you could show me what is wrong.

Interface:

Code:
Code:
interface Bicycle {

       void changeCadence(int newValue);   // wheel revolutions per minute

       void changeGear(int newValue);

       void speedUp(int increment);

       void applyBrakes(int decrement);
}
Class:

Code:
Code:
public class Bicycle {

       int cadence = 0;
       int speed = 0;
       int gear = 1;

       void changeCadence(int newValue) {
            cadence = newValue;
       }

       void changeGear(int newValue) {
            gear = newValue;
       }

       void speedUp(int increment) {
            speed = speed + increment;   
       }

       void applyBrakes(int decrement) {
            speed = speed - decrement;
       }

       void printStates() {
            System.out.println("cadence:"+cadence+" speed:"+speed+" gear:"+gear);
       }
 

·
Registered
Joined
·
1,009 Posts
Discussion Starter #8
So what I did was this:

Code:
Code:
public class Bicycle {

       int cadence = 0;
       int speed = 0;
       int gear = 1;

       void changeCadence(int newValue) {
            cadence = newValue;
       }

       void changeGear(int newValue) {
            gear = newValue;
       }

       void speedUp(int increment) {
            speed = speed + increment;   
       }

       void applyBrakes(int decrement) {
            speed = speed - decrement;
       }

       void printStates() {
            System.out.println("cadence:"+cadence+" speed:"+speed+" gear:"+gear);
       }

interface Bicycle {

       void changeCadence(int newValue);   // wheel revolutions per minute

       void changeGear(int newValue);

       void speedUp(int increment);

       void applyBrakes(int decrement);
}

}
Which does not work.
 

·
Registered
Joined
·
491 Posts
http://download.oracle.com/javase/tu...interface.html

See if that helps.

I mostly code in C, little in Java (I actually have to use Java now for a class, so eventually I'll use it more), so I am not as familiar with these terms and syntax.

The class would look like this:

Code:
Code:
public class BicycleClass {

       int cadence = 0;
       int speed = 0;
       int gear = 1;

       public void changeCadence(int newValue) {
            cadence = newValue;
       }

       public void changeGear(int newValue) {
            gear = newValue;
       }

       public void speedUp(int increment) {
            speed = speed + increment;   
       }

       public void applyBrakes(int decrement) {
            speed = speed - decrement;
       }

       public void printStates() {
            System.out.println("cadence:"+cadence+" speed:"+speed+" gear:"+gear);
       }
}
And the interface would be:

Code:
Code:
interface Bicycle {

       void changeCadence(int newValue);   // wheel revolutions per minute

       void changeGear(int newValue);

       void speedUp(int increment);

       void applyBrakes(int decrement);
}
Where the interface is Bicycle.java and the class is BicycleClass.java

Or this is how it would look all in one file:

Code:
Code:
public class BicycleClass
{
interface Bicycle
{

       void changeCadence(int newValue);   // wheel revolutions per minute
       void changeGear(int newValue);
       void speedUp(int increment);
       void applyBrakes(int decrement);
}

       int cadence = 0;
       int speed = 0;
       int gear = 1;

       public void changeCadence(int newValue) {
            cadence = newValue;
       }

       public void changeGear(int newValue) {
            gear = newValue;
       }

       public void speedUp(int increment) {
            speed = speed + increment;   
       }

       public void applyBrakes(int decrement) {
            speed = speed - decrement;
       }

       public void printStates() {
            System.out.println("cadence:"+cadence+" speed:"+speed+" gear:"+gear);
       }
}
Those two examples should work (they compile but I haven't ran it).
 

·
Premium Member
Joined
·
5,282 Posts
Quote:


Originally Posted by GriZzlEnLS
View Post

Got ya. Coming from Oracle's website maybe you could show me what is wrong.

Interface:

Code:
Code:
interface Bicycle {

       void changeCadence(int newValue);   // wheel revolutions per minute

       void changeGear(int newValue);

       void speedUp(int increment);

       void applyBrakes(int decrement);
}
Class:

Code:
Code:
public class Bicycle {

       int cadence = 0;
       int speed = 0;
       int gear = 1;

       void changeCadence(int newValue) {
            cadence = newValue;
       }

       void changeGear(int newValue) {
            gear = newValue;
       }

       void speedUp(int increment) {
            speed = speed + increment;   
       }

       void applyBrakes(int decrement) {
            speed = speed - decrement;
       }

       void printStates() {
            System.out.println("cadence:"+cadence+" speed:"+speed+" gear:"+gear);
       }
You do not want to use an interface in this case, just have a bicycle class.

From your code it seems like you may be familiar with a C-like language, where you have one file to declare the functions and another to implement them. In java you do not have to do this - implementing the functions declares them as well. An interface is something different

Quote:


Originally Posted by Tomiger
View Post

http://download.oracle.com/javase/tu...interface.html

See if that helps.

I mostly code in C, little in Java (I actually have to use Java now for a class, so eventually I'll use it more), so I am not as familiar with these terms and syntax.

The class would look like this:

And the interface would be:

Where the interface is Bicycle.java and the class is BicycleClass.java

Or this is how it would look all in one file:

Those two examples should work (they compile but I haven't ran it).

No offense, but I think your responses in this thread are confusing more than helpful. The code you posted is not a proper usage of an interface (at the very least the BicycleClass needs to implement Bicycle). It appears that what I typed above about C-familiarity applies to you as well.
 

·
Registered
Joined
·
491 Posts
Yeah I realized I confused myself as well. But I took the time to read up on what to actually use an interface for and it makes more sense.

The interface includes a set of methods that are not necessarily specific to any particular object. For example, an interface that has method definitions for finding the area of a circle and finding the volume of a cube. A class that just so happens to need to calculate the area or volume of those two shapes could "use" the interface. Another class that is completely different from the other one could also need those methods.

Is that half right? Like you said, I program in C almost exclusively, so I just deal with header files and c-files, where the header file contains the definition of the functions I am implementing in the c-file.

So I guess in that sense, an interface is a more robust version of a header file?
 

·
Premium Member
Joined
·
5,282 Posts
Quote:

Originally Posted by Tomiger View Post
Yeah I realized I confused myself as well. But I took the time to read up on what to actually use an interface for and it makes more sense.

The interface includes a set of methods that are not necessarily specific to any particular object. For example, an interface that has method definitions for finding the area of a circle and finding the volume of a cube. A class that just so happens to need to calculate the area or volume of those two shapes could "use" the interface. Another class that is completely different from the other one could also need those methods.

Is that half right? Like you said, I program in C almost exclusively, so I just deal with header files and c-files, where the header file contains the definition of the functions I am implementing in the c-file.

So I guess in that sense, an interface is a more robust version of a header file?
No, header files have no analog in java. I can't think of any C feature that is comparable to java interfaces either.

Interfaces tend to be used for tasks that many different unrelated classes need to perform. Places where you want multiple classes to have the same function, but the classes are not related enough to derive them from a common subclass.

An example is the Serializable interface. Having a class implement Serializable indicates that an instance of said class can be packaged into a byte array, sent over a serial connection (such as over an internet connection), and unpackaged on the other side. Classes of every type may want this behavior, lists, Bicycles, Bitmaps, whatever. Many, many, unrelated classes. You can't have all of these classes inherit from a single base class since they're completely different, but you want to be able to treat all of them as a Serializable object. So you have them all implement the serializable interfcae. That way you can use all of these distinct classes with distinct inheritance hierarchies in the same way.
 

·
Premium Member
Joined
·
1,592 Posts
Quote:

Originally Posted by rabidgnome229 View Post
No, header files have no analog in java. I can't think of any C feature that is comparable to java interfaces either.

Interfaces tend to be used for tasks that many different unrelated classes need to perform. Places where you want multiple classes to have the same function, but the classes are not related enough to derive them from a common subclass.

An example is the Serializable interface. Having a class implement Serializable indicates that an instance of said class can be packaged into a byte array, sent over a serial connection (such as over an internet connection), and unpackaged on the other side. Classes of every type may want this behavior, lists, Bicycles, Bitmaps, whatever. Many, many, unrelated classes. You can't have all of these classes inherit from a single base class since they're completely different, but you want to be able to treat all of them as a Serializable object. So you have them all implement the serializable interfcae. That way you can use all of these distinct classes with distinct inheritance hierarchies in the same way.

To sum that up you have classes with a common task, but perform that task in very different manners.

A good example would be a file transfer client.

Say you have and interface FileTransferClient that has methods upload(String) and download(String)

Lets have two implementations, SFTP and FTP. So SFTP and FTP are both of type FileTransferClient and have methods upload(String) and download(String). The actual implementation of these two is completely different.

So say you have a factory class that takes in some parameter that is used to determine a site's file transfer protocol. You have the factory method return a type of FileTransferClient so that the call can get that type back and do something like fileTransferClient.upload(String). The actual implementation could be SFTP or FTP but the caller only cares that it is FileTransferClient.

The interface creates a sort of contract between each of its implementations so that the behavior is the same across all of them.
 

·
Premium Member
Joined
·
5,282 Posts
Quote:

Originally Posted by xtascox View Post
To sum that up you have classes with a common task, but perform that task in very different manners.

A good example would be a file transfer client.

Say you have and interface FileTransferClient that has methods upload(String) and download(String)

Lets have two implementations, SFTP and FTP. So SFTP and FTP are both of type FileTransferClient and have methods upload(String) and download(String). The actual implementation of these two is completely different.

So say you have a factory class that takes in some parameter that is used to determine a site's file transfer protocol. You have the factory method return a type of FileTransferClient so that the call can get that type back and do something like fileTransferClient.upload(String). The actual implementation could be SFTP or FTP but the caller only cares that it is FileTransferClient.

The interface creates a sort of contract between each of its implementations so that the behavior is the same across all of them.
Inheriting from an abstract class would be better suited to the situation that you describe than an interface. Interfaces are typically used for tasks that are not related to the class's core function, like having a Bicycle implement Serializable to be sent over a network. If you wanted both a Bicycle class and a Car class, each of which has a drive() function (which would be implemented very differently for each class), you would want to have both inherit from an abstract Vehicle class
 

·
Premium Member
Joined
·
1,592 Posts
Quote:

Originally Posted by rabidgnome229 View Post
Inheriting from an abstract class would be better suited to the situation that you describe than an interface. Interfaces are typically used for tasks that are not related to the class's core function, like having a Bicycle implement Serializable to be sent over a network. If you wanted both a Bicycle class and a Car class, each of which has a drive() function (which would be implemented very differently for each class), you would want to have both inherit from an abstract Vehicle class
Using serializable is not really a good example. If you look through javadocs of common libraries you will see that interfaces are used to create method contracts to its implementations. Take a look at Quartz's API http://www.quartz-scheduler.org/docs...8.1/index.html and in particular the "Scheduler" interface along with its implementations and please realize that these relate specifically to the core function. If that is not enough proof I will link you to dozens of other API's that I work with professionally as a Java developer every day.
 

·
Premium Member
Joined
·
5,282 Posts
Quote:

Originally Posted by xtascox View Post
Using serializable is not really a good example. If you look through javadocs of common libraries you will see that interfaces are used to create method contracts to its implementations. Take a look at Quartz's API http://www.quartz-scheduler.org/docs...8.1/index.html and in particular the "Scheduler" interface along with its implementations and please realize that these relate specifically to the core function. If that is not enough proof I will link you to dozens of other API's that I work with professionally as a Java developer every day.
These are not actual rules, just best practices. You certainly can use an interface instead of an abstract class, and many highly used and well supported API's do so. There is very little difference between the two. The main differences are that abstract classes can have non-final instance variables and provide default function implementations.

If you look at the interfaces defined in the Java Standard Library, though, you see that interfaces are used for non-core functions (such as Serializable and Comparable) or to allow for multiple inheritance (Collections, RandomAccess, DataOutput). It's their intended usage, there is nothing forcing you to use them in this way, though. Looking at the quartz scheduler API I have little doubt that Scheduler would be an abstract class were it a part of the java standard library. That doesn't mean it doesn't work as an interface
 

·
Premium Member
Joined
·
1,592 Posts
Quote:

Originally Posted by rabidgnome229 View Post
These are not actual rules, just best practices. You certainly can use an interface instead of an abstract class, and many highly used and well supported API's do so. There is very little difference between the two. The main differences are that abstract classes can have non-final instance variables and provide default function implementations.

If you look at the interfaces defined in the Java Standard Library, though, you see that interfaces are used for non-core functions (such as Serializable and Comparable) or to allow for multiple inheritance (Collections, RandomAccess, DataOutput). It's their intended usage, there is nothing forcing you to use them in this way, though. Looking at the quartz scheduler API I have little doubt that Scheduler would be an abstract class were it a part of the java standard library. That doesn't mean it doesn't work as an interface
It does come down to personal preference. I have never read anything that states what you have just said (I'm not saying you are making it up, just that I have never heard it). The only time I ever use an abstract base is in instances where I have code (generally private methods) that is common to multiple implementations of an interface.
 

·
Registered
Joined
·
2,577 Posts
Quote:

Originally Posted by rabidgnome229 View Post
You do not want to use an interface in this case, just have a bicycle class.

From your code it seems like you may be familiar with a C-like language, where you have one file to declare the functions and another to implement them. In java you do not have to do this - implementing the functions declares them as well. An interface is something different

No offense, but I think your responses in this thread are confusing more than helpful. The code you posted is not a proper usage of an interface (at the very least the BicycleClass needs to implement Bicycle). It appears that what I typed above about C-familiarity applies to you as well.
However, he is likely learning about class hierachy in Java, and thus he should create an Abstract Class that defines what it is to be a bike!
He can then extend the abstract class and create a base type BasicBicycle, then extend BasicBicycle to make a RacingBike or a BMXBike, etc.

However, if he wants to use the bike in some environment, perhaps there is an interface called Printable, that requires that the object has a getObjectCoords() method, so the GUI elements know where it is! Further, the class should probably implement Comparable.
 

·
Registered
Joined
·
134 Posts
Just throwing my two cents in for a bit of clarification. Interfaces are useful for what essentially boils down to duck-typing. The objects that implement the interface need not share any common ancestry. They simply offer operations with similar meaning. Deriving from a common base class imparts a much stronger relationship between classes than simply implementing the same interface.

To illustrate, all of the following loosely make sense to have IVehicle operations, but it would seem odd to have them all inherit from the same base.

Code:
Code:
interface IVehicle{

       void speedUp(int increment);

       void applyBrakes(int decrement);
}
class Bicycle : IVehicle{

       void speedUp(int increment){};

       void applyBrakes(int decrement){};
}
class Donkey : IVehicle{

       void speedUp(int increment){};

       void applyBrakes(int decrement){};
}
class Plane : IVehicle{

       void speedUp(int increment){};

       void applyBrakes(int decrement){};
}
To me inheritance imparts an "is a" relationship, while an interface simply means "can act as a ".
 
1 - 19 of 19 Posts
Top