File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Good programming practice or.... BAD programming pracitce Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Good programming practice or.... BAD programming pracitce" Watch "Good programming practice or.... BAD programming pracitce" New topic
Author

Good programming practice or.... BAD programming pracitce

Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
I have a number of classses. I do NOT want these classes to have to have ANY thing in common except that I want them to be able to be recognized together. I was thinking a completely empty interface that they all implement, thus allowing
if(object instanceof Thing){
danceAJig();
}
however, i am wary of making an empty interface.
GOOD programming practice... or... BAD programming practice?


I've heard it takes forever to grow a woman from the ground
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8813
    
    5
Can you say more about why you have this design intent? There are 'marker' interfaces in the API, is this what you have in mind?


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Hiep Nguyen
Ranch Hand

Joined: Oct 26, 2001
Posts: 46
i don't understand clearly about your question and what do you want. But when you declare a class without exten any class, it mean that you extended the Object class, so your classes can know together.
Sorry if i wrogth
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
Well, the more I explain, the less it fits in beginner, but here goes.
I have Class Peon in GameWorld, and I have Class Peon in EditorWorld. Both 'worlds' extend Abstract Class World. Then, I have a singleton class (sigh... this really isn't begginner anymore...) GameCodes which has a final PEON. When i call GameCodes.getCode(Object obj) with either kind of Peon, I want to return PEON. Thus, my plan for implementing this idea was to put in World the interface AbstractPeon, with no methods or nuthin', just so i can say if(obj instanceof AbstractPeon)return PEON;
dig?

actually, another solution might be to (Peons implement Thing) have a method getCode() in Thing, and just use that to return the code... but none the less...
Good programming practice, or... Bad programming practice?
KR Campbell
Ranch Hand

Joined: Mar 26, 2004
Posts: 124
I would have thought this was bad practice. Referring to Joshua Bloch's very wonderful 'Effective Java', item 10 discusses the Cloneable interface which serves as a marker interface. He writes that the general purpose of an interface is that it should, "say something about what a class can do for its clients." He also says that, "this should not be emulated" but I'm not too clear on whether he is referring to the actual way that clone() operates or the use of marker interfaces.
My personal question would be, surely your various peons must have something in common?

perhaps? Or have peons changed recently?

Regards,
Kenny
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
well, you see, Peons in EditorWorld don't payTaxes, they just sit there and get saved. I have plenty of interfaces to describe each individual Peon, for example Peon in GameWorld exends SelectableThing, and implements Drawable, Advanceable. But if i make it also implement AbstractPeon, it will have some connection, however spurious, to Peon in EditorWorld.
sever oon
Ranch Hand

Joined: Feb 08, 2004
Posts: 268
When a class implements an interface, that is a statement about what that class is. In some cases, you need to be able to deal with classes of that certain type polymorphically even though you don't require any specific behavior of them...this is where the tagging interface comes in. It allows you to recognize a class as a member of a group when there is no behavior associated with that group that distinguishes it from other classes.
Cloneable, IMHO, was a mistake in the JDK. It is definitely NOT a case where there is no behavior associated with that interface. I would argue that the clone() method should be in that interface, and it was for purely practical reasons they went another way on this. From a pure OO theory standpoint, Cloneable is not elegant. Nor is Serializable, because I could envision a system where serializable objects implement a serialize() method that returns an array of bytes or something, so it too is tied up with some functionality that the class itself could provide.
There are situations, though, where you must use an interface to specify that something can be done to a class, but the operation cannot be performed by the class itself. In this case you could use a tagging interface to specify that this class can have this thing done to it. An example might make this easier to understand.
You're writing a system where any two objects might need to communicate, but you know you're going to have 100s of instances roaming around and you don't want each instance to hold a reference to every other instance so it can perform the communication. So you write one singleton object that keeps all the references to all the instances, and when any object needs to communicate with any other, it tells the singleton, and the singleton forwards the message to the appropriate destination object. In this case, you might want to restrict which objects can work with the singleton, so you have their classes implement a tagging interface and pass a this reference into the singleton as the source of the information. The singleton nor the destination object don't really need to call any method on the source object, you just want to ensure that only objects that meet the contract of that tagging interface can use it.
This is the interesting part about tagging interfaces. You can put any contract you want in the documentation, and by implementing that tagging interface, even though the no functionality is required of the implementing class, by implementing that interface it's still agreeing to abide by its contract which can be specified in documentation. So it's still useful.
For your particular situation, I think you might be using inheritance incorrectly. Most of the time, implementing an interface or extending a class means that you are writing a class that abides by a more restrictive contract that the interface or superclass. You have a Peon interface that it doesn't seem has any particular contract associated with it, begging the question: why have it? I'd have to learn more about your game to be able to say what the proper design would be, but this doesn't sound like it to me.
sev
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
Extremely helpful... You have answered GOOD programming practice. The situation you described where 'tagging interfaces' (SPLENDID nomenclature) are applicaple is precisely what is going on in my program. Two objects, (two Panels in this instance), a singleton... exactly as you described. Much Thanks!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Good programming practice or.... BAD programming pracitce