[java] What is the point of interfaces?

Started by
32 comments, last by fadilthrejk 20 years, 2 months ago
I am in AP Computer Science, and in there is a marine biology simulation we have to familiarize ourselves with for the AP exam. I was looking through my book, reading about interfaces, and realized "why use them?" They seem to be just a way of further organizing things. here is an example, straight from the book:

//Represents the interface for an object that can be assigned an explicit complexity

public interface Complexity
{
    public void setComplexity (int complexity);
    public int get Complexity();
}
Now, here is the class that uses these methods:

public class Question implements Complexity
{
    private String question, answer;
    private int complexityLevel;
    
    //Sets up the question with a default complexity 

    //(the constructor, I know)

    public Question (String query, String result)
    {
        question = query;
        answer = result;
        complexityLevel = 1;
    }

    //sets the complexity level for this question

    public void setComplexity (int level)
    {
        complexityLevel = level;
    }

    //Returns complexity

    public int getComplexity()
    {
        return complexityLevel;
    }
It goes on after that, but this is the implementation of the interface. What is the point of having an little blueprint for the methods if you put all the code and crap in the actual class anyway? Am I missing something? Is there some hidden use that I haven''t learned yet?
Advertisement
Interfaces are exactly that - a list of required functionality. Any example with only one use of an interface is always going to look a little odd.

Eg: I want to hold a group of objects, variable in size. I could use an ArrayList and just add and subtract things at will. But I might later find that the usage means that an ArrayList is a pretty bad choice, and instead I''d prefer a LinkedList. If I was to code the usage using the List interface, all I''d have to do is change the actual creation. Everywhere just deals with a generic List, and doesn''t have to worry about what it actually is.
I'm not following...can you give me an example?

EDIT:
Like, some code or something, real simple so I'll get it.

[edited by - fadilthrejk on February 2, 2004 2:40:10 PM]
Look up interfaces in the JDK such as EventListener and you''ll understand. Interfaces are not to make the programmer''s life easier, but to guarantee to some other block of code that a particular class has certain capabilities, and can be used in a certain way.

"Sneftel is correct, if rather vulgar." --Flarelocke
As a concrete example, I wrote a ray tracer a while back that used an interface for the objects. The interface contained several methods, but for examples sake, lets just say it contained a ''render'' function.
Now I know that any object that I write will contain a render function and I can call that (from the ray tracer). Now anyone else that wanted to create their own object could easily do that by implimenting my interface and writing their own render function. My ray tracer doesn''t need to know about their custom NURBS object, just that it impliments my object interface (which contains a render method that the tracer can call).

Hope that explains things a little bit,
Mat
To expand on OrangyTang''s description, they''re meant to abstract the interface from the actual code. For example, you could have several different shapes, circles, triangles, squares, etc. Then you can create an "Drawable" interface and give it to each of them. The each of them is forced to implement the drawable interface so you know that if you''ve got a shape in will be drawable, regardless of it''s kind. However, you create another interface called "Stackable". Only squares and rectangles are Stackable. So then you can create two lists, one which has all shapes which are Drawable, and one which has only Stackable shapes, yet the same object can be one of each. It gets better the more different interfaces you want to add. It may seem a little silly in this example, but hopefully you understand the idea. Sometime you''ll come across a situation and you''ll say, "Oh, this is when interfaces are helpful."

tj963
tj963
class intf{private:	int* val;public:	int* getval(){return val;}	const int* getvalC_(){return val;}	int* const getval_C(){return val;}	const int* const getvalC_C(){return val;}};int main(int argc, char* argv[]){	intf i;	int* a = i.getval();	const int* b = i.getvalC_();	int* const c = i.getval_C();	const int* const d = i.getvalC_C();	a = new int(5);	*a = 5;	b = new int(5);	*b = 5; // bad	c = new int(5); // bad	*c = 5;	d = new int(5); // bad	*d = 5; // bad	return 0;}


this shows what you can get out of restriciting access to values in a class using ''const''. The class can do what it likes to the value.
Consider the interface:

class Renderable {
public:
virtual void render() const = 0;
};

Now consider the following two classes derived from Renderable:

class Sphere: public Renderable {
public:
// Renders a sphere
virtual void render() const;
};

class Box: public Renderable {
public:
// Renders a box
virtual void render() const;
};


Now declare a std::vector that holds all the renderable
objects in our app:

std::vector< Renderable* > renderableObjects;

We can now render the objects in the vector whether
they are spheres, boxes or some other shape by just calling
the render function like so:

int i = 0;
renderableObjects->render();

Hope that helps.






Mind you if a user really wants to use your code in a totally different way he will manage as const_cast can be used to shed the ''const'' setting. Then again this kind of user will also use memcpy to paste over the private and protected members in a class.
but that''s in c++...and uses...ugh...pointers...
This is the eventListener interface:
/* * @(#)EventListener.java	1.12 03/01/23 * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */package java.util;/** * A tagging interface that all event listener interfaces must extend. * @since JDK1.1 */public interface EventListener {}

wtf? i guess I''ll figure it out.

This topic is closed to new replies.

Advertisement