Polymorphic (Apache Jena)

java.lang.Object
- org.apache.jena.enhanced.Polymorphic<T>

Direct Known Subclasses:

EnhNode
```
public abstract class Polymorphic<T>
extends java.lang.Object
```
Abstract base class for all polymorphic RDF objects, especially enhanced node and enhanced graph.

Method Summary

All Methods Instance Methods Abstract Methods Concrete Methods
Modifier and Type	Method	Description
`void`	`addView(Polymorphic<T> other)`	add another view for this object.
`abstract boolean`	`equals(java.lang.Object o)`	subclasses must override equals.
`abstract boolean`	`isValid()`	answer true iff this enhanced node is still underpinned in the graph by triples appropriate to its type.
`<X extends T> boolean`	`supports(java.lang.Class<X> t)`	return _true_ iff this polymorphic object supports the specified interface.

Methods inherited from class java.lang.Object
getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

- Method Detail
  - supports
```
public <X extends T> boolean supports(java.lang.Class<X> t)
```
    return _true_ iff this polymorphic object supports the specified interface. Synonymous with "does the argument class have this as an instance". Actually it shouldn't be. Review.
  - isValid
```
public abstract boolean isValid()
```
    answer true iff this enhanced node is still underpinned in the graph by triples appropriate to its type.
  - equals
```
public abstract boolean equals(java.lang.Object o)
```
    subclasses must override equals. Actually they may not have to nowadays ... I have expunged the clever facet-identity test (and indeed facets).
    
    Overrides:
    
    equals in class java.lang.Object
  - addView
```
public void addView(Polymorphic<T> other)
```
    add another view for this object. other must be freshly constructed. To be called by subclasses when they have constructed a new view for this object.
    The method is synchronised because addView is an update operation that may happen in a read context (because of .as()). Synchronising it ensures that simultaneous updates don't end up leaving the rings in an inconsistent state. (It's not clear whether this would actually lead to any problems; it's hard to write tests to expose these issues.) This method is public ONLY so that it can be tested. TODO find a better way to make it testable.