views:

37

answers:

1

Hi.

So I have started my initial design of a simple system.

I have a superclass/abstract called Customer. It has 2 subclasses: PrivateCustomer and BusinessCustomer.

I also have an account class. This account may be a downpayment account or just a regular account. It it determined by a Enum. The Customer class has a List<> of accounts.

Now, I also have a transaction class, and this is where it gets tricky. The transaction class has the following properties:

  • Sender
  • Receiver
  • Amount
  • Date
  • Type (Enum)

As you might imagine: A customer can have 1 or more accounts. A customer can make 0 or more transactions. An account has transactions (or the other way around?)

Now. Where do I place there transaction? Keep in mind, the system might have/get [insert large number] of transactions over time.

  • Do I have a global list of all transactions and simply filter the list, when I want to see all transaction for PrivateCustomer 12345?
  • Do each account property, in the Customer class, have a list of all transactions instead?
  • Something third?

As long as its an OO-solution, I will be satisfied.

+2  A: 

Why not Sender and Receiver be references to Customer objects. Going the other way, each Customer has a List of references to Transaction objects that it is participating in. If your design will allow for a circular reference, this is the way I would go.

Something along these lines:

using System;
using System.Collections.Generic;

namespace Sample
{
    public abstract class Customer
    {
        protected string _name;
        //...
    }

    public class PrivateCustomer : Customer
    {
        private List<Transaction> _transactions;
        //...
    }

    public class BusinessCustomer : Customer
    {
        private List<Transaction> _transactions;
        //...
    }

    public class Transaction
    {
        private Customer _sender;
        private Customer _receiver;
        private double _amount;
        private DateTime _date;
        private AccountType _accountType;

        //...
    }

    public enum AccountType
    {
        Downpayment,
        Regular
    }
}

a revision taking into account the account information (no pun intended):

using System;
using System.Collections.Generic;

namespace Sample
{
    public abstract class Customer
    {
        private List<Account> _accounts;
        protected string _name;
        //...
    }

    public class PrivateCustomer : Customer
    {
        //...
    }

    public class BusinessCustomer : Customer
    {
        //...
    }

    public class Transaction
    {
        private Account _sender;
        private Account _receiver;
        private double _amount;
        private DateTime _date;

        //...
    }

    public abstract class Account
    {
        private Customer _customer;
        private Collection<Transaction> _transactions;
    }

    public class RegularAccount
    {
        //...
    }

    public class DownpaymentAccount
    {
        //...
    }
}
Steve Elmer
Truth to be told, I am not sure what you mean. I am using c# if that helps you.
CasperT
Is this a homework assignment?
Steve Elmer
I simply have had a discussion with a friend, on how to design something like this. We couldn't find an answer, so I am using SO as a third-party
CasperT
So the answer would be the 2nd suggestion I made? "Do each account property, in the Customer class, have a list of all transactions instead?" or is there a difference I have not spotted.
CasperT
No need for a master list of Transaction objects. Each Customer has references to its own Transactions and each Transaction has references to the customer with whom it participates.You would, of course need to create the properties and/or constructors to wire up the relationships.
Steve Elmer
hmm... I overlooked the bit about accounts. thinking...
Steve Elmer
So the answer is my second suggestion/alternative. Thanks :)
CasperT
Steve Elmer
and, yes, the "as long as it is an OO solution" comment is a bit silly ;-)
Steve Elmer