Why is image and Bitmap a sealed class?

[Jon Slaughter]

Why did microsoft seal these classes? I would like to add coordinate
information to these classes but I can't derive from them ;/ It makes me
wonder why microsft choose to prevent anyone from deriving from many
classes.

I can simply do

class MyBitmap
{
public Bitmap B;
public Point Loc;
....
}

But why do they not want me to do

class MyBitmap : Bitmap
{
public Point Loc;
....
}

?

It seems to make it easier to work with the second case than the first and
I'm wondering what MS's motivation for doing what they did.

Thanks,
Jon

 

[Michael C]

Why did microsoft seal these classes? I would like to add coordinate
information to these classes but I can't derive from them ;/ It makes me
wonder why microsft choose to prevent anyone from deriving from many
classes.

I've asked this same questoion before because I wanted to add a property to
a bitmap just to tag some extra information along with it. The answer was it
is difficult to make a class inheritable. It exposes a lot of internal
functionality and the effects need to be taken into account. For example,
someone might override a method and returning an unexpected result could
cause a gpf, so they need to take this in to account to avoid a gpf. They
could have allowed it to be inheritable and provided no virtual or protected
methods but then everyone would complain about that.

Michael

 

[Guest]

Yep. Then you need to look into "Plan B". This might be, create a custom
class that has a Bitmap as a field,along with all the cool extra "Stuff" that
you want.
Peter

 

[Steven Nagy]

I've asked this same questoion before because I wanted to add a property to

a bitmap just to tag some extra information along with it. The answer was it
is difficult to make a class inheritable. It exposes a lot of internal
functionality and the effects need to be taken into account. For example,
someone might override a method and returning an unexpected result could
cause a gpf, so they need to take this in to account to avoid a gpf. They
could have allowed it to be inheritable and provided no virtual or protected
methods but then everyone would complain about that.

That seems to be a bit like saying "Lets remove the while loop because
someone could do a while(true) {}
While I appreciate that it wasn't actually your answer, I have to
believe that it should be up to the programmer to make those mistakes,
learn from them, and in turn become better at it, rather than just
restricting access to the inheritance of the class. Microsoft shouldn't
make my programming choices for me...

 

[Michael C]

That seems to be a bit like saying "Lets remove the while loop because
someone could do a while(true) {}
While I appreciate that it wasn't actually your answer,

In this case the result is not a gpf.

I have to
believe that it should be up to the programmer to make those mistakes,
learn from them, and in turn become better at it, rather than just
restricting access to the inheritance of the class. Microsoft shouldn't
make my programming choices for me...

One of the criterias for a component for .net appears to be that it should
be impossible to make it gpf (or at least difficult). This might not have
been possible if inheriting the bitmap class or might have been difficult.
On one hand I do agree that it's good to be able to do what you want it
would also be a pain to have a gpf on the odd occassion when an app was
released. That would be a complete bugger to find so I'd probably prefer to
have the non-inheritable bitmap.

That being said, I'd prefer to have a stable, inheritable bitmap

Michael

 

[sloan]

Aka,,,something along the lines of:
The Proxy Design Pattern.

http://www.dofactory.com/Patterns/PatternProxy.aspx