Inheritance - restrict methods etc.

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

Guest

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
 
Carlos,

Thanks for the information even though it's not what I had hoped for.

Art
 
Another approach is to override the methods/properties that you don´t want
to be used and in the overridden implementation throw a
NotImplementedException or similar. That would prevent the usage.

--

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

The only real thing I have found to get around this is to shadow the ones
you don't want to implement, hide them form the property browser and then do
that IMHO crappy hack to throw an NotImplimented exception when they are
used form code.

The only real way to get around this is to write your control completely
from scratch without inheriting from a base. Seems to make inheritance a bit
useless if you ask me.

I also don't like the fact that if you inherit from a base class, your
inherited classes must include code that implements each of the bases
constructors because constructors are not inherited. So this means that you
must write code that gives your inherited class each of the base classes
constructors with their signatures and then call their base class
counterparts. Seems to me that if you inherit form a base class and don't
include ANY constructers in your class then the fact that you want the bases
constructors bright forward to your inherited class is implied...

The whole inheritance thing seems a bit messy to me...
 
Ray Cassick said:
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.
Click to expand...

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
 
Art said:
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.
Click to expand...

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.
 
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.
 
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.
 
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.
 
Exactly.

Dennis said:
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.
Click to expand...
 
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
 
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.
 
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.
Click to expand...

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
 
Ray said:
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.
Click to expand...

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?
Click to expand...

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.
 
Dennis said:
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.
Click to expand...

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.
 
Cor Ligthert said:
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.
Click to expand...

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.
 
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
 
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
 
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.
 
You must log in or register to reply here.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Design Problem: Abstract Class inheriting from a List(Of AnotherAbstactClass) 4
Inheritance and COM 1
Class Design with Collection Classes 6
Help with inheritance problem 4
Inheritance Scoping 5
inherits class. 12
Custom Attributes, Shared methods, Derived classes and reflection 15
How would you translate this? 3

Back
Top