Re: cast to sub-class or extending instance of super or a.n.other
Richard Maher wrote:
Ok, cards on the table: - I have an instance of JSObject; I want to attach
an integer to it (oh, but we must know exactly what that integer does!)
Alright, it's a MinimumMessageNumber; any messages less than this will be
ignored. I want to reference the resultant object/structure by "index" for
performance. The ArrayList (I'm happy for alternatives and I'm looking at
your hashCode) will normally contain 1 element, and max-out at about10. The
minMsgNum is an appendage/baggage something that I'm sure there's a flash OO
term for like "orthogonal" that'll give everyone a boner (see, I've been
drinking :-)
This here strikes me as all kinds of wrongness. I'm not really sure
where the idea that a "property" must be added to an existing object
comes from. Given something like this, where JSObject is effectively a
global variable:
public class MyApplet extends JApplet {
private JSObject jso;
//...
}
I suppose the motivation might be to avoid more global variables.
However, that really doesn't make sense.
public class MyApplet extends JApplet {
private JSObject jso;
int minMessageNum;
Deque messageQueue;
//...
}
This works perfectly well.
In OO programming, there is the concept of "separation of concerns." In
other words, the JSObject is concerned only with accessing the browser
objects. It doesn't provide any other functionality because that would
just increase the cost of maintaining it. Likewise, the programmer who
uses a JSObject should avoid overloading a JSObject with a bunch of data
unrelated to the primary purpose of the JSObject. That data should go
in a separate object somewhere else.
Here's the Wikipedia article on Separation of Concerns.
<http://en.wikipedia.org/wiki/Separation_of_concerns>
I think Mike already hit the nail on the head when he said to create a
separate MessageObject, I'm just trying to show why it's a good idea and
why he's suggesting it.