On Mon, 28 Apr 2008 13:21:14 -0700, cbmeeks <cb*****@gmail.comwrote:
[...]
m.Value(); // 300
m.Value().FilterBy("Taxes"); // 200
This is a CRUDE example of what I have working. Method/Class names
are different but you should get what I am trying to do.
Right now, I have it working but I have to do something like:
m.Value(); // 300
m.Value("Taxes"); // 200
I don't like my current version because I actually have many methods
besides "Value". Things like Average, Sum, etc. I would hate to have
to overload every method to support tags.
I admit, I don't really see what the problem of having overloaded methods
is. Presumably the "unfiltered" version would just call the same
implementation as the filtered version. There should be very little extra
work.
However, as Ben alludes to, if you reverse the semantics you could do it
more like you're presenting here. In particular, create a Filter() method
that, given a specific tag, returns a new Metric instance that includes
only the data associated with that tag. Then the basic "Value",
"Average", etc. would still work without having to have each one support
an overload version.
A very basic implementation would simply create a standalone Metric
instance, unconnected to the original. It would be just like the original
Metric instance, but containing only the data that passes through your
filter.
But if you wanted to get fancy, and assuming it works well with your
present paradigm, you could design the Metric class and the Filter()
method so that the new instance is actually just a reference back to the
original one that contains the data. In the filtered instance, rather
than having a copy of the data, you'd just keep the tag you're using for
filtering, and do the appropriate thing in your calculations.
If you did this, then the new Metric would always be a filtering version
onto the original data. As data in the original changed, you could keep
using the filtering version to do the same filtered calculations on the
new data. Even if you didn't keep the previous filtering version,
creating new ones should be inexpensive, compared to the alternative of
creating a new copy of the data for each filtered Metric.
Doing it that way would be sort of like the "Tags property" solution you
mentioned, but without layering the filter state onto the existing Metric
instance. Instead, the filtering state would be unchanged for any given
Metric instance.
If you do get rid of the overloads in this way, then you could just make
the calculations properties instead of methods. Personally, I think
that'd be a little nicer, though obviously it's not a critical part of the
design.
As an alternative to the above, you might consider breaking the
functionality into two classes. One class to manage the data collection,
and another to do the filtering and calculations. This would be basically
the same as the "fancy" version of what I suggest above, with the
advantage that by making a second class responsible for filtering and
calculating, you would never have the ambiguity of a single class that is
doing two fundamentally different things. You'd always create an instance
of the filter-and-calculate class by passing to the constructor at a
minimum the data collection class, and optionally whatever filter criteria
is important (or you could keep the Filter() method on the collection
class, making it essentially a factory for the filter-and-calculate class).
And if that's not a complicated enough list of suggestions :), I'll point
out that the problem sounds suspiciously like a special case of a
database. You can "select" (which is the filtering process) and run
computations on the results. It may be that this could all be handled in
a more general way, using a basic collection class to contain your data,
and then LINQ syntax to do the filtering and computations.
Pete
