On 1/28/11 3:14 PM, James Ring wrote:
Hey,
On Fri, Jan 28, 2011 at 3:00 PM, Stephen Williams<scient...@gmail.com> wrote:
True, you shouldn't synchronize on any object that A) you want to change and
B) can only be changed by being replaced by a newly constructed object. If
Integer, for instance, had a setter method, then it could still have been
used in this way. However, it seems to be immutable. I generally just
create something like the following to synchronize:
Just because an object is immutable doesn't mean that you shouldn't
necessarily synchronize on it.
The point of the suggested link, which is valid, is to make sure you aren't synchronizing on a variable when you are going to
replace the value of that variable by assignment. Since you are really synchronizing on what the object variable is referencing,
assigning to it later means that the objects involved before and after assignment are different objects. Therefore, the
synchronization is completely broken.
Object lockArg;
For example, Object lockArg = new Object() is immutable but is fine
for synchronization.
FYI java.util.concurrent has a much better suite of synchronization
utilities than the language primitives provide.
Absolutely, very cool features. But not always needed.
...
About returning tuples:
Returning more than one value from a method has two reasonable solutions
that seem minimal for their use cases: returning a tuple as a single value
or making one or more calls to a callback method. The simplest case is when
multiple values need to be returned. While callbacks have their place when
you need to trigger more operations incrementally, they are cumbersome as
you need to define a class and provide an implementation, although the
latter can be an anonymous implementation. Many have complained about the
lack in Java of pair<>, however with the object reference system, it is easy
to do this with arrays. If the types are all the same, like String[], this
is completely typesafe. Otherwise, you can use Object[]. You can also
define a return type class to fill, however that is cumbersome. In addition
to Object[], a TreeMap can be a good solution, especially when more than a
few parameters are needed and they might change over time.
Returning tuples indicates that you are missing some sort of
abstraction that should be introduced to represent the thing you are
returning. Defining a class and providing an implementation is way
less cumbersome than dealing with the bugs that crop up when you fail
to properly encapsulate your state. Returning a TreeMap is probably
bad for the same reason.
Certainly, that is the common analysis. And it can be true in many cases. However, you could argue your point in the extreme: The
return value for any method should be a defined type. Rather than returning an int, why not "ScreenWidthType"? There is a
balancing need, which most ignore or do not see until it is too late, to be concise and not promote "class diarrhea". That is a
term I coined after working on a project where the primary development was by an offshore team who never met an idea for creating
new classes that they couldn't apply several times a day. A single transaction through the system involved substantially all of the
600 classes that they had created in a few months.
If you must create a return type, do it as an inner class right at the definition of the method. Having many tiny classes with 10
lines of real code each can become a huge complexity burden: complex simplicity does not result in anything like the lowest total
complexity. If the types are common and key objects in your system, then a separate abstraction is appropriate. That is seldom
true of everything in a system.
As for the TreeMap method, both Qt/C++ and Objective-C includes a properties system where arbitrary values can be ferried by
objects. For certain things, like returning sets that are potentially variable such as the results of an XML parse, this is ideal.
Stephen
Regards,
James
sdw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
