1

i read this in the c# yellow book

IAccount[] accounts = new IAccount[MAX_CUST];
accounts[0] = new CustomerAccount();
accounts[0].PayInFunds(50);

i understand what an instance of class is, what interface is, what i see is instance array called IAccount with size of MAX_CUST, the index number 0 is assigned to an instance of class CustomerAccount, can you please explain what is the logic here? what is the results of the code(behind the obvious) i printed the type of these and i get what type of each individual variable is

when you do

int [] x

you know x[1] to x[9] will hold data type int

when you do

CustomeClass [] y= new CustomClass();

you know y[1] to y[9] will hold objects with CustomeClass class instance attribute, but the syntex in the book is very weird

  • Typically it's because you have different versions of an "Account" - PersonalAccount, BusinessAccount etc - and need a set of "Accounts". This kind of design question is off topic here on SO though. – Luke Briggs Apr 26 '22 at 20:32
  • "y[1] to y[9] will hold objects with CustomeClass class instance" is generally incorrect statement... Please review `sealed` keyword (for reference types) and difference between value and reference type (as that explains why "x[1] to x[9] will hold data type int" is correct while the other statement is not necessary correct). – Alexei Levenkov Apr 26 '22 at 21:32

2 Answers2

0

The confusing part is actually the concrete implementation. It's common to have a collection (or array) of an interface type. Then to assign concrete types to that collection. For example, you may have classes "PersonalAccount" and "CreditCardAccount" both of which implement the IAccount interface. But for showing something like the account balance dashboard you don't care what kind of account it is, so the dashboard could just work with IAccount, so you can throw your collection/array of IAccount at the dashboard and it would call properties/methods on each IAccount.

Where the example get's confusing, is because it's creating the IAccount array, then instantiating the first element as a customer account. More typically you'd not do both those things in the same place (ie you'd create your IAccount's array then add items to it). That said, there are circumstances where creating the interface collection can create cleaner code, even if you're currently only working with one concrete class, especially where you know there may be future expansion and want to draw domain boundaries, and it's cleaner if other parts of your application simply work with IEnumerable - as per the dashboard example above... The Service layer of an application may simple present a method "GetExistingAccounts" which returns IEnumerable - and the concrete classes are never exposed.

Jim
  • 479
  • 2
  • 8
0

The idea is polymorphism - to have many different implementations of same definition in one collection and to process them simply.

This may be IAccount interface's definition:

public interface IAccount
{
   decimal GetBalance();
}

Different classes can implement IAccount interface and each class can have its own implementation of decimal GetBalance() method. In other words, each account type could calculate balance in its own way.

For example, on some user form user can create accounts and add them to a certain group. Account type could be selected from some dropdown list. Each dropdown list item would actually be a different class that implements IAccount interface.

Later on, user would like to see total balance for all those accounts from the group. Accounts would be still in same collection, although they are of different types (classes) previously chosen from dropdown list. Total balance would be calculated this simple way:

public decimal GetTotalBalance()
{
   decimal total = 0;
   accounts.ToList().ForEach(x => total += x.GetBalance());

   return total;
}
Marko Radivojević
  • 458
  • 2
  • 7
  • 11