I have an annoying problem I'm pondering: A dll has an object that implements a couple interfaces. One of these interfaces is IMetric, which exposes a couple methods that expose a means to calculate a single metric. When the program starts, it examines the objects in the dll, and if it finds one that implements a certain interface, it creates an instance of that object. If the object ALSO implements IMetric, the object is cast to IMetric and added to a list.
The problem is that I have recently realized that I need to expose two metrics from out of that dll. Effectively, I need to expose two metrics from out of that single object, because that single object is the gateway to calculate both metrics, and to do so it has to maintain information that no other object should even know about. The object can't implement IMetric twice, so the only two alternatives that I see are:
1) Alter the IMetric interface so that it can be used to return multiple metrics. This is possible, but annoying, since the current interface is particularly clean. The Metric is a function that returns a Double or Decimal. The IMetric interface also has an ordinal. Any other program can look up a metric based on the ordinal, or the name (such as weight, length, depth, volume, and other things). If I change IMetric to expose multiple metrics, the IMetric interface would have to return a List(of Integer) containing all the ordinals it answers for rather than a single ordinal. The function would also have to accept an ordinal as an argument to decide what information it has to return. That's considerably less clean than the current design, but it may be necessary.
2) Include a separate object in the dll that implements the IMetric interface. This may not even be workable. Because the objects are discovered and created dynamically, an instance of the first object won't know about an instance of the second object. Since the first object is the one that obtains/manages/allows editing/saves/ and restores the information critical to calculating the metrics, if the second object didn't have knowledge of the first object, then it wouldn't be able to work with the data, and wouldn't be able to do anything at all. I may be able to solve this by making the critical information Friend Shared data in the first object, since both objects are effectively Singletons, and there will only ever be a single instance of each. This seems like a pretty stupid design, though, because the second object won't have any data. It will be nothing but a class with a few methods and no data members of its own.
I don't particularly like either of these solutions, but am inclined to go with #1 as it increases versatility at the cost of some cleanliness, whereas the second option seems like a hack. I'm looking for any other suggestions.
The problem is that I have recently realized that I need to expose two metrics from out of that dll. Effectively, I need to expose two metrics from out of that single object, because that single object is the gateway to calculate both metrics, and to do so it has to maintain information that no other object should even know about. The object can't implement IMetric twice, so the only two alternatives that I see are:
1) Alter the IMetric interface so that it can be used to return multiple metrics. This is possible, but annoying, since the current interface is particularly clean. The Metric is a function that returns a Double or Decimal. The IMetric interface also has an ordinal. Any other program can look up a metric based on the ordinal, or the name (such as weight, length, depth, volume, and other things). If I change IMetric to expose multiple metrics, the IMetric interface would have to return a List(of Integer) containing all the ordinals it answers for rather than a single ordinal. The function would also have to accept an ordinal as an argument to decide what information it has to return. That's considerably less clean than the current design, but it may be necessary.
2) Include a separate object in the dll that implements the IMetric interface. This may not even be workable. Because the objects are discovered and created dynamically, an instance of the first object won't know about an instance of the second object. Since the first object is the one that obtains/manages/allows editing/saves/ and restores the information critical to calculating the metrics, if the second object didn't have knowledge of the first object, then it wouldn't be able to work with the data, and wouldn't be able to do anything at all. I may be able to solve this by making the critical information Friend Shared data in the first object, since both objects are effectively Singletons, and there will only ever be a single instance of each. This seems like a pretty stupid design, though, because the second object won't have any data. It will be nothing but a class with a few methods and no data members of its own.
I don't particularly like either of these solutions, but am inclined to go with #1 as it increases versatility at the cost of some cleanliness, whereas the second option seems like a hack. I'm looking for any other suggestions.