Inheritance - restrict methods etc.

[Art]

Hi,

I'd like to be able to create a class that inherits "Label". I want to
define a number of properties and methods for my new class.

The Question:
Can I prevent a user of this new class from accessing all of the properties
and methods of the base "Label" class. Some, like "Text" will need to be
available.

I'd appreciate any advice.

Art

[Herfried K. Wagner [MVP]]

"Art" <Ar*@discussions.microsoft.com> schrieb:

I'd like to be able to create a class that inherits "Label". I want to
define a number of properties and methods for my new class.

The Question:
Can I prevent a user of this new class from accessing all of the
properties
and methods of the base "Label" class. Some, like "Text" will need to be
available.

I an just curious why you would want to do that. Inheritance is used to
extend an existing class, and hiding methods of a base class stands in
conflict with this principle.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Ray Cassick]

I agree on the entire 'contract' thing, but contracts CAN have fine print :)

If I want to create a new kind of car that for example can drive itself
based upon my brain waves then, given your example I should still have to
implement a steering wheel just because of the fact that I started out with
a car that had one.

Perhaps I want to start off with a Car and derive a class that is a
completely different type of car? Does this mean that I have to start out
rewriting code that reimpliments all but the 1% that I want and use that as
a base class?

Again, while I agree that in its purest form, Inheritance does imply certain
things, but I also think that it can end up getting in the way a bit.
Especially if I plan to seal my class.
"Carlos J. Quintero [.NET MVP]" <ca*****@NOSPAMsogecable.com> wrote in
message news:%2******************@TK2MSFTNGP15.phx.gbl...

"Ray Cassick" <rc******@nospam.enterprocity.com> escribió en el mensaje
news:%2****************@TK2MSFTNGP10.phx.gbl...

I have tried to do this also.. People always seem to come back with that
standard 'breaks the rule of inheritance' thing that still does not sit
right with me.
If I want to inherit from a specific base class and seal my class so it
cannot be inherited from then there should not be any reason I HAVE to
implement and expose any of the base classes methods.
If you use inheritance, you are signing a contract, like when you say that
your class implements some interface. If your class is a Car which

inherits from Vehicle, you can not pretend that it has no wheels... all functions
expecting a Vehicle (of any derived class) will assume that it has wheels.
If that does not meet your needs, then you can not inherit, you must use
something else (such as encapsulation with delegation)

Inheritance can take some time to understand, but when you do, it makes
sense.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

[Dennis]

A good example is a class that inheirits from another class that handles it's
own binding and doesn't want to use the standard binding yet you still have
to handle the base class binding methods, etc.

It would be nice to have an attribute or some such for hiding base class
properties and methods that the user doesn't want. If one doesn't want to do
this, then just don't use this attribute.

"Herfried K. Wagner [MVP]" wrote:

"Art" <Ar*@discussions.microsoft.com> schrieb:

I'd like to be able to create a class that inherits "Label". I want to
define a number of properties and methods for my new class.

The Question:
Can I prevent a user of this new class from accessing all of the
properties
and methods of the base "Label" class. Some, like "Text" will need to be
available.

I an just curious why you would want to do that. Inheritance is used to
extend an existing class, and hiding methods of a base class stands in
conflict with this principle.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Dennis]

When I create a class that inherits form another class, I am writing my own
contract for my new class and should not be bound by a preconcieved notion of
what my new contract should look like.

"Carlos J. Quintero [.NET MVP]" wrote:

"Ray Cassick" <rc******@nospam.enterprocity.com> escribió en el mensaje
news:%2****************@TK2MSFTNGP10.phx.gbl...

I have tried to do this also.. People always seem to come back with that
standard 'breaks the rule of inheritance' thing that still does not sit
right with me.
If I want to inherit from a specific base class and seal my class so it
cannot be inherited from then there should not be any reason I HAVE to
implement and expose any of the base classes methods.

If you use inheritance, you are signing a contract, like when you say that
your class implements some interface. If your class is a Car which inherits
from Vehicle, you can not pretend that it has no wheels... all functions
expecting a Vehicle (of any derived class) will assume that it has wheels.
If that does not meet your needs, then you can not inherit, you must use
something else (such as encapsulation with delegation)

Inheritance can take some time to understand, but when you do, it makes
sense.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

[Ray Cassick \(Home\)]

Exactly.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:7F**********************************@microsof t.com...

When I create a class that inherits form another class, I am writing my
own
contract for my new class and should not be bound by a preconcieved notion
of
what my new contract should look like.

"Carlos J. Quintero [.NET MVP]" wrote:

"Ray Cassick" <rc******@nospam.enterprocity.com> escribió en el mensaje
news:%2****************@TK2MSFTNGP10.phx.gbl...

>I have tried to do this also.. People always seem to come back with that
> standard 'breaks the rule of inheritance' thing that still does not sit
> right with me.
> If I want to inherit from a specific base class and seal my class so it
> cannot be inherited from then there should not be any reason I HAVE to
> implement and expose any of the base classes methods.

If you use inheritance, you are signing a contract, like when you say
that
your class implements some interface. If your class is a Car which
inherits
from Vehicle, you can not pretend that it has no wheels... all functions
expecting a Vehicle (of any derived class) will assume that it has
wheels.
If that does not meet your needs, then you can not inherit, you must use
something else (such as encapsulation with delegation)

Inheritance can take some time to understand, but when you do, it makes
sense.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

[Cor Ligthert]

Dennis,

In my opinion do we see this behaviour in the standard controls as well. I
thought AFAIK that the text in the picturebox is nothing else than an extra
Tag.

In my opinion would it be nice as such a (probably shadowed property) could
be hidden.

Just my thought,

Cor

[c j anderson, mcp]

I agree with the other respondents on this point in that I do not
precisely understand why you want to hide certain properties or methods.
There are two solutions, however, to wit:
0) Move further up the inheritance chain (i.e. inherit from Control
rather than Label), or
1) Create a custom class with a private member of the type that you want
to extend. You can then write methods and properties that access the
private member. You will have to implement every method that you wish
to use, however. for a Windows Form Control, this is a lot of work, but
it can be done -- I doubt that the benefits of doing this are worth the
amount of pain that'll go into authoring the new class.

Cheers.
---
http://code.box.sk
nemo me impune lacessit

*** Sent via Developersdex http://www.developersdex.com ***

[Carlos J. Quintero [.NET MVP]]

Hi Dennis,

When I create a class that inherits form another class, I am writing my
own
contract for my new class and should not be bound by a preconcieved notion
of what my new contract should look like.

No, you are not writing a new contract from scratch, you are bound by the
clauses of the old one, because you are inheriting. You can override the
behaviour of the methods of the base class, but that's all, you can not
remove them. It is like when you declare:

Class MyClass
Implements IMyInterface

You must implement each method of IMyInterface, you can not, as much as you
wish, not to implement one of them.

Inheritance is the same, but you get the implementation, for free,
automatically without writing code, which you can override writing code if
you don´t like it. That's how inheritance works in OOP languages.

The alternative, which maybe meets your needs better, is to declare a class
that does not inherit from the base class but encapsulates it instead:

Class MyClass
Private m_objMyBaseClass As New BaseClass

Public Sub f1()
m_objMyBaseClass.f1()
End Sub

' MyClass chooses not to expose f2 of BaseClass
' Public Sub f2()
' m_objMyBaseClass.f2()
' End Sub

End Class

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

[Larry Lard]

Ray Cassick wrote:

I agree on the entire 'contract' thing, but contracts CAN have fine print :)
If I want to create a new kind of car that for example can drive itself based upon my brain waves then, given your example I should still have to implement a steering wheel just because of the fact that I started out with a car that had one.
If part of the definition of 'car' is 'has a steering wheel' then
logically anything without a steering wheel IS NOT a car and so should
not be (an instance of) a class derived from 'car'. I hate the phrase
but it's important to remember, as the books tell us, that inheritance
represents 'IS A' relationships.

Perhaps I want to start off with a Car and derive a class that is a
completely different type of car? Does this mean that I have to start out rewriting code that reimpliments all but the 1% that I want and use that as a base class?

If it's different enough that it's not actually a Car, don't derive
from Car. In your example above (like a car, but no steering wheel),
you might look for one of Car's parents to derive from -
WheeledVehicle, maybe.

--
Larry Lard
Replies to group please

[Herfried K. Wagner [MVP]]

"Dennis" <De****@discussions.microsoft.com> schrieb:

A good example is a class that inheirits from another class that handles
it's
own binding and doesn't want to use the standard binding yet you still
have
to handle the base class binding methods, etc.

It would be nice to have an attribute or some such for hiding base class
properties and methods that the user doesn't want. If one doesn't want to
do
this, then just don't use this attribute.

If the property is marked as 'Overridable', you can override it, mark the
overrided version as 'Browsable(False)' and throw an appropriate exception:

Untested:

<Browsable(False)> _
Public Overrides Property AutoScroll() As Boolean
Get
...
End Get
Set(ByVal Value As Boolean)
...
End Set
End Property
///

The main problem with this is that many methods are not marked as
'Overridable' although it would make sense.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Cor Ligthert" <no************@planet.nl> schrieb:

In my opinion do we see this behaviour in the standard controls as well. I
thought AFAIK that the text in the picturebox is nothing else than an
extra Tag.

Although it would sometimes make sense to hide inherited methods from the
user, removing them would not make sense because it would break the
principle of extension by inheritance. Consider a variable of type
'Control' containing a reference to a picturebox control. The 'Control'
variable will always show the 'Text' property because 'Control' has such a
property and because of inheritance all inherited controls will have such a
property too.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Art]

Hi,

FIrst, just in case it's not obvious to everyone, I'm something of a novice
at this.

Now, what is it that I'm trying to do...

I want to create my own group of controls (Base Classes), like MyTextBox.
This is for a particular group of projects I'm working on. I will add some
properties and methods to the TextBox control in order to make MyTextBox. I
will then instantiate MyTextBox as needed.

There are lots of properties and methods that get inherited when I create
MyTextBox. Many of these will not be needed -- and may confuse things. What
I ultimately want is a TextBox control that has my additional properties and
methods, but does not encourage the use of properties and methods of the base
class that do not have applicability in this project.

I understand what some of the folks are saying about inheritence being "is
a". Perhaps there's a better way to do this.

Art

[Carlos J. Quintero [.NET MVP]]

Then inheritance won´t meet your needs in this case. You have to create
MyTextBox encapsulating (not inheriting) a TextBox. That's the only way that
was possible in VB6 (which lacked inheritance) and it is so:

- You create a Window Usercontrol and name it MyTextBox
- Put a TextBox control (TextBox1) in the designer surface and add code to
resize it whenever the size of the usercontrol changes or use the Anchor
property
- Add code to expose the properties and methods that you want. For example:

Public Property MyText() As String
Get
Return Me.TextBox1.Text
End Get
Set(ByVal Value As String)
Me.TextBox1.Text = Value
End Set
End Property

Notice that your MyTextBox control inherits from Usercontrol (exposing its
properties) but does not inherit from TextBox (and therefore it lacks the
MaxLength property, for example).

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

"Art" <Ar*@discussions.microsoft.com> escribió en el mensaje
news:B5**********************************@microsof t.com...

Hi,

FIrst, just in case it's not obvious to everyone, I'm something of a
novice
at this.

Now, what is it that I'm trying to do...

I want to create my own group of controls (Base Classes), like MyTextBox.
This is for a particular group of projects I'm working on. I will add
some
properties and methods to the TextBox control in order to make MyTextBox.
I
will then instantiate MyTextBox as needed.

