pair.class revised

O

opalpa

A while back I posted what I used as pair

http://groups.google.com/group/comp...de06bb1f053619?q=pair&rnum=1#bdde06bb1f053619


I had some concerns about the code, which a revision has eliminated.
By making pair immutable synchronization concerns disappeared. Here is
a simple class which is used frequently in my code:

/**
Class to maintain a relation between two objects.
*/
public class pair<First, Second> implements java.io.Serializable {
private First one; private Second two;
public pair(First one, Second two) {
this.one = one;
this.two = two;
}
/**
evaluates to "(" + first() + "," + second() + ")"
*/
public String toString() {
return "(" + one + "," + two + ")";
}
public First first() { return one; }
public Second second() { return two; }
/**
A pair equals another pair when their
respective parts equal one another.
*/
public boolean equals(Object o) {
boolean same = false;
if (o instanceof pair) {
pair p = (pair) o;
if (p == this)
same = true;
else {
same = p.one.equals(one) && p.two.equals(two);
}
}
return same;
}
public int hashCode() {
return one.hashCode()*47 + two.hashCode();
}
};

The benefits of being able to update each part of the relation are
small (as a new pair can be created with wanted parts). The benefits
of immutability are greater.

Sharingly,
Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/
 
L

lewmania942

Bonjour mon ami (saw you were learning french ou your website ;)

By making pair immutable synchronization concerns disappeared.

Indeed. Though you'll only get referential transparency if your
First and Second object are also really immutable.

http://en.wikipedia.org/wiki/Referential_transparency

The benefits of being able to update each part of the relation are
small.

To me that would be a procedural approach... and I'd indeed
say that the benefits would be tiniest than tiny.

The benefits of immutability are greater.

I think like you. So does Joshua Bloch...

"Effective Java", item 13: "favor immutability".

On creating a new instance when needed instead
of having a mutable instance:

"It is known as the functional approach because methods
"return the result of applying a function to their operand
"without modifying it. Contrast this to the more common
"procedural approach in which methods apply a procedure
"to their operand causing its state to change.
"
"The functional approach may appear unnatural if you're
"not familiar with it, but it enables immutability, which has
"many advantages.

Buy that book if you haven't done it yet, you'll like it
(it's getting old, but it's a goldmine).


Note also that OOP using immutable objects is possible, but
that is one of the best kept secret of some posters in comp.object
(disagreement on this should go either to comp.object or
to /dev/null ;) <-- notice the gentle smiley :)
 
O

Oliver Wong

A while back I posted what I used as pair



I had some concerns about the code, which a revision has eliminated.
By making pair immutable synchronization concerns disappeared. Here is
a simple class which is used frequently in my code:

/**
Class to maintain a relation between two objects.
*/
public class pair<First, Second> implements java.io.Serializable {
private First one; private Second two;
[snip]
};

The benefits of being able to update each part of the relation are
small (as a new pair can be created with wanted parts). The benefits
of immutability are greater.

Declare the fields as being final, to make your intent more explicit,
and to avoid subtle bugs.

- Oliver
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top