How do I use an Interface for this?

Hi all, if someone could explain the logic behind this I'd appreciate it.:)

I have to construct a UML to model a "World Builder" for a basic adventure game.

The model I have so far has entities/classes: World, Site, Player, Item, GridReference, ExitPoint etc....

Each class forms a relationship with other classes in the system/model. To unify the classes I have created a class "WorldBuilderEngine" which brings all "high-level" operations into one area to ease the development of a GUI, which I will do at a later date. The problem specs also state:

"Note that it is advisable to expose the system functionality via an interface, therefore you should also provide a facade interface e.g. WorldBuilderModel. Your WorldBuilderEngine class can then implement this interface."

From this I gather that the code will look something like this:

-----
public interface WorldBuilderModel {
public void addSite(...) throws StructuralException;
...
// other required methods
...
}


-----
public class WorldBuilderEngine implements WorldBuilderModel {
public void addSite(...) throws StructuralException
{
...
}
...
// implement other methods exposed in the WorldBuilderModel interface
...
}


But what I don't understand is how is using an interface going prevent system exposure?

If the interface is esentially a copy of the class that implements it, how will that be usable as the means to access the system?

My understanding of an interface, is that it provides functionallity for classes that are otherwise not related so that certain operations can be used in a polymorphic manner. This is because java does not allow multiple inheriatnce.

I have many classes that are all used in some manner to give the required output and provide the desired functionallity. These operationis are all combined into the "WorldBuilderEngine"

If someone could explain to me how I am supposed to do this using the WorldBuilderModel interface I would be greatfull.

For the first part of thid problem I am only required to Model the system using UML, so if someone is able to help, could you please take that into consideration when explaining it to me.:)

You can have other methods in WorkerBuilderEngine that aren't specified in the interface. These internal methods can hide all the actual implementation details and won't be visible externally.

Quote:

---

Originally Posted by OrangeDog

You can have other methods in WorkerBuilderEngine that aren't specified in the interface. These internal methods can hide all the actual implementation details and won't be visible externally.

---

True, but this is still possible with just classes.
For example...

Code:

---

public int addSubtractAlternator(int[] compute){
    int ret;
    boolean add = true;
    for(int i : compute){
          if(add)
              ret=add(ret,i);
          else ret = subtract(ret,i);
          swapBoolean(add);
    }
}
private int add(int val1, int val2){
    return val1+val2;
}
private int subtract(int val1, int val2){
    return val1-val2;
}
private boolean swapBoolean(boolean b){
    if(b)
          return false;
    return true;
}

---

It's inefficient, but the basic idea is there... implementation can still be hidden from classes that use the class (the code is directed more at OD than anything else...)

With an interface, you KNOW without looking that if a class implements the interface, it has the methods specified by the interface, even if you don't know exactly what they do. Therefore if another developer wanted to make calls to the WorldBuilderEngine class when it did not implement the WorldBuilderModel interface, he/she would have to look up the methods used to perform actions with the Engine. However, if the Engine implements the Model, he/she already knows what methods do what. I would almost say name the interface BuilderModel and use it with other classes that create objects, but that is up to you.

In short, interfaces are useful for when multiple developers must use each others classes/interfaces, but are almost a waste if they are only implemented by one class. If they are only implemented by the class, the class itself should declare the methods.

Thanks Singing boyo, everything you've said makes perfect sense to me. What I'm still having trouble grasping is HOW will developers use the interface?

Since you can't create an instance of the interface, how will it be used?

Am I correct like this: A developer will create a new class for example "Build", he/she will then make calls to my system via the interface, such as:

BuilderModel.createSite();
BuilderModel.addItemToSite(newItem);

How is this possible when you can't make objects of the interface?

You mentioned that you would use the BuilderModel with other classes that create objects, how is this possible? If other classes implement the interface, don't they too have to show all of the methods of the interface? This doesn't really make sense for the other classes in my model, as the only class that would have all the methods of the interface(and more) is WorldBuilderEngine

The way I have my system set up everything is contained in a "World" object. The WorldBuilderEngine provides all of the high level operations such as createSite(), deleteSite(), addItemToPlayer(), removeItem(), addExitToSite(), removeExitFromSite(), etc..........

If the WorldBuilderModel implements the interface, how will developer use it?

I really don't understand why/how I use the interface in this scenario, but the design specs say we MUST used an interface to protect all high-level operation.

Hope that makes more sense, thanks for your help;)

