Document query-related interfaces

[JordanMartinez]

I believe PointQuery should extend BoundsQuery (since that provides the initial query method) and should better clarifies what its query method method does. There is no PointQueryImpl because BoundsQueryImpl is the actual implementation used for the PointQuery interface.

Why then does the BoundsQuery interface exist? I have no idea. Perhaps to prevent any changes to the implementation's position or offset values.

[JordanMartinez]

Note: I did not write javadoc for PointQuery's query method due to the above concern/issue.

[JordanMartinez]

I'm going to look into the locator package to see if that might give more insight as to the various ways that PointQuery can work.

[brcolow]

To be honest I am not a fan of the interface Thing, class ThingImpl implements Thing pattern. Ideally I think interfaces should almost always be adjectives (think Comparable, Sortable, Identifiable, etc.). That is, we would have a Queryable<T> interface in this case. However, I do not think tearing apart the working base we have would be fruitful (not saying you are suggesting to do that, but to enforce the adjectives idea would take a lot of re-writing).

In any case, can you show me with code what your suggestion is for the inheritance of PointQuery and BoundsQuery?

[JordanMartinez]

How can PointQuery extend BoundsQuery though? BoundsQuery's query method returns Bounds and PointQuery's query returns Point2D. What am I missing?

Ah! Haha... I didn't realize they had 2 different return types 😄

[JordanMartinez]

Why doesn't BoundsQuery have a @FunctionalInterface annotation? That's essentially all it is.

[JordanMartinez]

interface Thing, class ThingImpl implements Thing pattern.

Neither am I. I think I read somewhere that this is an anti-pattern, but I can't recall all that it said.

[brcolow]

The @FunationalInterface annotation is optional, but it is nice to use. I saw throw it on 😄 ! Going to bed for the night.

[brcolow]

Merged. Thanks a lot.