RE: [MO-java-dev] dynamic mock cannot handle overloaded methods

[Tim M. <tim...@po...>]

I have been a silent lurker on this one - but there is a code smell here...
using overloading of methods in this way is a bad sign (it may ultimately be
legitamate but there is a smell I have encounterered in other java code).

If you want to avoid an if statment but are relying on overloading to get
this - there is an issue. From a quick glance, this looks like a double
dispatch pattern - the object you are passing in is a visitor, different
objects call back using the different method signatures - this isn't
polymorphic at all - you don't really gain anything from giving the same
method name to the two methods as they are just differnt  (they have
different paramaters anyway) - why not be clearer and say getShorQuatity....
and getPositionQuatity (eg. different names).

If you want polymorphism - getQuatity should have the same parameter with
some other object that has the details required. This is often the smell -
you are missing some other object (which is the single paramater)- your
tests may be telling you this???

If you were overloading with the same number of parameters - is there
something common in those parameters (ie some interface) - if so the
interaced parameters should be used and the mock would be simple.

Tim
 -----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of Barry
Kaplan
Sent: 19 November 2002 16:22
To: Nat Pryce
Cc: mockobjects dev
Subject: Re: [MO-java-dev] dynamic mock cannot handle overloaded methods


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.

Java does not dispatch methods polymorphically based on runtime argument
types.  If your code is calling overloaded methods you don't need ifs
and switches.
  I was not refering to polymorphism at the overloaded method level, but the
ability to not have to do:

  int quantity
  if ( bla bla) {
      getLongCashOvernightQuantity();
  else if (bla bla) {
      get ShortCashOvernightQuantity();
  else if (bla bla)
      get LongMarginDaytradeQuantity();
  else if (bla bla)
      ...

  (Remember, you asked why overloaded methods were necessary at the
interface level. The above is why).


  ------------------------------------------------------- This sf.net email
is sponsored by: To learn the basics of securing your web site with SSL,
click here to get a FREE TRIAL of a Thawte Server Certificate:
http://www.gothawte.com/rd524.html
_______________________________________________ Mockobjects-java-dev mailing
list Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.419 / Virus Database: 235 - Release Date: 13/11/2002