471,610 Members | 1,316 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,610 software developers and data experts.

overloading abstract type

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
}

--
----------------------------------------------------------------------
This is an unmonitored email account. Please do not reply directly to
this email. Common email account for NG by group of techies.
Dec 26 '05 #1
15 2532
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

Pohihihi wrote:
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
}

Dec 26 '05 #2
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?
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
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

Pohihihi wrote:
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
}

Dec 26 '05 #3
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]
- mv*@spam.guard.caspershouse.com

"Pohihihi" <no*****@hotmail.com> wrote in message
news:uE*************@TK2MSFTNGP15.phx.gbl...
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?
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
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

Pohihihi wrote:
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
}


Dec 26 '05 #4
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 [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:e1**************@tk2msftngp13.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Pohihihi" <no*****@hotmail.com> wrote in message
news:uE*************@TK2MSFTNGP15.phx.gbl...
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?
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
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

Pohihihi wrote:
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
}



Dec 26 '05 #5
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 wrote:
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.

Dec 26 '05 #6
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
Om**************@TK2MSFTNGP12.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Dec 26 '05 #7
Joanna,

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

Thank.

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:uC**************@TK2MSFTNGP14.phx.gbl...
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
Om**************@TK2MSFTNGP12.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer

Dec 26 '05 #8
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
ea**************@TK2MSFTNGP09.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Dec 26 '05 #9
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....."

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OZ*************@TK2MSFTNGP15.phx.gbl...
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
ea**************@TK2MSFTNGP09.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer

Dec 26 '05 #10
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
%2******************@TK2MSFTNGP14.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Dec 26 '05 #11
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.
"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:eH*************@TK2MSFTNGP15.phx.gbl...
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
%2******************@TK2MSFTNGP14.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer

Dec 27 '05 #12
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
%2***************@TK2MSFTNGP15.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Dec 27 '05 #13
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.
"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
%2***************@TK2MSFTNGP15.phx.gbl...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer

Dec 27 '05 #14
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
eJ***************@TK2MSFTNGP14.phx.gbl...

|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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Dec 27 '05 #15
I guess that is what I am left with. Thanks for working with me. I will
suggests this route as well tomorrow to others.
"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:ur**************@TK2MSFTNGP10.phx.gbl...
"Pohihihi" <no*****@hotmail.com> a écrit dans le message de news:
eJ***************@TK2MSFTNGP14.phx.gbl...

|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

--
Joanna Carter [TeamB]
Consultant Software Engineer

Dec 27 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Rob Long | last post: by
3 posts views Thread by pmatos | last post: by
4 posts views Thread by Tony Johansson | last post: by
1 post views Thread by Kristian Kjems | last post: by
4 posts views Thread by Andrew K | last post: by
10 posts views Thread by Joe | last post: by
9 posts views Thread by Sean Kirkpatrick | last post: by
reply views Thread by MichaelMortimer | last post: by
reply views Thread by CCCYYYY | last post: by
1 post views Thread by ZEDKYRIE | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.