This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Functional Reactive Programming and have Stephen Blackheath and Anthony Jones on-line!
See this thread for details.
Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Good programming practice or.... BAD programming pracitce

 
Nick George
Ranch Hand
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Bert Bates
author
Sheriff
Posts: 8900
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Hiep Nguyen
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 815
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic