Calling ancestor method

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I know that you can do this, I can't find the answer. I try the following code

((company) base).newCompany("ACME", "vendor");

Of course company is the ancestor and newCompany is a public method. The
compiler tells me that "use of keyword 'base' not valid in this context"

What am I missing?
 
Rik said:
I know that you can do this, I can't find the answer. I try the following code

((company) base).newCompany("ACME", "vendor");

Of course company is the ancestor and newCompany is a public method. The
compiler tells me that "use of keyword 'base' not valid in this context"

What am I missing?
Click to expand...

You don't need to cast to company - just call

base.newCompany("ACME", "vendor");

Jon
 
Nope, the compiler tells me

Error 1 'object' does not contain a definition for 'newCompany'
--
----------------------------------------
Magic is not in the hands of the magician but in the mind of the audience.

Animadverto est verus
 
OOPS! I forgot to make vendor inherit from company. I thought for sure I had
done that.

Never miiiiiind
 
"Rik Brooks" <[email protected]> a écrit dans le message de (e-mail address removed)...

| OOPS! I forgot to make vendor inherit from company. I thought for sure I
had
| done that.

Heheh, easily done.

BTW, you have derived Vendor from Company; what would you do if a Company
was also a Supplier ?

Many people have fallen into this trap of trying to use inheritance when it
isn't always wise. Just for your and other's information, this situation can
be overcome by using the concept of Roles :

class Role
{
...
}

class Vendor : Role
{
...
}

class Supplier : Role
{
...
}

class Company
{
public List<Role> Roles {...}
public bool FulfilsRole(Role role) {...}
...
}

Joanna
 
Joanna said:
"Rik Brooks" <[email protected]> a écrit dans le message de (e-mail address removed)...

| OOPS! I forgot to make vendor inherit from company. I thought for sure I
had
| done that.

Heheh, easily done.

BTW, you have derived Vendor from Company; what would you do if a Company
was also a Supplier ?

Many people have fallen into this trap of trying to use inheritance when it
isn't always wise. Just for your and other's information, this situation can
be overcome by using the concept of Roles :
Click to expand...

How about plain interfaces?
 
"Larry Lard" <[email protected]> a écrit dans le message de (e-mail address removed)...

| How about plain interfaces?

Well, they can be useful, but that would mean that, unless you have a list
of IRole, you have to tie a class like Company to implement IVendor and/or
ISupplier. This then means that you can't add a role without altering the
Company class to include a new role. Neither can the Company change roles or
drop a role. You have to consider the lifetime of a class and plan for the
possible changes in role without tying the class to a fixed set of roles.

You could declare an interface :

interface IRoleAdopter
{
void AddRole(Role role);
void RemoveRole(Role role);
bool Implements Role(Role role);
...
}

and then implement that in any class that needs it. But that may not really
make any difference from designing the classes with that support built in,
apart from the fact that you could build a delegate class that implements
the IRoleAdopter and that can be instantiated inside any class.

Joanna
 
Back
Top