Returning an Abstract class from a property

  • Thread starter Thread starter Ant
  • Start date Start date
A

Ant

Hi,

I'd like to return a class from a property. The class must be abstract as it
cannot exists without the parent class but the parent class should have the
ability to create it & expose it through a property.

e.g
---
AbstractClass ac;

parentclass.AbstractClass = ac;
---
My question is, if the class is abstract, how do I create it within the
parent class in order to pass it to ac?

Many thanks for any help on this
Ant
 
Ant said:
I'd like to return a class from a property. The class must be abstract as it
cannot exists without the parent class but the parent class should have the
ability to create it & expose it through a property.
Click to expand...
It's not entirely clear what you want. What does "cannot exist without the
parent" mean? Can you give a brief but complete overview of the classes and
their collaborations?

If the goal is to allow instantiation of a class whose exact type is
determined by the subclass, you'll want to use to factory method pattern:
http://www.dofactory.com/Patterns/PatternFactory.aspx

If the goal is to make sure a class cannot be instantiated by outside
clients, you can mark the constructor "internal". This will prevent classes
from outside the assembly from instantiating it.

Otherwise, you'll have to be a little more specific.
 
Jeroen Mostert said:
It's not entirely clear what you want. What does "cannot exist without the
parent" mean? Can you give a brief but complete overview of the classes and
their collaborations?

If the goal is to allow instantiation of a class whose exact type is
determined by the subclass, you'll want to use to factory method pattern:
http://www.dofactory.com/Patterns/PatternFactory.aspx

If the goal is to make sure a class cannot be instantiated by outside
clients, you can mark the constructor "internal". This will prevent classes
from outside the assembly from instantiating it.

Otherwise, you'll have to be a little more specific.
Click to expand...

Thanks Jerouen,

Consider a Bank account & a loan. The loan cannot exist without a bank
account, therefore you can create a bank account but you cannot create a loan
on its own.
To create a loan, you create a bank account which issues the loan.

Hence, the loan (I think) should be an Abstract class & the Bank account can
be instantiated. It has a method (or property)which will pass out a loan
based on information held by the Bank account.

Therefore, you instanitate the Bank account, add information to its
properties; these properties are used to create a loan object which is then
passed out to an object of type Loan.

Therefore, it would look like:

// create the bank account
BankAccount johnsAccount = new Bank Account("John", "Doe", "33");

// create a loan
johnsAccount.CreateLoan("20,000", 5, 5);

// create a loan object to pass the loaon 'out' of the bank acocunt
Loan johnsLoan;

// pass the loan in the bank account into a Loan object
johnsLoan = account.Loan;

// test the values in the Loan object
int loanAmount = johnsLoan.amount;

------------

but how can I create a Loan object from within the Bank Account Class?

Many thanks for your time on this

Ant
 
Consider a Bank account & a loan. The loan cannot exist without a bank
account, therefore you can create a bank account but you cannot create a
loan
on its own.
To create a loan, you create a bank account which issues the loan.
Click to expand...

That describes a sort of parent/child relationship between the account and
a loan, but it has very little to do with the way the classes are
defined. On the other hand, "abstract" is all about how the classes are
defined.
Hence, the loan (I think) should be an Abstract class & the Bank account
can
be instantiated. It has a method (or property)which will pass out a loan
based on information held by the Bank account.
Click to expand...

Either class could be an abstract class, and either could be concrete.
Regardless of how you define the classes, they would presumably have the
same parent/child relationship.
Therefore, you instanitate the Bank account, add information to its
properties; these properties are used to create a loan object which is
then
passed out to an object of type Loan.
Click to expand...

Here's where you seem to misunderstand what an abstract class is.
"Abstract" means that the class cannot itself be instantiated. If you
want to be able to "create a loan object", then the "loan object" _cannot_
be abstract. You are asking how to do an impossible act.

You can define an abstract loan object class if you like, but then you
would still need to define a sub-class of that class that is not abstract,
and thus can be instantiated. Your account object then could either
create a brand new instance of the non-abstract sub-class, or perhaps in
some situations you might already have created an instance of the
non-abstract sub-class previously and are just returning it.

Either way, even if the type of the class that you're returning is the
abstract loan object, you _must_ have a non-abstract concrete class that
is actually implementing that abstract loan class. Otherwise, there's no
way to get an instance of it.

Now, all that said, I suspect that what's really going on here is that you
have misunderstood the word "abstract" as it applies to C# classes (and
OOP classes generally). You haven't written anything that suggests that
the loan class does in fact need to be abstract.

As far as this specific question goes:
[...]
but how can I create a Loan object from within the Bank Account Class?
Click to expand...

You would create a Loan object the same way you'd create any other
object. Use "new" with your desired constructor. Just because that code
happens to be in some other class, that doesn't change how it works. If
you know how to create a "Bank Account Class" instance, then you also know
how to create a "Loan object [class]" instance.

I have the impression from your original post that you may simply want to
prevent any other code except your account class from creating an instance
of the loan class. I'm not convinced that's really a necessary
restriction -- after all, why not allow a loan class instance to be
created as long as the instantiator has a reference to an account instance
to provide when creating the loan instance? -- but if you want that
restriction, you need to provide a way for any loan class constructors to
be visible only to the account class.

I know of at least two ways to do that: you can make the account class a
nested class within the loan class, making the loan class constructors
"private"; or you can put both classes into the same assembly, without any
other classes, and make the loan class constructors "internal". The
latter solution seems more sensible to me.

Pete
 
Peter Duniho said:
Consider a Bank account & a loan. The loan cannot exist without a bank
account, therefore you can create a bank account but you cannot create a
loan
on its own.
To create a loan, you create a bank account which issues the loan.
Click to expand...

That describes a sort of parent/child relationship between the account and
a loan, but it has very little to do with the way the classes are
defined. On the other hand, "abstract" is all about how the classes are
defined.
Hence, the loan (I think) should be an Abstract class & the Bank account
can
be instantiated. It has a method (or property)which will pass out a loan
based on information held by the Bank account.
Click to expand...

Either class could be an abstract class, and either could be concrete.
Regardless of how you define the classes, they would presumably have the
same parent/child relationship.
Therefore, you instanitate the Bank account, add information to its
properties; these properties are used to create a loan object which is
then
passed out to an object of type Loan.
Click to expand...

Here's where you seem to misunderstand what an abstract class is.
"Abstract" means that the class cannot itself be instantiated. If you
want to be able to "create a loan object", then the "loan object" _cannot_
be abstract. You are asking how to do an impossible act.

You can define an abstract loan object class if you like, but then you
would still need to define a sub-class of that class that is not abstract,
and thus can be instantiated. Your account object then could either
create a brand new instance of the non-abstract sub-class, or perhaps in
some situations you might already have created an instance of the
non-abstract sub-class previously and are just returning it.

Either way, even if the type of the class that you're returning is the
abstract loan object, you _must_ have a non-abstract concrete class that
is actually implementing that abstract loan class. Otherwise, there's no
way to get an instance of it.

Now, all that said, I suspect that what's really going on here is that you
have misunderstood the word "abstract" as it applies to C# classes (and
OOP classes generally). You haven't written anything that suggests that
the loan class does in fact need to be abstract.

As far as this specific question goes:
[...]
but how can I create a Loan object from within the Bank Account Class?
Click to expand...

You would create a Loan object the same way you'd create any other
object. Use "new" with your desired constructor. Just because that code
happens to be in some other class, that doesn't change how it works. If
you know how to create a "Bank Account Class" instance, then you also know
how to create a "Loan object [class]" instance.

I have the impression from your original post that you may simply want to
prevent any other code except your account class from creating an instance
of the loan class. I'm not convinced that's really a necessary
restriction -- after all, why not allow a loan class instance to be
created as long as the instantiator has a reference to an account instance
to provide when creating the loan instance? -- but if you want that
restriction, you need to provide a way for any loan class constructors to
be visible only to the account class.

I know of at least two ways to do that: you can make the account class a
nested class within the loan class, making the loan class constructors
"private"; or you can put both classes into the same assembly, without any
other classes, and make the loan class constructors "internal". The
latter solution seems more sensible to me.

Pete
Click to expand...

Hi Pete, Thanks very much for your time in answering that. I belive you
understand what I'm really trying to do. I have seen this done somewhere in
the .NET framework but can't for the life of me remember which classes they
were. I think your last recommendation making the class constructors internal
seems the best solution & one which I'll use.

Thanks again Pete

Ant
 
Hi,
Consider a Bank account & a loan. The loan cannot exist without a bank
account, therefore you can create a bank account but you cannot create a
loan
on its own.
To create a loan, you create a bank account which issues the loan.
Click to expand...

You can solve this problem by different means. All you have to do is make
sure that a loan cannot be creatable.
You can declare the only constructors of the Loan class as internal for
example.

Another way of doing this is by declaring a public interface like ILoan and
the class implementing it is declared inside the BankAccount class. in this
way the class is invisible from the outside (Except using reflection)
 
Back
Top