Develop Reference

Change multiple inheritance into deriving from a template

Say I have a bunch of code for all controls, yet I need subclasses that interact with my software suite to use those common methods. I really want my subclass to derive from the control, not the class with the common code. (A MyEdit should derive from Edit, not from MyControl). Also, the suite interacts with controls using an interface which MyControl derives from. In order to do this in C++, I would use multi-inheritance like so
class MyEdit : public Edit, public MyControl;
class MyControl : public IControl;
However, I suddenly discover that I shouldn't use multi-inheritance if I want some controls to be C# which doesn't support multi-inhertiance.
So I thought I could do this...
class MyEdit : public MyControl<Edit>;
template class MyControl<Type> : public IControl;
Convert the common control stuff into a template, and give it the type of control I want to derive from.
However I'm not sure this will work, because the template templatizes Edit, but it doesn't necessarily create one does it? When I create the template will I actually be able to create the Edit?
And secondly, if this is possible, is it possible in C#? What would it look like?

I can't say I quite followed your question, but in regards to:
However I'm not sure this will work,
because the template templatizes Edit,
but it doesn't necessarily create one
does it? When I create the template
will I actually be able to create the
Edit?
I would go for
template<class Controlled_t>
class MyControl : public Controlled_t, public IControl
{
//My Control inherits from its templated class
}
so that
MyControl<Edit> inherits Edit (which is created) and the interface

In C#, a class can only inherit from one other class, but it can implement multiple Interfaces, so if you want a class that can override behavior for more than one polymorphic type at runtime, you have to use Interfaces. The drawback of Interfaces is that they have no properties or base method implementations, so you may have to duplicate some of the methods in classes that implement the same Interface.
Another, C#-y way to get polymorphic runtime behavior is by attaching delegates. A lot of times I've found that what looks like a multiple-inheritance situation is better expressed as a multicast-delegate situation.

Hide Virtual function In Inherited Class

I have a class that inherits from LinkButton and I want to hide OnClinentClick from my class.
Somthing like this :
public class MyClass : LinkButton
{
// some Code
}
And somewhere in code:
MyClass myclass = new MyClass();
MyClass.OnClinentClick = "";//this line must not be accessable

Hiding something from a class definition is not directly supported as it breaks OOP principles.
You could use the new operator, however, I wouldn't advise it. Personally, I would think about my design and/or use a NotSupportedException if there is no other way around it.

You can use the EditorBrowsableAttribute to prevent it from being suggested by IntelliSense, but you can't get rid of it entirely.
[EditorBrowsable(EditorBrowsableState.Never)]
public virtual string OnClientClick { get; set; }
C# only supports public inheritance. You shouldn't be inheriting from a class whose methods don't make sense for all derived classes. Consider composition instead of inheritance to solve this problem.

You can override the function (that is, replace the base implementation with your one, as long as the former is virtual), but you cannot completely prevent the clients from calling the base class function if you hide it with new, as they may always cast to the base class.
Update:
actually, you cannot change the access from public to protected/private when overriding, this won't compile (http://ideone.com/Y65Uh). Besides that, if you use new to hide the base function and make it uncallable, the original function is still visible (http://ideone.com/xiL2F). If you declare the new function public (which is perhaps not what you want), the old function can still be called by casting to the base class (http://ideone.com/A3Bji).

How about making giving it a lower visibility. One of protected and internal might be what you want. Of course that doesn't remove such a member from the derived class, but just removes them from the public interface. It also requires control over the base-class. No idea if LinkButton is one of your classes.
You could also hide the property by reintroducing a new one with the same. But that's a bad idea, and casting back to the base-class allows outsiders to access it.
And you should consider using a has-a relationship instead of an is-a. i.e. Don't derive from a base class if you don't want all its public members. This violates OOP principles such as that it should be possible to substitute the derived class where the base class is expected.
You could also override it, and make the setter throw a NotSupportedException. But that's ugly too because it will only show an error at runtime instead of compiletime. You can generate compile-time warnings with attributes such as the ObsoleteAttribute.

Is there a way to have a public method, which won't be inherited?

