]
Brian Carothers updated DNA-280:
--------------------------------
Attachment: DNA-280-abstract.patch
Refactored Location into abstract class with one generic concrete subclass
(PathPropertiesLocation) and two specific concrete subclasses per IRC discussion. Added
test case for Location.
Create optimized versions of Location
-------------------------------------
Key: DNA-280
URL:
https://jira.jboss.org/jira/browse/DNA-280
Project: DNA
Issue Type: Task
Components: API, Graph
Affects Versions: 0.3
Reporter: Randall Hauch
Assignee: Randall Hauch
Fix For: 0.4
Attachments: DNA-280-abstract.patch, DNA-280.patch
The Graph API uses the Location class to represent the location (path and/or
identification properties) of a node. So far, we haven't needed different
implementations, but given that the current class has a number of optional member
attributes and we'd like to add more, it is probably prudent to have different
implementations that more optimally represent the combination of attributes that's
possible.
Currently, there are quite a few constructors and they are called in numerous places.
However, every place that one is created, an ExecutionContext is available. Therefore, it
seems like there are (at least) two valid approaches:
1) Change Location to an interface, create multiple implementation classes, define and
implement a LocationFactory that instantiates the most appropriate implementation class,
and add getLocationFactory() to the ExecutionContext. This approach mirrors the way that
the properties and value types are created, but Location objects are not used as property
values. It would even be possible to add a "with(LocationFactory)" method to
ExecutionContext so that one can clone a context but specify the implementation of the
LocationFactory that the clone should use.
2) Keep Location as an abstract class, but remove the constructors and replace with
static factory methods. This would likely mean that there is a single set of
implementations that never need to be customized. It also means that we could add methods
that could return a new location with additional attributes set. For example:
Location newLocation = location.with(uuid);
Either way, we need to change the current implementation to be more flexible. I think
the choice comes down to whether it's appropriate to be consistent with the
factory-style approach used by property values, or whether Location is different enough
and we know we'll only have a single family of implementations that don't need to
be extended or customized.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: