C# bank example - class for customers - what for withdrawls, deposits, etc

Question

I'm learning C# and am trying to get my head around when to use classes and when not to.

If I was writing an app for a bank, I know I would use classes for customers which would include their name, account number, balance, etc. Would I use a static class for the methods that would deposit into their account, withdraw, change their address, etc since I only need to write them once?

Also, what would I use to keep track of every customer object? Having 2,000 Customers:

exampleName = new Customer();

in my code doesn't seem right. I'm not at the point of learning database's yet and am just learning classes.

Solution 1

Having a database would be ideal, but in the mean time you could use an IEnumerable to hold your Customer objects, like this:

List<Customer> myCustomers = new List<Customer>();
myCustomers.Add(new Customer {Name = "Bob", Address = "123 Anywhere St." });  

Then you can just pass the list around where needed.

Typically you will then have a property on the Customer class that holds the accounts:

public class Customer
{
    public Customer()
    {
        _accounts = new List<Account>();
    }

    public List<Account> Accounts 
    {
        get { return _accounts; }
        set { _accounts = value; }
    }

    private List<Account> _accounts;
}

And so on. Note that I'm keeping this simple and doing things the more long winded and descriptive way as you are a beginner.

Using lists of items in this way is a good way to start because you will natuarlly use these when you get to using a database; you will retrieve result sets from the database and then translate those result sets into lists of business objects.

As for using static methods to do business logic like adjusting balances, changing addresses, etc., for you at this stage it doesn't matter. If you are using tools like Resharper it will nag you with suggestions like that, but in your case you can safely ignore that particular one. What you should look for is keeping everything as self contained as possible, avoid leakage of data and leakage of responsibilities between objects - this is just good coding discipline and a good way to prevent bugs that are caused by loose coding.

Once you've got your functionality laid down and working, you may have a desire to move some functionality into static 'helper' style classes. This is absolutely fine, but do be careful - helper classes are fantastic and everything but can quickly turn into an anti-pattern if you don't maintain that coding discipline.

Solution 2

You don't need to use a static class, or static methods, in order to only write the methods once. It may or may not make sense to do so, but this is a perfectly valid way to write the methods without repeating yourself:

public class Customer
{
    //properties, constructors, etc.

    public virtual void Deposit(decimal amount) { }
    public virtual void Withdraw(decimal amount) { }
    //etc
}

This also allows you to make use of polymorphism, e.g.

public class BusinessCustomer : Customer
{
    public override void Deposit(decimal amount) { //some other implementation }
}

Solution 3

Static classes are used when you aren't going to instantiate objects. You get one "instance" of that class - you can't do things like:

MyStaticClass m = new MyStaticClass();
m.SomeFunc();

when you've got a static class. Instead you'd use it by using the class name itself. Something like:

MyStaticClass.SomeFunc();

As to what would you use to keep track of every Customer object? You could use some sort of collection to hold these. Granted, in a real system there'd be some sort of persistence piece, likely a database, to hold the data. But you could just make something like:

IEnumerable<Customer> Customers = new List<Customer>();

And then add your customers to that list

Customers.Add(new Customer() { ... });

Back to the question about static methods...

So, the deal here is that you're not going to be referencing instance members in a static method, so you wouldn't use static methods to update a particular Customer's address. Assuming your Customer class looked like:

public class Customer
{
   public string Address { get; set; }
}

You couldn't use a static method like

public static void SetAddress()

because each Customer (presumably) has a different address. You couldn't access the customer's address there because it isn't static. Get that? Instead, you'd use a static method if you were wanting to do something that didn't need to deal with instance data. I use static methods for things like utility functions.

public static double ComputeSomething(double someVal) { ... }

Here, the ComputeSomething function can be called by anybody like:

var result = MyStaticClass.ComputeSomething(3.15);

The takeaway here is that static classes aren't used to instantiate objects, rather they are used really as a convenient container to hold functions. Static functions are ones that can be on a non-static class but can't access any of the instance data.

One place where a static function would be used would be for the Singleton pattern. You make the constructor non-public so folks can't call it, and instead provide a static method on the class to return the one and only instance of the class. Something like:

public class MySingleton
{
   private static MySingleton instance;

   private MySingleton() {}

   public static MySingleton Instance
   {
      get 
      {
         if (instance == null)
         {
            instance = new MySingleton();
         }
         return instance;
      }
   }
}

Comments

[varg]

List<T> and other types of collections are important. Check MSDN, too: msdn.microsoft.com/en-us/library/6sh2ey19.aspx