OOP/Design question

  • Thread starter Thread starter codymanix
  • Start date Start date
C

codymanix

Hi!

I have a class Bank and a Class BankAccount. A Bank can contains multiple
BankAccounts (logical, isn't it?). The central Bank object contains a
datatable which holds the data of all bankaccounts.

This means, the class BankAccount must have access rights to the datatable
in Bank, but I don't want to expose the datatable as a public property.

Since C# does not support friend classes, what is the best solutuion for
this problem?
 
codymanix said:
Hi!

I have a class Bank and a Class BankAccount. A Bank can contains multiple
BankAccounts (logical, isn't it?). The central Bank object contains a
datatable which holds the data of all bankaccounts.

This means, the class BankAccount must have access rights to the datatable
in Bank, but I don't want to expose the datatable as a public property.

Since C# does not support friend classes, what is the best solutuion for
this problem?

Personally, instead of having Bank hold all data for accounts, I'd break the
data down and store it in each BankAccount class. However, to answer your
question as posed I'd just pass the data reference into the account at
construction. Is it one row per account? If so then just pass the
appropriate row into the constructor. If its multiple rows pass in a
DataView.
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
 
codymanix said:
Hi!

I have a class Bank and a Class BankAccount. A Bank can contains multiple
BankAccounts (logical, isn't it?). The central Bank object contains a
datatable which holds the data of all bankaccounts.

This means, the class BankAccount must have access rights to the datatable
in Bank, but I don't want to expose the datatable as a public property.

Since C# does not support friend classes, what is the best solutuion for
this problem?

Yeah.

They are just called "internal" isntead of friend. Ok, not exactly the same,
but VERY close.


--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
(CTO PowerNodes Ltd.)
 
I have a class Bank and a Class BankAccount. A Bank can contains
multiple
Yeah.

They are just called "internal" isntead of friend. Ok, not exactly the same,
but VERY close.


When my application is only one Assembly (which in it is in most cases),
then declaring something internal is the same as making it public.
 
I have a class Bank and a Class BankAccount. A Bank can contains
multiple
Personally, instead of having Bank hold all data for accounts, I'd break the
data down and store it in each BankAccount class. However, to answer your
question as posed I'd just pass the data reference into the account at
construction. Is it one row per account? If so then just pass the
appropriate row into the constructor. If its multiple rows pass in a
DataView.


This seems the best Idea to me. But the constructor of the BankAccount is
still public.
Ideally it would only be visible to the Bank itself. Do you think putting
the BankAccount
class into the Bank as a local class would solve that problem?
 
Thomas Tomiczek said:
Yeah.

They are just called "internal" isntead of friend. Ok, not exactly the same,
but VERY close.
Internal restricts access to the classes in an assembly. An assembly usually
contains many classes. Friend, at least as defined in C++, restricts access
to a single class, a single member of that class, or a single non
member.

/Magnus Lidbom
 
codymanix said:
This seems the best Idea to me. But the constructor of the BankAccount is
still public.
Ideally it would only be visible to the Bank itself. Do you think putting
the BankAccount
class into the Bank as a local class would solve that problem?
A contained class would work. Its a bit harder to work with(The type name is
Namespace.Bank.BankAccount now) but it should be sufficent. Just use a
private constructor(that is, unless my head is fooling with me today).
--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
 
I have a class Bank and a Class BankAccount. A Bank can contains
A contained class would work. Its a bit harder to work with(The type name is
Namespace.Bank.BankAccount now) but it should be sufficent. Just use a
private constructor(that is, unless my head is fooling with me today).


If the ctor would be private, nobody but the BankAccount itself can
instantiate a BankAccount.
 
Back
Top