I have a class, with public API.
I have other classes who inherit from that class.
I do not make use of all the APIs inherited from the first class.
If I change the order of inheritance, then I have even more API methods I do not wish classes to inherit.
Languages: PHP and C#

If some method should not be in inherited class, you probably should not place its in base class.
Second class could implement some interface which has that method, or inherit by another class which has that method and is inherited by current base-class.

Is there any specific reason why you would want such method? I think you should consider putting the functionality you want your classes to inherit in an interface. Other functionality should be implemented as private methods.
Also consider breaking down the functionality into several classes and then using Composition instead of inheritance. If you use inheritance to compose complex class hierarchies, they will always be difficult to manage. You should favor composition over inheritance.

I would suggest you to use Decorator pattern.

If we call the base class B and the derived classes D1, D2...
Two approaches are:
Split B into two classes: the private implementation (abstract B) and the public methods (that you wish to hide in your other 2 classes), D3. So to "use" the base class you instantiate D3. Then D1,D2 only inherit the private implementation of B because the public interface for "B" is only available through D3. (If you still need some of the public functionality in D1,D2 but don't want it to be public, then simply add it as a private method od B, and then add a public proxy method in D3 that exposes it and simply calls down to the base class implementation.
Don't derive your classes from B. Embed an instance of B in D1,D2 and simply expose a new interface in those classes that only makes the "limited functionality" available.

I do not make use of all the APIs inherited from the first class
put those methods to a public sealed class
I have other classes who inherit from that class.
use Interface of base class with virtual methods for that.

Interface and base class mix, the right way to implement this

I have some user controls which I want to specify properties and methods for.
They inherit from a base class, because they all have properties such as "Foo" and "Bar", and the reason I used a base class is so that I dont have to manually implement all of these properties in each derived class.
However, I want to have a method that is only in the derived classes, not in the base class, as the base class doesn't know how to "do" the method, so I am thinking of using an interface for this. If i put it in the base class, I have to define some body to return a value (which would be invalid), and always make sure that the overriding method is not calling the base. method
Is the right way to go about this to use both the base class and an interface to expose the method? It seems very round-about, but every way i think about doing it seems wrong...
Let me know if the question is not clear, it's probably a dumb question but I want to do this right.
EDIT : Thanks to all the people with your excellent abstract suggestions, but this breaks the designer. If abstract was not a selectable option, what would you do?

Alternatively you could define the method as 'abstract' in the base class, which will not require the class to implement it. For example:
abstract class A
{
public abstract void B();
}
Of course this will force your base class to be abstract as well, but it sounds like this would work just fine for you.
See Abstract methods on MSDN.
Update
Since abstract is not an option for you due to designer issues, you could just define the method as part of your base class, and have it throw a NotImplementedException if it is called directly from the base class:
void DerivMethod()
{
// Must be implemented by derived class
throw new NotImplementedException();
}
Otherwise, using an interface would be fine, especially if the above leaves a bad taste in your mouth...

You should make your base class an Abstract class. Then the base class can implement the Interface by marking the method abstract.
http://msdn.microsoft.com/en-us/library/aa664435(VS.71).aspx

Mark the method as abstract in your base class. You'll be forced to implement it in the derived classes, but the base class will not need to have a method definition.

I agree with with others, but making your user control abstract has some issues for the designer. The designer will often not display the abstract user control.
I would implement the interface methods in the base class. You can throw a NotImplemented exception or Assert.Fail in the methods if you want to make sure the inheritors are overriding these methods properly.

Declare the function signature in the base class and use the "abstract" modifier.

Can I use Extension Methods to implement an Interface?

I would like a class to implement an interface, I do not want to change the original class (that would add undesired dependecies).
I know I could inherit from the class and make it's child implement these methods, but then I am faced with a problem how to convert the parent class (that come from the data / ORM) to this presentation class.
If I implement all the interface required methods, will it count as being that interface or not ?

No, it still won't count as implementing the interface.
Extension methods are nothing more than a way of calling static methods in a different kind of way. They don't affect object identity, inheritance etc at all.