From FunctionObject...

This is an extremely valuable object we found working on LifeTech. It is so simple, but it makes solving so many problems trivial.

A Function is a function of value over time. The instance signature is:
	+ , - aFunction => aFunction
	/ , * aNumber => aFunction
	valueOn: aDate => aNumber
	integrate => aFunction
	discountBy: , compoundBy: aNumber => aFunction (returns the integral of the NPV (or FV) of the receiver)

The constructors are:
	on: aDate pay: aNumber
	in: aPeriod pay: aNumber
	in: aPeriod pay: aNumber every: aPeriodicity

With this and nothing more you can build models of interesting financial instruments like life insurance. In particular, where models like AccountsAndTransactions are good at modeling a fairly certain past, Functions are good at modeling an uncertain future.

You could substitute a MoneyObject for numbers in the above and gain the ability to model multi-currency instruments.

'''Implementation Hints'''

Don't go crazy trying to duplicate Mathematica. Only implement the operations you need to model your situation. We found that we could get away with a much-less-than-complete-or-orthogonal implementation and still model everything we needed to model.

The classes in our system are:
	* Function -- Abstract superclass
		* Instantaneous -- "$45 on 1 May". Created by Function class>>pay:on:
		* Constant -- "$45 / year for the next ten years". Created by Function class>>pay:in:
		* Periodic -- "$45 monthly for the next ten years". Created by Function class>>pay:in:every:
		* Exponential -- a * (b ^ (t - t0)). Created by compoundBy: and discountBy:.
		* Sum -- The sum of any number of Functions. Created by + and -.

	* Period -- An interval with start and end dates. We found it very helpful to make Periods contain dates >= to the start date and < the end date. 

----

''Siggggghhhhhh.  I hate to sound mainstream like this, but would someone be willing to give me a c++-esque version of this one?''

MichaelFeathers went crazy trying to implement MoneyObject in C++. The structure of the two is very similar in some ways.

Discussion of ValueObject''''''s (like MoneyObject) being AlgorithmsThatDemandGarbageCollection moved to ValueObjectsRequireGarbageCollection.

-----

Sounds like you're creating class(es) that combine dates with monetary amounts.
I'd probably have common interfaces, and multiple implementation classes, as the number and types of valid attributes vary with usage, and yet are fixed at construction time.
Use a ClassFactory object (...which is what a SmalltalkLanguage class object is) if you like the simple creation syntax.

So, looking at the different uses (which I would make classes):
	* Instantaneous -- "$45 on 1 May".  Attributes:  MoneyObject ($45) and Date (1 May of some year).
	* Constant -- "$45 / year for the next ten years".  Attributes:  MoneyObject ($45), Period ("One Year"), Numer-of-Periods (10).  ''Perhaps it needs a start date / first payment date?''
	* Periodic -- "$45 monthly for the next ten years".  Attributes:  MoneyObject ($45), Period (per "Month"), Numer-of-Periods (120).
	* Loan with Interest (but not payments).  Attributes:  Start Date, Principal, Interest Rate, Compound Period (IE: Daily).
	* Loan with Payments:  Combine (as attributes) a "Loan with Interest" with any payment scheme above.

The common interface could include functions such as...
	* What's the "Net Present Value" of the loan, or payments, as of <date> (assuming a given inflation <interest rate>).
	* What will be the total of all payments?
	* As of <date>, what's the total of payments made?