I thought that maybe if you can see my model it would make more sense, so I've attached it here>

Thanks again.

I had to zip it as the file size for a pdf was too large for the forum:)

One example is the Java Sound API, where the developer only works with interfaces for hardware objects (SourceDataLine, Mixer), or when you define methods that take Collections as arguments, e.g. when you ask for any kind of Map or List.

An interface really doesn't seem useful to me in this case... interfaces allow developers knowledge as to what methods are provided by the classes implementing the interface. Because the interface is only used once in your program, it seems unnecessary. Then again, I've never tried using interfaces for security reasons.

Essentially, interfaces are just like abstract classes that define only abstract methods and static final variables, with the exception of inheritance with interfaces. Because they provide no implementations, they are useless unless you need lists of objects for specific methods. (The xxxListener interfaces are examples of situations where a list of objects is needed for certain methods only)

I believe OrangeDog knows more about the security possibilities of interfaces than I do, so I will leave that topic untouched.

I'm flattered by the assumption, but I don't see any real security benefit.

One other advantage to using an interface is that you can switch out different classes that implement it without having to re-factor major portions of code. For example, you could change your WorldBuilderEngine for a ThreadedWorldBuilderEngine in the future with minimal fuss.

And then again, maybe he doesn't, or there just is no benefit

Quote:

---

Originally Posted by OrangeDog

For example, you could change your WorldBuilderEngine for a ThreadedWorldBuilderEngine in the future with minimal fuss.

---

I'm not sure how it would be any more difficult without the interface... I can just as easily create private(or public) classes that extend thread to perform desired functions without an interface as I can with one.

@OP: I have serious issues with whoever told you to use an interface for something like this. It is a waste of time in general. The only possible use I could see would be something like a WorldObjectCreator interface that used generics and contained methods related to the construction of the objects/people in your virtual world to be implemented by the classes responsible for constructing the objects/people.

Using an interface gives you more flexibility, as you're not tied to a single sub-classing opportunity. Generally best not to restrict yourself unnecessarily when developing software. Thus an Interface is preferred over an Abstract Class.

Remember this is actually a question about UML, not Java, so Java-specific ways of doing object-oriented coding may not apply.

Quote:

---

Originally Posted by OrangeDog

Remember this is actually a question about UML, not Java, so Java-specific ways of doing object-oriented coding may not apply.

---

I'd agree, but he DID post on a JAVA forum, so he probably wants a java-related answer. Also, some of his methods return Lists that use generics, so it probably is Java-based.

OD is right, it does give more flexibility. Say you wanted to subclass a class called Engine. If your interface was an abstract class, it wouldn't work. But because the methods could just as easily be defined in the WorldBuilderEngine, it doesn't really matter all that much.

I still don't really see the advantage of an interface in this situation.

Any idea why the specs say to use an interface? (Or just post what they say about using interfaces in general)

Quote:

---

Originally Posted by OrangeDog

I'm flattered by the assumption, but I don't see any real security benefit.

One other advantage to using an interface is that you can switch out different classes that implement it without having to re-factor major portions of code. For example, you could change your WorldBuilderEngine for a ThreadedWorldBuilderEngine in the future with minimal fuss.

---

I was going to bring up this as a reason to possibly use an interface. Having mucked about with world builder stuff myself, having an interface really does help in that it allows you to easily drop in variants of your world building code if you're not entirely sure of, say, the algorithms you want to use. So you could have 3 world builder classes, any of which could be chosen to build your world based either on come start up property, or possibly user selection in game...in addition this also allows you to drop in new versions later in development should you come up with a better idea of how to do things, with the minimum of fuss.

That and really it's good coding practice to code against interfaces rather than solid classes, because all the above applies to almost any class.

As for the OPs question about how you instantiate them, you generally have a factory that does that.

I believe Toll's may have it. It's not necessary, but if you're unsure of exact implementation, using an interface is better...

BTW, what are you using to create the UML diagrams? I've been looking for a good tool for a while and I can't seem to find one.

Quote:

---

Originally Posted by Singing Boyo

I believe Toll's may have it. It's not necessary, but if you're unsure of exact implementation, using an interface is better...

---

To be honest, that applies to pretty much all coding involving more than one person. Which is why it's generally considered best practice to code against interfaces rather than defined classes.

Quote:

---

Originally Posted by Tolls

To be honest, that applies to pretty much all coding involving more than one person.

---

Or all coding that's ever got a chance of being changed in the future.