form inheritance

[Guest]

Hi all,
Another beginner's question:
I want to have some common functionality to all my forms. The way I think of
doing this is to have some class that will inherit from a Form, and in this
class define the common functionality that I want, and all my forms will
inherit from this class.

For example:
public partial class MySpecialClass : Form
{
public static int MyintVariable;
private void Functionality()
{
//do some work
}
}

And all my forms will look something like this:
public partial class Form1 : MySpecialClass
{
public Form1()
{
InitializeComponent();
}
}

1. Is it a good way of doing this?
2. Do I need to define a constructor for MySpecialClass?

3. I don't need the graphic interface for MySpecialClass, I only need its
code. Where is the place to put code that does not belong to a form/graphic
interface ?

Thank you very much

 

[Scott M.]

Hi all,
Another beginner's question:
I want to have some common functionality to all my forms. The way I think
of
doing this is to have some class that will inherit from a Form, and in
this
class define the common functionality that I want, and all my forms will
inherit from this class.

For example:
public partial class MySpecialClass : Form
{
public static int MyintVariable;
private void Functionality()
{
//do some work
}
}

And all my forms will look something like this:
public partial class Form1 : MySpecialClass
{
public Form1()
{
InitializeComponent();
}
}

1. Is it a good way of doing this?

Not only is this a good way of doing this, it is the best way of doing
this... it's called "visual inheritance".

2. Do I need to define a constructor for MySpecialClass?

You don't *have* to, but constructors are great places to initialize values,
so adding one is a good idea.

3. I don't need the graphic interface for MySpecialClass, I only need its
code. Where is the place to put code that does not belong to a
form/graphic
interface ?

If you don't need the GUI, then why are you inheriting from a Form? You can
create your own methods & properties within the class and they will be
usable by any code that makes an instance of that class.

 

[Guest]

Thanks for your answer, Scott
As for constructors: yes, I understand what you say, I just wanted to be
sure. And another thing- if I have a constructor for MySpecialClass, and for
some of the other "regular" forms that constructor is good enough, then those
forms are better left without a constructor, am I right? (they use the
constructor of MySpecialClass).

As for the GUI- I'm inheriting from a Form because:
1.I don't know of a better thing to inherit from
2.I want my forms to inherit from that class

The thing is that I want my forms to have some functionalities which don't
belong to GUI. But I still want each of my forms to be a Form…

Yes, I can create MySpecialClass as an empty form, but I thought there is a
way to insert a class which is only code in some place that will be used by
the forms.

 

[Jon Skeet [C# MVP]]

Thanks for your answer, Scott
As for constructors: yes, I understand what you say, I just wanted to be
sure. And another thing- if I have a constructor for MySpecialClass, and for
some of the other "regular" forms that constructor is good enough, then those
forms are better left without a constructor, am I right? (they use the
constructor of MySpecialClass).

As for the GUI- I'm inheriting from a Form because:
1.I don't know of a better thing to inherit from
2.I want my forms to inherit from that class

The thing is that I want my forms to have some functionalities which don't
belong to GUI. But I still want each of my forms to be a Form?

Then use composition instead of inheritance. Make each of your forms
have a reference to an instance of MySpecialClass rather than *being*
an instance of MySpecialClass.

 

[Guest]

Thanks for your answer, Jon
Please explain to me in more details how to do your solution.
Please explain to me why is it better than my solution.
Thank you very much

 

[Scott M.]

Inline..

Thanks for your answer, Scott
As for constructors: yes, I understand what you say, I just wanted to be
sure. And another thing- if I have a constructor for MySpecialClass, and
for
some of the other "regular" forms that constructor is good enough, then
those
forms are better left without a constructor, am I right? (they use the
constructor of MySpecialClass).

Constructors aren't overridden like other methods with identical signatures
are. When an instance of any class is made, it's constructor is called.
Even if you haven't specified a constructor, the CLR will execute an empty
one for you. So, if something inherits from MySpecialClass (which does have
a constructor), but the something that is inheriting doesn't have one. then
MySpecialClass's constructor will still fire.

As for the GUI- I'm inheriting from a Form because:
1.I don't know of a better thing to inherit from
2.I want my forms to inherit from that class

Well, if you have other forms, then it makes sense to inherit from a form,
but in your last message, you said you didn't want a GUI. Forms are GUI's,
so I am a little confused as to what you are doing.

The thing is that I want my forms to have some functionalities which don't
belong to GUI. But I still want each of my forms to be a Form.

That's fine. A form can do whatever you want it to, regardless of whether
it's a GUI thing or not (however it's not necessarially good software design
to have the GUI doing non-GUI things. Generally, you'd break your code up
into tiers and have the GUI call (make instance of) another class that does
your business logic. What are the non-GUI things you need to do?

Yes, I can create MySpecialClass as an empty form, but I thought there is
a
way to insert a class which is only code in some place that will be used
by
the forms.

You can just create a new class from scratch and write your code into this
class (create the properties, methods and events you choose) and then just
make instances of this class from within your various forms to get the
functionality you need. This is a better way to code this, as it separates
your business logic from your UI and is more straightforward.

-Scott

 

[Jon Skeet [C# MVP]]

Thanks for your answer, Jon
Please explain to me in more details how to do your solution.

Create a class containing the logic you're interested in.

For each form which wants to be able to expose or use that logic,
create a member variable of the new type, and create a new instance of
it. Then call the appropriate methods on the instance where you need
to.

If you need to be able to expose the behaviour in a consistent manner,
create an interface which your forms can all implement, even if the
implementation is just proxying the work to your other forms.

Please explain to me why is it better than my solution.

It's not abusing inheritance. Your class isn't *really* a form - the
extra logic has nothing inherently to do with forms. The fact that you
have to derive from a form even if you don't want a form at all should
ring design alarm bells.

 

[Guest]

Thanks a lot to both of you, Jon and Scott
for your detailed explanation. I appreciate it a lot.
I'll try it soon.