Hi everybody :)
I am currently working on a project that interfaces to a banking system.
The
Banking System uses the ISO 8583 Message layout. For those unfamiliar with
the message layout:
The ISO Message is basically divided into 127 different fields. Things
like
transaction number, account number, some currency fields etc. Not all 127
fields are present in each message, since a Balance Enquiry Message is
different from a withdrawal Message. There is a 128 bit bitmap in the
message header, which details which fields are present.
Message A could, for example, only contain a transaction number, account
number and balance. Message B could contain Name, Surname, Account Number,
etc. Message C would have a different layout. You get the idea :)
Now, the simplest way to implement something like this, would probably be
a
list or array of fields, with a SetField(int fieldNum, string value) and
string GetField(int fieldNum) method. The only problem is, this is very
prone to the user choosing the wrong field (80 instead of 81 for example).
One could use an enumeration for the field numbers (ie enum FieldNumber {
Name = 1, Surname=2, ... }), but this still seems not quite right.
The other option is to code every single message with a GetName, SetName,
GetAcc, SetAcc, etc method for each required field. But this also seems
ridiculous. The advantage is that a) there is no doubt which fields are
available in each message, b) ease of use, (since the client's inhouse
staff
will have to maintain the code at a later stage) and c) the fact that the
Compiler will complain if one tried to access a field which doesn't exist,
since the correct Set/Get method is not present (This would in essence,
equate to a little compile-time message validation).
Another solution may be to use inheritance to let eg. WithdrawalMessage
inherit from Name, Surname, Balance etc. The nice thing about this
approach
is that since balance will contain the GetBalance() and SetBalance()
methods, Name would contain GetName an SetName(), the WithdrawalMessage
would also include these methods, which would give one the functionality
above. Problem is, one now potentially needs to inherit from up to 128
different cl*****. This sounds wrong (even if one uses TypeLists and some
sort of recursive template to simplify this).
So my question is, is there a nice clean way to solve this problem? Is
there
some obscure design pattern that will solve this? Or am I approaching this
all wrong? My gut tells me that somewhere there is a nice, elegant
solution
for this - but I'll be darned if I can see it :(
Thanks in advance folks.
|
