Data Object

Interfaces for: READ_WRITE with EQUALS

Why is this different? This approach is safe as all data can be copied.

Story: Editing information from an external server, and sending it back

• In this approach the equals and hashcode defined in the javadocs (all implementations are interchangeable as an Object is completely defined by its contents).
• Data objects are suitable for use with Collections<Interface>, actual collection implementation may store the values any way they see fit.
• A factory is not needed (since it is a data object there is no difference between one implementation and the next)

The GeoAPI Feature interface is defined in this fashion.

ID Often when the specification itself demands a data object you will see the provision of an "ID", you can define your equals and hashcode methods in terms of this ID for a benifit of both speed and simplicity.

Example Interface

A definition of hashCode and equals has been provided in the javadocs:

Notes:

• getISBN(): is immutable so we can return it straight up
• getDates(): is mutable so we return a copy

Example Data Implementation

Notes:

• all methods are synchronized
• getDates() makes a copy (and is careful to check for null)
  • CitationDate has a nice copy constructor to make this easier
• equals implementation does a special check to avoid a copy if it can

Yes this example does not look fun, but it is safe.