There are lots of properties and methods that get inherited when I create
MyTextBox. Many of these will not be needed -- and may confuse things.
What
I ultimately want is a TextBox control that has my additional properties
and
methods, but does not encourage the use of properties and methods of the
base
class that do not have applicability in this project.

I understand what some of the folks are saying about inheritence being "is
a". Perhaps there's a better way to do this.

Art

[Ray Cassick]

How much overhead does this method add to a control though? It seems like it
adds some additional resource overhead because you are now really including
two controls for every one that you place on a form.

How does this impact thins like tab order and focus as well?

I am not trying to say it is bad, I am just trying to get straight some
alternatives here.
"Carlos J. Quintero [.NET MVP]" <ca*****@NOSPAMsogecable.com> wrote in
message news:uz**************@TK2MSFTNGP12.phx.gbl...

Then inheritance won´t meet your needs in this case. You have to create
MyTextBox encapsulating (not inheriting) a TextBox. That's the only way that was possible in VB6 (which lacked inheritance) and it is so:

- You create a Window Usercontrol and name it MyTextBox
- Put a TextBox control (TextBox1) in the designer surface and add code to
resize it whenever the size of the usercontrol changes or use the Anchor
property
- Add code to expose the properties and methods that you want. For example:
Public Property MyText() As String
Get
Return Me.TextBox1.Text
End Get
Set(ByVal Value As String)
Me.TextBox1.Text = Value
End Set
End Property

Notice that your MyTextBox control inherits from Usercontrol (exposing its
properties) but does not inherit from TextBox (and therefore it lacks the
MaxLength property, for example).

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

"Art" <Ar*@discussions.microsoft.com> escribió en el mensaje
news:B5**********************************@microsof t.com...

Hi,

FIrst, just in case it's not obvious to everyone, I'm something of a
novice
at this.

Now, what is it that I'm trying to do...

I want to create my own group of controls (Base Classes), like MyTextBox. This is for a particular group of projects I'm working on. I will add
some
properties and methods to the TextBox control in order to make MyTextBox. I
will then instantiate MyTextBox as needed.

There are lots of properties and methods that get inherited when I create MyTextBox. Many of these will not be needed -- and may confuse things.
What
I ultimately want is a TextBox control that has my additional properties
and
methods, but does not encourage the use of properties and methods of the
base
class that do not have applicability in this project.

I understand what some of the folks are saying about inheritence being "is a". Perhaps there's a better way to do this.

Art

[Carlos J. Quintero [.NET MVP]]

> How much overhead does this method add to a control though? It seems like

it
adds some additional resource overhead because you are now really
including
two controls for every one that you place on a form.
Not much really, and it is one of the 3 well known techniques to create new
controls, "Composite controls", is called. See

Windows Forms Control Development Basics
http://msdn.microsoft.com/library/de...mentbasics.asp
How does this impact thins like tab order and focus as well?

I have not tested it, but it should be explained in the docs. In your case,
with only one control, it should be easy to handle, if some handling is
needed at all.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

[Ray Cassick \(Home\)]

Yeah, I know all about composite controls... I just never really considered
doing it for the case of one control before...
"Carlos J. Quintero [.NET MVP]" <ca*****@NOSPAMsogecable.com> wrote in
message news:eO****************@tk2msftngp13.phx.gbl...

How much overhead does this method add to a control though? It seems like
it
adds some additional resource overhead because you are now really
including
two controls for every one that you place on a form.

Not much really, and it is one of the 3 well known techniques to create
new controls, "Composite controls", is called. See

Windows Forms Control Development Basics
http://msdn.microsoft.com/library/de...mentbasics.asp

How does this impact thins like tab order and focus as well?

I have not tested it, but it should be explained in the docs. In your
case, with only one control, it should be easy to handle, if some handling
is needed at all.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com