overloading abstract type

  • Thread starter Thread starter Pohihihi
  • Start date Start date
P

Pohihihi

How can I overload abstract type method in child class?

e.g.

public abstract void BaseMethod()
{
// do something
}

// in child class
public override void BaseMethod(int i)
{
// do something
}
 
void BaseMethod(int) does not override void BaseMethod(); the signatures
are different. To implement abstract BaseMethod() use:

public override void BaseMethod() {}

If you want an abstract BaseMethod(int) then define that in the parent
class, then you can override it in the child class. Otherwise declare
it virtual in the child class if that's where you want this
specialization / overload to be defined.

--Bob
 
So basically what you are saying that if I want to overload a baseclass
method I need to declare is as vertual and not abstract in base abstract
class?

That works, second part of my problem is that it will show overloaded in
intellisence. Is there a way to hide base class method that are overloaded
and overridden to the users of my class? It is same assembly and namespace.
As far as I know it can't be, is that right?
 
No, if you declare it as virtual, you then have to provide an
implementation. You wanted to add another parameter altogether, which is
impossible, because the base class wouldn't know about this parameter list.

The second issue is a non-issue if you override a method. If you
overload a method, why do you want to hide the base class versions?

I think you need to look at your class design a little bit better, since
you are doing some pretty non-conventional stuff.

Hope this helps.
 
Base class is actually base of many other workable classes in my case (~50
child classes).
Now that base class is also used in few other child classes that are needing
special overloads that are not in base class (but still need to use base for
other stuff) and for human (and other given technical) reasons can't be
added in the base class as overloads. Basically in other child classes those
public overloads with params should not be visible and it is too late to go
back and change anything in this proj.

I am given the task for finding a way out.


Nicholas Paldino said:
No, if you declare it as virtual, you then have to provide an
implementation. You wanted to add another parameter altogether, which is
impossible, because the base class wouldn't know about this parameter
list.

The second issue is a non-issue if you override a method. If you
overload a method, why do you want to hide the base class versions?

I think you need to look at your class design a little bit better,
since you are doing some pretty non-conventional stuff.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Pohihihi said:
So basically what you are saying that if I want to overload a baseclass
method I need to declare is as vertual and not abstract in base abstract
class?

That works, second part of my problem is that it will show overloaded in
intellisence. Is there a way to hide base class method that are
overloaded and overridden to the users of my class? It is same assembly
and namespace. As far as I know it can't be, is that right?
 
Ah yes, the old "we've screwed it up, now you figure out how to save our
collective behinds" routine.

Once you introduce a public overload it becomes available to all
children of that class.

I don't know of a clean "way out", especially in .NET 1.1. In 2.0, the
concept of friend classes I understand has been extended in ways that
may or may not be useful in this situation but I haven't had time to
check it out. You could consider some sort of adapter pattern. None of
these are clean and none will contribute to the consistency,
maintainability, or simplicity of the system, unfortunately.

--Bob
 
"Pohihihi" <[email protected]> a écrit dans le message de (e-mail address removed)...

| Base class is actually base of many other workable classes in my case (~50
| child classes).
| Now that base class is also used in few other child classes that are
needing
| special overloads that are not in base class (but still need to use base
for
| other stuff) and for human (and other given technical) reasons can't be
| added in the base class as overloads. Basically in other child classes
those
| public overloads with params should not be visible and it is too late to
go
| back and change anything in this proj.

It sounds to me like you need to look at aggregation rather than
inheritance. You seem to be trying to apply different behaviour to some
classes but not others; this indicates that you should split the common
behaviours into classes that can be delegated to rather than trying to force
all "common" behaviour in one base class.

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

| I could have thought about it but please read the condition here.

| > | Base class is actually base of many other workable classes in my case
| > (~50
| > | child classes).
| > | Now that base class is also used in few other child classes that are
| > needing
| > | special overloads that are not in base class (but still need to use
base
| > for
| > | other stuff) and for human (and other given technical) reasons can't
be
| > | added in the base class as overloads. Basically in other child classes
| > those
| > | public overloads with params should not be visible and it is too late
to
| > go
| > | back and change anything in this proj.

I have read the conditions you state; that is why I suggest you look at
aggregation instead of inheritance.

Or do you not understand what I mean by aggregation ?

Joanna
 
No actually I am not understanding how it fits. Also please explain what you
mean by

"...this indicates that you should split the common
behaviours into classes that can be delegated to rather than trying to force
all "common" behaviour in one base class....."
 
