Is it ever justified to have an object which has itself as a field like this :
class Thing {
Thing field;
public Thing() {
this.field = this;
}
}
I'm not talking about a class with a field of the same type but a class made so that every instance of the class has itself as a field. I just saw this in some legacy code (this field was never used) so I'm curious. Any legit use of this ?
Yes, though this is rare. This is used in the JDK for situations which the field could be this but it might not be.
From the class which implements Collections.synchronizedCollection(c)
static class SynchronizedCollection<E> implements Collection<E>, Serializable {
private static final long serialVersionUID = 3053995032091335093L;
final Collection<E> c; // Backing Collection
final Object mutex; // Object on which to synchronize
SynchronizedCollection(Collection<E> c) {
this.c = Objects.requireNonNull(c);
mutex = this;
}
SynchronizedCollection(Collection<E> c, Object mutex) {
this.c = Objects.requireNonNull(c);
this.mutex = Objects.requireNonNull(mutex);
}
In this case the mutex might be the current class, however if this collection is obtained from an existing synchronised collection, the mutex might be different. e.g. if you call Map.values() and the Map is a synchronizedMap the mutex will be the map not the collection.
Another example is Throwable which points to itself as the cause by default.
/**
* The throwable that caused this throwable to get thrown, or null if this
* throwable was not caused by another throwable, or if the causative
* throwable is unknown. If this field is equal to this throwable itself,
* it indicates that the cause of this throwable has not yet been
* initialized.
*
* @serial
* @since 1.4
*/
private Throwable cause = this;
I can think of at least one example where it is justified. e.g.
I have a certificate chain where each link in the chain has a reference to its parent. At the top of the chain the last certificate is self signed so its parent is its self.
In short it really depends on the problem space you are modeling. Any absolute claims stating that this should not be done are suffering from a lack of imagination.
public class Cert {
public Cert parent;
}
public class SelfSignedCert extends Cert {
public SelfSignedCert() {
this.parent = this;
}
}
No, in my opinion this is never justified, because every object implicitly already has such a field: this. Of course, it is justified for an object to have a field which may sometimes, but not always, refer to itself (which could for example occur in a cyclic linked list), but the question is about a field which always refers to the object itself.
I have seen code where such a field is used to be able to refer to the containing object from (anonymous) from inner classes, but also in that case this is not necessary. You can use ContainingClass.this. For example:
class A {
class B {
A getParent() {
return A.this;
}
}
}
Another example in JDK - java.lang.Throwable
private Throwable cause = this;
The cause field can be in 3 states - unset; set to null; set to another Throwable.
The implementer uses this to represent the unset state.
A more readable strategy is probably to define a sentinel value for unset
static Throwable UNSET = new Throwable();
private Throwable cause = UNSET;
of course, there's a recursive dependency - UNSET.cause=? - which is another fun topic.
The only case I can think of is for some kinds of refactoring. To create an example, an object may have started out as a collection of static methods that are not very object-oriented:
public static void doItToIt(Foo it) {
if (it.getType().equals("bar")) {
it.setSomeVariable(value);
it.manipulate();
} else {
// do nothing
}
}
... so we decided to get rid of getType() and make it a subclass relationship, and when refactoring, the thing was copied and pasted so as to make the code cleaner and more object-oriented, necessitating:
public class Bar extends Foo {
private Bar it = this;
private String getType() {
return "bar";
}
public void doItToIt() {
if (it.getType().equals("bar")) {
it.setSomeVariable(value);
it.manipulate();
} else {
// do nothing
}
}
}
If there were only one method like this, it'd be better to use a local variable:
public void doItToIt() {
final Bar it = this;
...
}
but if there are several, using an instance variable would get the code working faster.
It would now be better to go and replace all instances of it with this (and get rid of getType(), and remove the if, and so forth) but as an intermediate step it's still an improvement, and it might get left in that state if there are (or are thought to be) other, more important things to do.
Another possibility would be copying pseudo-code from something like a specification in which this has a name in the pseudo-code and you are deliberately attempting to match the pseudo-code structure to make it easy to compare the implementation to the specification. (And, again, if you had multiple methods so using a local variable would lead to repetition.)
But generally speaking, no, having an instance variable that always refers to this is redundant and thus impedes clarity.
It could be justified if the referenced object can be changed afterwards, but the initial value is this (although such a design should be revisited as well, because it may indicate that Thing has more responsibilities than it should).
However, if the referenced object is always this, then it is unnecessary and confusing.
The following declaration is not only confusing, but also funny :)
private final Thing thing = this;
No because it would be redundant to have itself as a field when it has the keyword this
Within an instance method or a constructor,
thisis a reference to the current object — the object whose method or constructor is being called. You can refer to any member of the current object from within an instance method or a constructor by usingthis." - Javadocs Keyword "this"
In iOS, objects quite often have delegates - typically another object that may supply data, or may do other things needed to make an object to work properly, as an alternative to subclassing. If an object implements all the functionality itself that the delegate should implement, then the object can be its own delegate. Not totally common, but not uncommon either.
Let's say you have a "boss" who has a "secretary", a "coffee maker" and a "driver". The boss can obviously write his own letters, make his own coffee and drive himself, but not every boss does. So sometimes one or more of these fields will be set to "this".
It is fully legitimate in certain usage patterns. In undisclosed enterprise framework I've seen XML like this simplified example:
<form>
<comboBox listItems="order.LineItems" displayMember="description" valueMember="selfRef"/>
</form>
Bindings of the control to values are made though Reflection. If you are happy with only Integer ID as valueMember, you do not need class member referencing to object itself. But if you want reference to object itself AND by design, empty value ("") isn't implemented as special case meaning this, then you need to keep this in a member variable (selfRef in the above example).
