C# From inherit both interface and abstract class.

Question

2.00/5 (1 vote)

See more:

Hi, Long story short.. I would like to create many windows (Form classes), that ofc has to inherit Form.cs class. But I want also, that every window will implement interface (so basically, list of necessary methods to implement) and inherit abstract class (so some of methods (necessary or not), will have default behavior).

Sth like that: Interface -> Abstract class -> MyForm (which inherits Form class).

Could you tell me what is the best way to implements such a combination ?

Posted 16-Jul-12 9:06am

mnd017

Add a Solution

Comments

Sergey Alexandrovich Kryukov 16-Jul-12 20:15pm

"Best way" assumes there are more than one? Could you explain at least two?
--SA

charles henington 17-Jul-12 0:13am

Have a look at this http://www.codeproject.com/Articles/98598/How-I-explained-Design-Patterns-to-my-wife-Part-1

3 solutions

Solution 3

C#

public abstract class MyAbstractClass : Form, MyInterface
    { 
        public MyAbstractClass()
        { 
        }
    }
    public interface MyInterface
    { 
    
    }
    public class MyFormClass : MyAbstractClass
    {
        public MyFormClass()
        { 
        
        }
    }

Posted 16-Jul-12 18:17pm

charles henington

Comments

mnd017 17-Jul-12 3:05am

Yes, but in this case I cannot open designer view :/

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2012-07-16T09:12:00

Solution 1

There is only one way: to create an abstract class that inherits Form, and derive your form from that. It can then also implement the interfaces.

You cannot derive from an abstract class and the Form class together - the inheritance hierarchy only allows the one base class, abstract or not.

BTW: Have a good look at google before you inherit directly from the abstract class, or you will start swearing. The VS designer will not allow you to display forms (or other controls) based on abstract classes - you have to derive it to a non-abstract class before your form inherits it. :mad:

[edit]Added VS designer behaviour - OriginalGriff[/edit]

Posted 16-Jul-12 9:12am

OriginalGriff

Updated 16-Jul-12 9:14am

v2

Comments

mnd017 16-Jul-12 15:53pm

Omg, u right, i cannot display it. But when I add another class.. i can. Like that:
public interface IInterface
{
void Func();
}
public abstract class AbsFunc : Form, IInterface
{
public virtual void Func()
{
}
}

public class AnotherClass: AbsFunc
{
// do nothing
}

public partial class MyForm : AnotherClass
{
public override void Func()
{
}
}

But, is it good programming practice?

Sergey Alexandrovich Kryukov 16-Jul-12 20:25pm

This is good enough, but it's better to use explicit interface implementation (you use implicit here) which should call a virtual method which will be overridden, but the implementation itself is not virtual. It depends on how complex is your assembly in general...
--SA

OriginalGriff 17-Jul-12 3:24am

It is a total PITA. It catches me out about once every couple of months with UserControls and makes me want to hunt down the developer who caused in back in VS2005 and pull lumps off his anatomy. :mad:

There is a method on the web which allows you to indirectly derive only if you are in development by using #IF DEBUG on your class definition and selecting a non-abstract version of your abstract class for release, but I don't like it, since it means that the code you release is not the code your tested against in development. So I live with the indirect abstraction and mumble curse at MS employees...

mnd017 17-Jul-12 3:49am

So, you would accept my comment as a good programming practice, or not? I'm a little bit confused..

OriginalGriff 17-Jul-12 4:04am

It's not good practice, but no solution is: You are bodging round a VS problem, so there is no "clean" solution.
I create a non-abstract version of the abstract class and inherit from that, with appropriate commenting - you are doing much the same, but I would add a pile of comments to explain why it exists so that you don't remove it in six months time...:laugh:
Personally, I would leave the Interface until I implemented the Form, unless the abstract class needed it.

mnd017 17-Jul-12 5:14am

Yes, I abandoned my 'abstract class' idea. Right now I have a simple MyFrom class, that inherit From and some interfaces. Inside MyForm I've created some controls, implements some events and methods. And when I create new From I inherit this MyForm. Is that good solution ?
Actually, my main goal was to separate view from behavior as much as I can, but right now I'm not sure what is gonna happen with that project.

OriginalGriff 17-Jul-12 5:21am

It difficult to say without knowing a lot of detail about your project, but abstracts are so useful that I get on with it and work round the designer problem.

It is a very good idea to separate the view from the behaviour - I generally try to keep them in separate projects (PL and BL with DL) :laugh:

mnd017 17-Jul-12 7:16am

So you actually do empty non-abstract, doing nothing class, just to be able to see designer view, right?

OriginalGriff 17-Jul-12 7:26am

Yes. Grrrrr!
Normally I tack the text "NonAbstract" in front of the class name:
"NonAbstractAddressSource" for the abstract "AddressSource" class to make it a bit clearer.

mnd017 17-Jul-12 8:15am

ok, thanks :)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-07-16T14:21:00

Please see my comment.

I mean, on second though, I can share a very beneficial coding style, when it comes to implementing some interfaces, especially good with forms. This style is based on the fact that partial class declaration requires each element in the list of base classes or interfaces only once. It means, you should not to repeat any of them. This gives you the opportunity to separate different aspects of the class. In particular, the parts related to implementation of each interface, could be in separate files. Like this:

C#

public partial class MyForm : System.Windows.Forms.Form { /* ... */ }

internal interface IFirst { /* ... */ } // practically, never public...

internal interface ISecond { /* ... */ } //...because forms are rarely accessed from another assembly

public partial class MyForm : IFirst { /* implement IFirst here... */ } //no need to mention base class Form or ISecond

public partial class MyForm : ISecond { /* implement ISecond here... */ } //no need to mention base class Form or IFirst

—SA

C# From inherit both interface and abstract class.

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

C# From inherit both interface and abstract class.

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

Existing Members

...or Join us