"Pohihihi" <[email protected]> a écrit dans le message de %23KNG5%[email protected]...

| No actually I am not understanding how it fits. Also please explain what
you
| mean by
|
| "...this indicates that you should split the common
| behaviours into classes that can be delegated to rather than trying to
force
| all "common" behaviour in one base class....."

First create a class that defines the "essential" functionality :

public class BasicBehaviour
{
public void DoThis();
public void DoThat();
...
}

Then create additional classes that define other functionality that may or
may not be required in some classes :

public class AdditionalBehaviour
{
public void AdditionalStuff();
}

Then instead of deriving from a base class, simply include private fields of
the various types and write methods that redirect the calls to the delegate
objects stored in those private fields.

public class AClass
{
private BasicBehaviour basic = new BasicBehaviour();

private AdditionalStuff add = new AdditionalBehaviour();

public void DoThis()
{
basic.DoThis();
}

public void DoThat()
{
basic.DoThat();
}

public void AdditionalStuff()
{
add.AdditionalStuff();
}
}

You can now mix and match all sorts of different varieties of additional
bits without having to try and shoehorn them into a single base class.

Joanna
 
Solution is nice, and someone should should have done like that but then
still it do not solves my current problem of living with base class which we
have to use. Basically I am looking for a way to override base abstract
class that do not take arguments. I need to hide that and put my own
override to take an argument. I can't hide public methods in base class as
it is a derived class, and can't create object and use it internally in the
child class as base class is very full of stuff needed and it will be a
80-90 % rewrite of it. Also can't add method in base class.
 
"Pohihihi" <[email protected]> a écrit dans le message de %[email protected]...

| Solution is nice, and someone should should have done like that but then
| still it do not solves my current problem of living with base class which
we
| have to use. Basically I am looking for a way to override base abstract
| class that do not take arguments. I need to hide that and put my own
| override to take an argument. I can't hide public methods in base class as
| it is a derived class, and can't create object and use it internally in
the
| child class as base class is very full of stuff needed and it will be a
| 80-90 % rewrite of it. Also can't add method in base class.


Yes, aggregation does solve your problem in that it allows you to hide
properties/methods that are not suitable behind a wrapper class. If your
base class is abstract then simply derive from that and override all the
abstract stuff in a meaningful way, then include an instance of the derived,
non-abstract class in the wrapper class.

You cannot hide public methods, in the base class but you can use the
aggreagation technique to create a wrapper class which will allow you to
hide the entire declaration of the class and only expose what you want in
the wrapper class. You don't have to rewrite a whole class, just write
methods/properties in the wrapper class that access the base or derived,
non-abstract class

public abstract class BaseClass
{
public abstract void NoArgsMethod();
}

public class DerivedClass : BaseClass
{
public override void NoArgsMethod()
{
// empty method
}
}

public class WrapperClass
{
private BaseClass baseObj = new DerivedClass();

public void ArgsMethod(int arg, string anotherArg)
{
// do what you want, calling baseObj as required
}
}

Joanna
 
I understand now and some what still disagree with the solution. thing is
that users of Wrapper class are limited to what I show them using Wrapper
class and moreover I am still forced not to control DerivedClass in my
assembly. When users will do something like following
WrapperClassObject.SomeBaseClassMethod() then they can only do when it is
implemented in wrapper class. More over this bracks the derivation from
BaseClass. Means WrapperClassObject is not a typeof(BaseClass) anymore. This
in turn distroys the versioning of classes. Please feel free to correct me
if I am not understanding anything cause I am still looking for a positive
solution.
 
"Pohihihi" <[email protected]> a écrit dans le message de eJXa4%[email protected]...

|I understand now and some what still disagree with the solution. thing is
| that users of Wrapper class are limited to what I show them using Wrapper
| class and moreover I am still forced not to control DerivedClass in my
| assembly. When users will do something like following
| WrapperClassObject.SomeBaseClassMethod() then they can only do when it is
| implemented in wrapper class. More over this bracks the derivation from
| BaseClass. Means WrapperClassObject is not a typeof(BaseClass) anymore.
This
| in turn distroys the versioning of classes. Please feel free to correct me
| if I am not understanding anything cause I am still looking for a positive
| solution.

If you want to do things like hiding base public properties/methods, then
there is only one solution, a Wrapper class.

You have to either change the way you want to derive from and use the base
class, or you forego the benefits of having a class that derives from the
base class.

IMO, you have no other choices.

Joanna
 
I guess that is what I am left with. Thanks for working with me. I will
suggests this route as well tomorrow to others.
 
Back
Top