"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:So, here's my question: when a method might return a new instance of some class, but might also return objects that are to be interpreted specially (such as those that represent cancelation of the transaction, or those that indicate the method never allows cancelation), is it safer to have those unique objects created at run time by "new Object()" as opposed to creating them at compile time, the way it is done in JOptionPane?
Jeff Verdegan wrote:First, all objects are created at runtime. None at compile-time.
For your case, it sounds like either
or
would be fine. But note that since it's a static variable, only one will ever be created anyway.
"Il y a peu de choses qui me soient impossibles..."
Mike Simmons wrote:However, I would recommend something else - don't return an Object, but instead a Parameter instance which represents the concept of an uninitialized parameter. This instance could also have a toString() method that returns a meaningful string, e.g. "Parameter[uninitialized]" or something. This is more type-safe and useful in debugging, especially for someone not familiar with the internal implementation of your Parameter class. If they just see an Object, they have no idea what that means. If they see Parameter[uninitialized], they have a much better chance at understanding what's going on.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:Perhaps I am misunderstanding your point, but I don't think that addresses the dilemma I'm asking about. The issue I see is that (however unlikely this may be), a user's override method for getParameters() might return "this is my dummy 'no parameters' object", with the intent that this actually be the parameters returned, rather than an indication that no parameters are returned by this method
Stevens Miller wrote:es me for using the String constructor, but I don't see any other way to be sure I have a unique object reference to a String.
Jeff Verdegan wrote:Okay, I see what you're getting at now. Then, yes, if you want to ensure a unique object that can never be == to or equals() to any other object (unless somebody deliberately defines and incorrect equals() method), then new Object(), or some instance of your own class or enum is the way to go.
Is Parameter your class or part of the core API? If yours, you can make a special instance that's never equal to any other instance. If it's part of the core API, you'd have to look at its rules for equals().
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:That's what got me into looking at the JOptionPane source. I figured that would be a good example to follow. But, I was really expecting to see "new Object()" in there (or something like it). When I saw the hard-coded String, some dusty neuron fired and reminded me that Java tries not to create distinct String objects.
Mike Simmons wrote:However I'd still prefer to see a separate Parameter value returned.
Jeff Verdegan wrote:Or one could define a subclass of Parameter, possibly anonymous, that is only ever instantiated once, and that is never equal to any other Parameter.
Jeff Verdegan wrote:There are multiple options, and which one is most suitable depends on the constraints of the specific situation.
Mike Simmons wrote:
Jeff Verdegan wrote:Or one could define a subclass of Parameter, possibly anonymous, that is only ever instantiated once, and that is never equal to any other Parameter.
Kind of like, say, the one I just showed.![]()
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:I don't think the null object pattern is warranted in this case, as the only objects that should pass on to code that would need it are those that do not equate to "no parameters."
,Further, though unlikely, I may actually need to pass a bona fide null object
Jeff Verdegan wrote:
Stevens Miller wrote:I don't think the null object pattern is warranted in this case, as the only objects that should pass on to code that would need it are those that do not equate to "no parameters."
You wouldn't necessarily have to use it to represent null per se. It's just the general pattern of a special object meant to indicate a particular value outside the normal range of possible "real" values.
,Further, though unlikely, I may actually need to pass a bona fide null object
There is no such thing. Only references can be null in Java, not objects.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:Hmmm... I think we're using our terms differently from each other. I meant "null object" in the sense of the Wikipedia item linked to above. As I understood that item, a null object actually does implement the methods of a class, but none of them do anything.
Jeff Verdegan wrote:A very common mistake made by beginners, and even by people with a moderate amount of experience, is to think about objects being null--null in the sense of the Java language meaning of the word, like someObj = null. This misconception usually comes from not being aware of the distinctions among objects, references, and variables.
"Il y a peu de choses qui me soient impossibles..."
Consider Paul's rocket mass heater. |