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]]

Re: Inheritance - restrict methods etc.

"Art" <Art@discussion s.microsoft.com > schrieb:[color=blue]
> 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.[/color]

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]

Re: Inheritance - restrict methods etc.

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]" <carlosq@NOSPAM sogecable.com> wrote in
message news:%23%23DMII kVFHA.3540@TK2M SFTNGP15.phx.gb l...[color=blue]
> "Ray Cassick" <rcassick@nospa m.enterprocity. com> escribió en el mensaje
> news:%23L1mH9jV FHA.1040@TK2MSF TNGP10.phx.gbl. ..[color=green]
> >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.[/color]
>
> 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[/color]
inherits[color=blue]
> 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
>
>[/color]

[Dennis]

Re: Inheritance - restrict methods etc.

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:
[color=blue]
> "Art" <Art@discussion s.microsoft.com > schrieb:[color=green]
> > 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.[/color]
>
> 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/>
>
>[/color]

[Dennis]

Re: Inheritance - restrict methods etc.

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:
[color=blue]
> "Ray Cassick" <rcassick@nospa m.enterprocity. com> escribió en el mensaje
> news:%23L1mH9jV FHA.1040@TK2MSF TNGP10.phx.gbl. ..[color=green]
> >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.[/color]
>
> 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
>
>
>[/color]

[Ray Cassick \(Home\)]

Re: Inheritance - restrict methods etc.

Exactly.

"Dennis" <Dennis@discuss ions.microsoft. com> wrote in message
news:7FDF7311-3D2F-4BEA-820B-96C97AF331EC@mi crosoft.com...[color=blue]
> 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:
>[color=green]
>> "Ray Cassick" <rcassick@nospa m.enterprocity. com> escribió en el mensaje
>> news:%23L1mH9jV FHA.1040@TK2MSF TNGP10.phx.gbl. ..[color=darkred]
>> >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.[/color]
>>
>> 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
>>
>>
>>[/color][/color]

[Cor Ligthert]

Re: Inheritance - restrict methods etc.

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]

Re: Inheritance - restrict methods etc.

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]]

Re: Inheritance - restrict methods etc.

Hi Dennis,
[color=blue]
> 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.[/color]

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_objMyBaseClas s As New BaseClass

Public Sub f1()
m_objMyBaseClas s.f1()
End Sub

' MyClass chooses not to expose f2 of BaseClass
' Public Sub f2()
' m_objMyBaseClas s.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]

Re: Inheritance - restrict methods etc.


Ray Cassick wrote:[color=blue]
> I agree on the entire 'contract' thing, but contracts CAN have fine[/color]
print :)[color=blue]
>
> If I want to create a new kind of car that for example can drive[/color]
itself[color=blue]
> based upon my brain waves then, given your example I should still[/color]
have to[color=blue]
> implement a steering wheel just because of the fact that I started[/color]
out with[color=blue]
> a car that had one.[/color]

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.
[color=blue]
>
> 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[/color]
out[color=blue]
> rewriting code that reimpliments all but the 1% that I want and use[/color]
that as[color=blue]
> a base class?[/color]

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]]

Re: Inheritance - restrict methods etc.

"Dennis" <Dennis@discuss ions.microsoft. com> schrieb:[color=blue]
>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.[/color]

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

Untested:

<Browsable(Fals e)> _
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]]

Re: Inheritance - restrict methods etc.

"Cor Ligthert" <notmyfirstname @planet.nl> schrieb:[color=blue]
> 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.[/color]

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]

Re: Inheritance - restrict methods etc.

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]]

Re: Inheritance - restrict methods etc.

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.Tex t
End Get
Set(ByVal Value As String)
Me.TextBox1.Tex t = 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" <Art@discussion s.microsoft.com > escribió en el mensaje
news:B5958E04-F41A-4BD6-A85B-094DF2611E85@mi crosoft.com...[color=blue]
> 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[/color]

[Ray Cassick]

Re: Inheritance - restrict methods etc.

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]" <carlosq@NOSPAM sogecable.com> wrote in
message news:uz2StvwVFH A.3572@TK2MSFTN GP12.phx.gbl...[color=blue]
> 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[/color]
that[color=blue]
> 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[/color]
example:[color=blue]
>
> Public Property MyText() As String
> Get
> Return Me.TextBox1.Tex t
> End Get
> Set(ByVal Value As String)
> Me.TextBox1.Tex t = 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" <Art@discussion s.microsoft.com > escribió en el mensaje
> news:B5958E04-F41A-4BD6-A85B-094DF2611E85@mi crosoft.com...[color=green]
> > 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[/color][/color]
MyTextBox.[color=blue][color=green]
> > 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[/color][/color]
MyTextBox.[color=blue][color=green]
> > I
> > will then instantiate MyTextBox as needed.
> >
> > There are lots of properties and methods that get inherited when I[/color][/color]
create[color=blue][color=green]
> > 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[/color][/color]
"is[color=blue][color=green]
> > a". Perhaps there's a better way to do this.
> >
> > Art[/color]
>
>[/color]