From: Barry K. <bk...@in...> - 2002-11-19 15:11:31
|
Nat Pryce wrote: >I designed the API that way for simplicity rather than completeness. In >all my use of the dynamic mock library I have not found a need for >overloaded methods. Overloaded methods they do not seem to be used in >interfaces. The interfaces which are most likely to use overloaded >methods (DataOutput for example) don't use them to, I guess, avoid >silent type coercions and all the tricky bugs they cause. > >Supporting overloaded methods would make the API really awkward unless >the Mock class completely hid the lookup of methods behind a convenient >set of functions. > I believe I can do it without any change to the public interface. Roughly, what I was thinking of was to add a method to MockCall to return Class[] corresonding to the method arguments. MockCall would delegate to its [top-level] Constraints to get the Class's. Thus, given the name and Class[], MockCall can get the Method and use that as the key. (MockCall already looks up the Method when invoking a non-proxied method, but in that case it already has the Object[]'s.) The one limitation (until jdk 1.5) is that composite Constraint's will simply give back the first Class of the first contained Constraint. One of the other benefits of this approach is that invocations to setupCall/expectCall can check that the MockCall represents an actual method on the interface at the time the call is setup. As it is now, the test can specify a set of arguments for a non-existant method. This type of error won't manifest itself until Mock.invoke(). >Can you give us an example of where you need them? > > The class I have been using to learn mocksobjects: public interface Position { int getQuantity(PositionBucketType bucketType, PositionTimeType timeType); int getQuantity(LongShort longShort, CreditType creditType, PositionTimeType timeType); .... } Different components of our system know different aspects of a position. The two methods above allow each to access the quantities polymorphically without any ifs or switches. What I have done so far is to use explicit CallSequence (actually CallSet, which does not consider order of invocations): public class MockPosition extends Position { private CallSet expectedGetQuantity1 = new CallSet(); public int getQuantity(PositionBucketType bucketType, PositionTimeType timeType) { // use expectedGetQuantity1 } private CallSet expectedGetQuantity2 = new CallSet(); int getQuantity(LongShort longShort, CreditType creditType, PositionTimeType timeType); // use expectedGetQuantity2 } .... } |