Re: Good Fowler article on ORM
Jan Burse wrote:
Yes some JITs can do the required escape analysis to some
extent. But when talking about JITs there is always a weak
JIT and a strong JIT, since there are different providers on
the market.
True statements.
For example I am developing the same code base for later
use in both Swing and Android. And the Dalvik JIT for
Android is lacking a little bit behind, you can even read
recommendations to not use setters/getters (sic!) if possible
in code written for Dalvik.
"Setter" and "getter" are well-established informal terms with nothing
shameful in their pedigree.
One must be judicious in accepting such recommendations. I don't oppose direct
use of attribute values /per se/, but I do warn against microoptimization
early in the development cycle.
Write the code that most clearly expresses the model and behaviors it implements.
If you do use, say, 'public' variables in a class, strongly consider using
read-only values to immutable instances.
It is neither microoptimization nor premature to consider whether data will be
primarily read or frequently written. A good domain model considers the flow
and "shape" of information (size of data packets, frequency of transactions,
proportion of duplicates, etc.) and its transformation, not just the static
object model. Considerations of read-heaviness vs. write-happiness originate
in the domain model and are appropriate topics for early analysis. (Aside:
"write-happiness" was a typing accident that I shall let stand.) Whether an
attribute comes as a variable reference or a method call is an implementation
detail perhaps irrelevant to the domain model. An immutable final variable is
not dangerous and can be justified without fear that it's premature. It
directly expresses the intent, might (!) help on an Android and won't hurt
elsewhere.
OTOH I will continue to write my own Android code with getters and setters.
So I am helping the JIT and I am helping the application.
And I'm sure the JIT is ever so grateful for your undoubtedly most useful
assistance.
You should back up such claims with hard evidence.
Measurable, repeatable tests.
I'm not saying you aren't helping, but "helping the optimizer" is so often
such an utterly outrageous claim that it can never be accepted on the face.
The code fragment under discussion is heavily used internally
to the API, since the indexing is dynamic. It is still possible
for the dynamic multi-indexing API, the package which has 9 classes,
to provide a proper Iterator interface to the outside, and use
this by the application.
But if you know that youre deployment range will be only
top-notch JITs you might go into the pain of adding additional
class to the package for the iterator implementations. This
would blow up the packgage to 11 classes, counting the
.class files.
I don't think I get your last paragraph here. What pain? What additional
classes? Why?
Regardless, source-code structure should nearly always express algorithm, not
platform. Deviations should stem from measured results.
I'm willing to lay odds that for your use cases the difference made by
accessors and mutators is not the low-hanging fruit.
Harmless optimizations that also strengthen code structure are always
acceptable, of course.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg