We Keep Coding

instantiating two unrelated subclasses using factory design pattern?

As per my understanding, We can use factory if we have same method implemented by subclasses, something like this
interface IAnimal
{
void Eat();
}
class Bird : IAnimal
{
public void Eat()
{
// bird eats grain
}
}
class Tiger : IAnimal
{
public void Eat()
{
// Tiger eats meat
}
}
our factory
class AnimalFactory
{
public IAnimal GetInstance(int type)
{
// dependind on type we can return
// animal
}
}
but what if we have another different method in the subclasses like Fly() in Bird class and Walk() in Tiger class?
class Bird : IAnimal
{
public void Eat()
{
// bird eats grain
}
public void Fly()
{
}
}
class Tiger : IAnimal
{
public void Eat()
{
// Tiger eats meat
}
public void Walk()
{
}
}
What is the best way to implement? I think, since subclasses do not implement completely one interface, so we should not use a factory design pattern? Of course we can still use and client can use Fly() and Walk() method by casting it back to the respective classes.
But my question is, is this still a valid use case for implementing factory design pattern?
Is my understanding correct?

If you are using a factory and the calling code cares whether the returned animal can fly or walk, then the factory needs to return a more-derived type.
interface IAnimal { void Eat(); }
interface IFlyingAnimal : IAnimal { void Fly(); }
interface IWalkingAnimal : IAnimal { void Walk(); }
class Tiger : IWalkingAnimal
{
public void Eat() { }
public void Walk() { }
}
class Bird : IFlyingAnimal
{
public void Eat() { }
public void Fly() { }
}
// The factory lets the caller choose which type of animal it wants:
class AnimalFactory
{
public IFlyingAnimal GetFlyingAnimal() { return new Bird(); }
public IWalkingAnimal GetWalkingAnimal() { return new Tiger(); }
}
// or, you can use separate factories:
class FlyingAnimalFactory
{
public IFlyingAnimal Get() { return new Bird(); }
}
class WalkingAnimalFactory
{
public IWalkingAnimal Get() { return new Tiger(); }
}
This may or may not be the right solution, depending on the code you are writing. You should choose a pattern that fits your needs.
Your original factory accepts an int type parameter, which makes me think the calling code probably knows it needs a Tiger or a Bird. So other solutions might be to not use a factory, or have the factory return a Tiger specifically:
public void AnimalFactory
{
public Tiger GetTiger() { return new Tiger(); }
public Bird GetBird() { return new Bird(); }
}

How can we use default implementation of different interfaces?

As I know, I need to upcast an instance of an inherited class to the interface where a needed method is implemented and then call it.
interface IProcess
{
void Do() { Console.WriteLine("doing"); }
//...
}
interface IWait
{
void Wait() { Console.WriteLine("waiting"); }
//...
}
class Example : IProcess, IWait { }
static void Main(string[] args)
{
Example item = new Example();
(item as IProcess).Do();
(item as IWait).Wait();
}
What if there are few interfaces with default implementation of different methods that I need? Is there some pattern that can solve this or maybe I should always use as keyword to call a method of a certain interface?

Another option in addition to #DavGarcia's answer - introduce an interface combining the needed ones and upcast to it:
interface IExample : IProcess, IWait { }
class Example : IExample { }
IExample item = new Example();
item.Do();
item.Wait();

If you are only calling the method once, I would do it like below. As ugly as it is, it is correct.
((IProcess)item).Do();
There are some other options that may be cleaner if you need to call more than once. You can convert to the interface:
IProcess itemProcess = item;
itemProcess.Do(); // Now call many times.
Usually though, I think you would be passing the object into a function that expects the interface:
void DoSomething(IProcess itemProcess) {
itemProcess.Do();
}
DoSomething(item);

You can override the methods in the implementing class and pass through control to the default implementation.
interface IProcess
{
void Do() { Console.WriteLine("doing"); }
}
interface IWait
{
void Wait() { Console.WriteLine("waiting"); }
}
class Example : IProcess, IWait
{
public void Do() => ((IProcess)this).Do();
public void Wait() => ((IWait)this).Wait();
}
Now you can do this:
static void Main(string[] args)
{
Example item = new Example();
item.Do();
item.Wait();
}

Should I include all the interfaces in the inheritance chain?

If I have two interfaces:
interface IGrandparent
{
void DoSomething();
}
interface IParent : IGrandparent
{
void DoSomethingElse();
}
then there are two implementations:
//only includes last interface from the inheritance chain
public class Child1 : IParent
{
public void DoSomething()
{
throw new NotImplementedException();
}
public void DoSomethingElse()
{
throw new NotImplementedException();
}
}
// includes all the interfaces from the inheritance chain
public class Child2 : IGrandparent, IParent
{
public void DoSomething()
{
throw new NotImplementedException();
}
public void DoSomethingElse()
{
throw new NotImplementedException();
}
}
Are these two implementations identical? (except the class name)? Some people say there are something to do with "implicit and explicit implementation", would some one explain why? I have seen Child2 style more than the other one.

Implicit interface implementation takes place when there is no conflicting method names from diffirent interfaces, and it is the common case.
Excplicit, on the other hand, is when there are conflicting method names, and at this point you have to specify which interface implements in the method.
public interface IFoo
{
void Do(); // conflicting name 1
}
public interface IBar
{
void Do(); // conflicting name 2
}
public class FooBar : IFoo, IBar
{
void IFoo.Do() // explicit implementation 1
{
}
void IBar.Do() // explicit implementation 1
{
}
}
Notice that excplicitly implemented interface methods cannot be public.
Here you can read more about explicit interface implementation.
Talking about your specific example. You can safely use only IParent. Even if you would like to use excplicit interface implementation, you still can do it without specifically mentioning IGrandparent in class declaration.
interface IGrandparent
{
void DoSomething();
}
interface IParent : IGrandparent
{
void DoSomethingElse();
void DoSomething();
}
public class Child : IParent
{
void IGrandparent.DoSomething()
{
}
public void DoSomethingElse()
{
}
public void DoSomething()
{
}
}
EDIT: As Dennis pointed out, there are several other cases of explicit interface implementation usage, including interface re-implementation. I found very good reasoning for implicit vs explicit interface implementation usages in here (you may also want to check out the whole thread, it's fascinating).

They are identical.
This is not about explicit interface implementation, because one can implement interface explicitly using both Child1 and Child2 styles, e.g.:
public class Child2 : IGrandparent, IParent
{
void IGrandparent.DoSomething()
{
throw new NotImplementedException();
}
public void DoSomethingElse()
{
throw new NotImplementedException();
}
}
public class Child1 : IParent
{
void IGrandparent.DoSomething()
{
throw new NotImplementedException();
}
public void DoSomethingElse()
{
throw new NotImplementedException();
}
}
Note, that this shouldn't be confused with interface re-implementation within class hierarchy:
public class Child1 : IParent
{
public void DoSomething()
{
Console.WriteLine("Child1.DoSomething");
}
public void DoSomethingElse()
{
Console.WriteLine("Child1.DoSomethingElse");
}
}
public class Child2 : Child1, IGrandparent
{
// Child2 re-implements IGrandparent
// using explicit interface implementation
void IGrandparent.DoSomething()
{
Console.WriteLine("Child2.DoSomething");
}
}
I'd avoid Child2 style. It's just a visual trash. Moreover, if IGrandparent isn't your responsibility, then sometime you will get this:
interface IGrandparent : ICthulhu { ... }
Do you want to update your code this way:
public class Child2 : ICthulhu, IGrandparent, IParent { ... }
?

Is there a more elegant way to do this in .NET 4.0?

It appears that C# 4.0 does not support covariance (using the "in" keyword) on parameters in overrides; is that the case?
If so, is there a more elegant way to do this?
CONTEXT
public interface IBaseEvent { /* ... */ }
public interface IDerivedEvent : IBaseEvent { /* ... */ }
public class MoreDerivedEvent : IDerivedEvent { /* ... */ }
I have a set of classes that handle MoreDerivedEvent. Due to limitations of the event handling code, I can only register a single event handler for MoreDerivedEvent, and I don't know that it will handle registering interfaces as events (I don't believe it will, as the guidance is to use classes explicitly). So, in order to handle the event appropriately, I've defined the handlers as follows:
public class BaseType
{
protected virtual void Handle(IBaseEvent #event) { /* Do Base Stuff */ }
}
public class DerivedType
{
protected virtual void Handle(IDerivedEvent #event)
{
/* Do Derived Stuff */
Handle((IBaseEvent)#event);
}
protected override sealed void Handle(IBaseEvent #event)
{
base.Handle(#event);
}
}
This obviously does not provide true inheritance, and I'll probably just flatten the types derived from DerivedType and BaseType if I can't solve this issue. But I figured I'd put it to the Stack Overflow community first.

First off, parameter type covariance is not typesafe. Suppose we allowed parameter type covariance:
class B
{
public virtual void Frob(Animal a)
{
}
}
class D : B
{
public override void Frob(Giraffe g)
{
}
}
....
B b = new D();
b.Frob(new Tiger()); // Calls D.Frob, which takes a giraffe.
No, covariance is not at all what you want. It is unsafe. You want covariance on return types, not on parameter types. On parameter types you want contravariance:
class B
{
public virtual void Frob(Giraffe g)
{
}
}
class D : B
{
public override void Frob(Animal a)
{
}
}
....
B b = new D();
b.Frob(new Giraffe()); // Calls D.Frob, which takes any animal.
No problem there.
Unfortunately for you, C# supports neither return type covariance nor parameter type contravariance. Sorry!

First you need an interface to specify the contra-variance on
public interface IBaseHandler<in T> where T : IBaseEvent
{
void Handle(T handle);
}
Then you can define a base class to do 'base stuff'
public class BaseType<T> : IBaseHandler<T> where T : IBaseEvent
{
public virtual void Handle(T handle) { /* do base stuff */}
}
which will then allow you to override for the MoreDerivedEvent
public class MoreDerivedType : BaseType<MoreDerivedEvent>
{
public override void Handle(MoreDerivedEvent handle)
{
base.Handle(handle);
}
}

Is there a way to hide the methods partially in child classes?

This question seems weird, but i came across this question in one of the interviews recently.
I ve been asked, is there a way in c# to hide the methods partially in a inherited child classes?. Assume the base class A, exposed 4 methods. Class B implements A and it will only have the access to first 2 methods and Class C implements A will only have the access to last 2 methods.
I know we can do this way
public interface IFirstOne
{
void method1();
void method2();
}
public interface ISecondOne
{
void method3();
void method4();
}
class baseClass : IFirstOne, ISecondOne
{
#region IFirstOne Members
public void method1()
{
throw new NotImplementedException();
}
public void method2()
{
throw new NotImplementedException();
}
#endregion
#region ISecondOne Members
public void method3()
{
throw new NotImplementedException();
}
public void method4()
{
throw new NotImplementedException();
}
#endregion
}
class firstChild<T> where T : IFirstOne, new()
{
public void DoTest()
{
T objt = new T();
objt.method1();
objt.method2();
}
}
class secondChild<T> where T : ISecondOne, new()
{
public void DoTest()
{
T objt = new T();
objt.method3();
objt.method4();
}
}
But what they wanted is different. They wanted to hide these classes on inheriting from baseclasses. something like this
class baseClass : IFirstOne, ISecondOne
{
#region IFirstOne Members
baseClass()
{
}
public void method1()
{
throw new NotImplementedException();
}
public void method2()
{
throw new NotImplementedException();
}
#endregion
#region ISecondOne Members
public void method3()
{
throw new NotImplementedException();
}
public void method4()
{
throw new NotImplementedException();
}
#endregion
}
class firstChild : baseClass.IFirstOne //I know this syntax is weird, but something similar in the functionality
{
public void DoTest()
{
method1();
method2();
}
}
class secondChild : baseClass.ISecondOne
{
public void DoTest()
{
method3();
method4();
}
}
is there a way in c# we can achieve something like this...

I did it by having 1 main base class and 2 sub bases.
// Start with Base class of all methods
public class MyBase
{
protected void Method1()
{
}
protected void Method2()
{
}
protected void Method3()
{
}
protected void Method4()
{
}
}
// Create a A base class only exposing the methods that are allowed to the A class
public class MyBaseA : MyBase
{
public new void Method1()
{
base.Method1();
}
public new void Method2()
{
base.Method2();
}
}
// Create a A base class only exposing the methods that are allowed to the B class
public class MyBaseB : MyBase
{
public new void Method3()
{
base.Method3();
}
public new void Method4()
{
base.Method4();
}
}
// Create classes A and B
public class A : MyBaseA {}
public class B : MyBaseB {}
public class MyClass
{
void Test()
{
A a = new A();
// No access to Method 3 or 4
a.Method1();
a.Method2();
B b = new B();
// No Access to 1 or 2
b.Method3();
b.Method4();
}
}

Although you can't do exactly what you want, you could use explicit interface implementation to help, in which the interface members are only exposed if it is explicitly cast to that interface...

Perhaps the interviewer may have been referring to method hiding?
This is where you declare a method with the same signature as on in your base class - but you do not use the override keyword (either because you don't or you can't - as when the method in the base class is non-virtual).
Method hiding, as opposed to overriding, allows you to define a completely different method - one that is only callable through a reference to the derived class. If called through a reference to the base class you will call the original method on the base class.

Don't use inheritance. It makes the public or protected facilities of the base class available directly in the derived class, so it simply isn't want you want.
Instead, make the derived class implement the relevant interface, and (if necessary) forward the methods on to a private instance of the underlying class. That is, use composition (or "aggregation") instead of inheritance to extend the original class.
class firstChild : IFirstOne
{
private baseClass _owned = new baseClass();
public void method1() { _owned.method1(); }
// etc.
}
By the way, class names should start with an upper case letter.

There is 2 solutions to hide methods inherited from a base class:
As mentioned by thecoop, you can explicitely implement the interface declaring the methods you want to hide.
Or you can simply create these methods in the base class (not inherited from any interface) and mark them as private.
Regards.

What about injecting base class as an IFirst?
interface IFirst {
void method1();
void method2();
}
interface ISecond {
void method3();
void method4();
}
abstract class Base : IFirst, ISecond {
public abstract void method1();
public abstract void method2();
public abstract void method3();
public abstract void method4();
}
class FirstChild : IFirst {
private readonly IFirst _first;
public FirstChild(IFirst first) {
_first = first;
}
public void method1() { _first.method1(); }
public void method2() { _first.method2(); }
}
Injection keeps you from violating the Interface Segregation Principle. Pure inheritance means that your FirstChild is depending on an interface that it doesn't use. If you want to retain only the IFirst functionality in Base, but ignore the rest of it, then you cannot purely inherit from Base.