EBF_2

Is there a way to implement operator+ given that I need the interface class, IMoney below, to be on the return and left hand side of the expression TIA, Eric

--------------------
There are two concrete classes, Money and MoneyBag, both of which implement a common IMoney interface. Adding is done via double dispatch.

public interface IMoney {
IMoney Add(IMoney m);

IMoney AddMoney(Money m); // helper to double dispatch, although requires public access

IMoney AddMoneyBag(MoneyBag mb); // helper to double dispatch, although requires public access
}

public interface Money {
public IMoney Add(IMoney m) {
return m.AddMoney(this);
}

public IMoney AddMoney(Money m) {
if (m.Currency.Equals(Currency)) {
return new Money(Amount + m.Amount, Currency);
}
return new MoneyBag(this, m);
}

public IMoney AddMoneyBag(MoneyBag mb) {
return mb.AddMoney(this);
}

public static IMoney operator +(Money m1, IMoney im) {
return m1.Add(im);
}
}

public interface MoneyBag {
public IMoney Add(IMoney m) {
return m.AddMoneyBag(this);
}

public IMoney AddMoney(Money m) {
return (new MoneyBag(m, this)).Normalize();
}

public IMoney AddMoneyBag(MoneyBag mb) {
return (new MoneyBag(mb, this)).Normalize();
}

public static IMoney operator+ (MoneyBag mb, IMoney im) {
return mb.Add(im);
}
}


Re: Visual C# General operator+ usage with an interface

mwalts

Seems like your trying to put implementation into an interface based on your code segment, which is wrong.

Secondly, if it returns a MoneyBag or a Money, if both implement the IMoney interface, you can treat them like IMoney objects regardless of which is actually returned. Yes you should be able to return an IMoney object as well

Actually using an interface in design is done like this

public interface IMoney {
IMoney Add(IMoney m);

IMoney AddMoney(Money m); // helper to double dispatch, although requires public access

IMoney AddMoneyBag(MoneyBag mb); // helper to double dispatch, although requires public access
}


public class
Money:IMoney {

//And here I must implement the three add methods above

}

Based on what I've seen you might want to rethink your design a bit, maybe you could tell us what you are actually trying to do with this structure

Good luck,

-mwalts




Re: Visual C# General operator+ usage with an interface

Alan M.

Yes interfaces do not contain any implementation just a list of methods that a class must implement.

Have you looked into using a abstract class An abstract class cannot be instantiated. It can however define some functionality and also declare methods that are abstract meaning a class that inherits from it MUST implement the abstract method, however it can use the parent abstract class's non-abstract methods through inheritance.




Re: Visual C# General operator+ usage with an interface

EBF_2

Ideally I'd like to have an library of of classes to support Fowler's Quantity pattern for both Money & Time, with an expression of the Amount as a double for both, but I'd settle for being able to get the Add operation on simple (same currency) Money right for a start :-).

I can't even do someMoney.Add(someOtherMoney).Add(someOtherMoney) as it is.

I like the idea of the MoneyBag since it allows for deferred currency conversion at an arbitray time (I'll need a Converter interface & implementation too). To answer your question more directly, I want some reuseable domain libraries to replace manual & semi-manual (ie, Excel) currency conversions, and as a separate project, a flexible way to handle timesheet accounting and reporting (Excel again). Then I could quit my day job (which I should probably be greatful for!) and become an overnight billionaire.

I agree with you that the implementation I shamelessly stole from an NUnit sample designed to show off NUnit more than the Money class 'feels' confining. From the little I know of GoF design patterns, it seems like I should be dealing with Composition at least.

Would greatly appreciate any pointers towards extracting the implementation out of there or anything else I've mentioned here.

As an aside, I didn't see where the code you wrote differed from mine, but I may just be thrilled that it's Friday.

Thanks for responding!! Eric