Re: Looking for right idiom
On 8/23/2012 5:51 PM, Jorgen Grahn wrote:
On Thu, 2012-08-23, Johannes Bauer wrote:
Hi group,
I'm looking for a OO idiom and currently just have a knot in my brain.
I'll explain what the result should be and hopefully somebody can help
me out.
Let's assume I have a class A which has a method setValue(int, int).
Let's further assume that the operation is quite expensive (for example,
think of a database commit). However, in order to keep complexity low,
consecutive setValue() operations can be combined. Assume for example that
a.setValue(w, x)
a.setValue(y, z)
would be equivalent to
a.setValue((w ^ y) * z, z - x)
i.e. the expensive setValue() operation would be executed only once at
the cost of cheap arithmetic operations.
The way I would like this to behave is have the setValue() operation
return some kind of cascadable object that does a "commit" when the last
operation has finished. In other words, it should be possible to:
I suspect that much of the time, it's better to accept that this /is/
something expensive, and expose that fact in the interface. I.e. have
an explicit a.commit() somewhere.
(Note that I'm not saying it's /always/ a bad idea to make it
automatic. File I/O for example -- it would not be convenient in the
general case to have to keep track of how much you've written so you
can flush at the right moment.)
IOW, there is no general recommendation, is there? By the same token,
the 'Setter' could keep track of any sort of parameter of the operation
(like how many 'setValue' calls there have been, or how much time has
passed since it was created or since last 'flush') and perform that
lengthy operation (commit) according to some other heuristic.
V
--
I do not respond to top-posted replies, please don't ask