On 17 February 2014 10:34, <fwereade@gmail.com> wrote:
> AFAICS, this just makes the code harder to change. Opinions may
> reasonably differ re likelihood of changes that'd cause the interface
> implementation to pay off, but IME the aggregated cost of designing for
> change is trivial compared to the cost of failing to do so, and so a CL
> that just removes flexibility does not lgtm.
For the record, my view is precisely the opposite in this case.
For methods that simply return some data, it is easier just
to have a field containing the data rather than an extra method
to call that returns the data and an interface type that encapsulates
that.
Adding an extra layer of indirection does *not* make things easier
to change, particularly when we are talking about a package-internal
detail here.
Any change is likely to require changes to the signature of the interface
type, and therefore to the user of that type. Given that, we may as well
just store the data in fields and avoid the need to change all the
interface implementations as *well* as the users of the type.