General talk about software patterns

["Yan, Hong [IT]" <hong.yan AT citigroup.com>]

Dan:

 

I like your humor and wisdom. I am sure I would be able to manage my coins better if I am better in accounting methodologies and bookkeeping skills such as double-entry bookkeeping -:)

 

 

rgds

 

Jeff

-----Original Message-----
From: Dan Palanza [mailto:dan AT capecod.net]
Sent: Saturday, September 13, 2003 10:53 AM
To: patterns-discussion AT cs.uiuc.edu
Cc: Yan, Hong [IT]; sfedi AT yahoo.com; RunnDancer AT aol.com
Subject: Re: [patterns-discussion] A question about Coin and Wallet

Hi Jeff,

I have a question that has been on my mind for a couple of days, and I
would like to hear your suggestions/comments. It is on Coin and Wallet,
which describes my wallet and the coins in it. And I am thinking in Java
language.

I can't help you with Java, but do know that the problem of Coin and Wallets that you are studying is a common one; it is the basis for traditional double entry bookkeeping language.

Please be a little patient -:)

Ditto :)

(1) Just Ordinary Coins
Wallet is an object that contains a hashtable with instances of Coin in
it.

In bookkeeping the wallet for Ordinary Coins was defined by Pacioli in 1494 as "debtor cash." Debtor cash, as value, is the bookkeeping entity's share of the purse in each trade. The cash value can be defined by barter, by future promises, or by money, as a medium of exchange held in common by the commercial community.

(2) Collectible Coins
But then, I find two of my coins more valuable than their face values -
they are collectible coins because of mint defects.

Pacioli then defines the category you name "Collectable Coins" as "creditor capital."

The debtor cash category, or wallet, differs from the creditor capital category as the physical calculus of a zero sum game, differs from an intellectual algebra tracking a non-zero sum game.

Sergio moves us into the beginning of bookkeeping's method when he says:

Note that the "value" of a piece of metal,
is not known by it, but by the market in which it is traded.
Moreover, if you want to be really picky, the value of something
is in the context of the transaction that involves it.
I have never been so lucky, and I want to describe this, so I invented
another interface Collectiable:

In traditional double entry bookkeeping cash value is set a contract to trade. Capital's potential, in creditor accounts, becomes an image of future value of the collectable coin if and when it finds its way into a subsequent transaction. In more complex entity situations, future value of an artifact can have expenses, such as storing your coin in a safe place, as well as to generate revenue, such as getting paid to show your coin at a museum.

Wanting to obtain profit for the Collectable Coin and its other invested capital, bookkeeping tracks the safe storage expense and museum revenue that affect the future value Collectable Coin's image accounts that we call "capital."

If you stick with the problem you outline you will find that a pattern language forms where present value, as cash, versus future value, as capital, form two categories of reasoning that take the traditional pattern form. Cash value language, typical of forces, focuses on the behavior of entity such as the physical value of the Ordinary Coin at transaction time. Capital potential language, typical of a solution, focuses on the identity of an intellectual entity intellectual meaning of the Collectable Coin's future value at as subsequent transaction time.

Behavior is defined by interpreting it into physical units of a medium of exchange. (Money as calculus. Units of measure is the traditional bookkeeping application of debits, which can both increase of decrease a counting of cash value depending upon whether a debtor entity is importing resources, such as the safe storage, or exporting product, as the museum revenue.)

Identity is assigned by compiling an accounting into the same medium of exchange, which forms an informational image of future value (money's image, representing an algebraic solution, which tracts entity as a whole image, and as subsidiary images thereof), which we will know for certain only when the contents of the accounts we are tracking become in part or in whole, a transaction in a marketplace.

(5)
Maybe I am worrying too much - I have only one wallet anyway, and how
can I store coins differently when I have only one wallet? But how about
my having two wallets, one for orginary coins and the other one for
precious ones?

You might want to expand your image to include a notion that everything we trade in a marketplace is precious in some way, in terms of both present and future value to the parties engaged in a trade.

I still have no way of changing the behavior of hashtable
in Java, so both wallets would be storing coins in the same way - as
defined by equals/hashCode methods.

If you ever decide to expand your problem to include whole entities, as double entry bookkeeping does, you will see that to track future value you must deal with issues of time as a variable that affects value. In Lisp this is precisely why "the substitution model" is differentiated from "the environmental model." What's more, time as variable, is why Lisp Streams must differentiate two categories of reasoning as 'car' versus 'cdr' for the same reasons that bookkeeping creates a journal of debits (as physical calculi) equivalent to credit (as informational, or intellectual, accounts). By storing data in Journal Form, or Lisp Streams, one can periodically create subsidiary ledgers to calculate time's variables. And, of course, one can filter a Journal, or Stream, to calculate time's changes for specific contracts, such as the Collectible Coin.

Traditional double entry bookkeeping may seem too complex to be worth the effort. But that is a perception that does not hold in fact. Double entry enables test code by setting debtor language into isomorphic balance with creditor language. It then sets entity as subject artifacts in a second isomorphic balance with object liability. Both isomorphies are set into balance by the relation of debits versus credit in each journal entry. The result is test code that is magnitudes ahead of any other way to test for accurate and complete business logic, than any I have followed on this list, or on XP.

What's more, in your particular case, Jeff, bookkeeping's debtor language versus creditor language, which uses debits and credit as elements and operations of a complete language, in my experience, follows the precise pattern of yin versus yang worked out by Chinese scholars in the pattern language used to support I Ching's oracle. My feeling is that these scholars have earned tribute that is long since past due.

Dan