how to use interface and purpose of casting?

Question

i have used interface in both cases. is it my first case use interface ?? here is the my interface and class

interface IAddition {
    int Add();
}

interface IMultiplication {
    int Multiplication();
}

it is my class

public class Calculation : IAddition, IMultiplication {
    int x, y;
    public Calculation(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int Add() {
        return (x + y);
    }
    public int Multiplication() {
        return (x * y);
    }
} 

1st case is this

class Program {
    static void Main(string[] args) {
        Calculation cal = new Calculation(20, 30);
        Console.WriteLine("Sum is= " + cal.Add());
        Console.WriteLine("Multiplication is= " + cal.Multiplication());
        Console.ReadKey();
    }
}

And 2nd case is this

class Program {
    static void Main(string[] args) {
        Calculation cal = new Calculation(20, 30);
        IAddition add = (IAddition)cal;
        IMultiplication mul = (IMultiplication)cal;
        Console.WriteLine("Sum is= " + add.Add());
        Console.WriteLine("Multiplication is= " + mul.Multiplication());
        Console.ReadKey();
    }
}

What is the purpose of these 2 lines ??? here what is the purpose of casting ?? Although 1st case have same output

IAddition add = (IAddition)cal;
IMultiplication mul = (IMultiplication)cal;

Answer 1

how to use interface

There are many ways to use an inteface, from implementation to type-checking.

// Definition of interface or sometimes referred to as "Contract"
// Implementing classes must define these methods and properties
public interface IMyInterface
{
  void MyMethod();
  int MyProperty { get; }
}


// Implementation or sometimes referred to as "Concrete type"
public class MyClass : IMyInterface
{
  public void MyMethod();
  public int MyProperty { get; set; }
}

// Compile time type checking:
public void MyMethod<T>(T value)
  where T : IMyInterface
{ }

// Runtime checking
public void MyMethod(object someobject)
{
  var myinterface = someobject as IMyInterface;
  if (myinterface != null)
  {
    //someobject implements IMyInterface so I can do things with it
    someobject.MyMethod();
  }
}

and purpose of casting?

The purpose of casting is has many uses. I'll mostly be demonstrating use the as keyword because it provides type-safety for the run-time.

You can use it to validate a type implements an interface at run-time:

public MyMethod(object obj)
{
  var calc = obj as ICalc;
  if (calc != null)
  {
    calc.Calculate();
  }
}

This can be improved:

public void MyMethod(ICalc calc)
{
  calc.Calculate();
}

Using generics and compile time type safety (I think it's important to show).

public void MyMethod<TObject>(TObject calc)
  where TObject : ICalc
{
  calc.Calculate();
}

is it my first case use interface ??

I'm not sure what this means, I think what you are trying to say is

Am I required to use the interface by casting it?

No you are not. Lets take a look at these two classes:

public class Calculation1 : IAddition, IMultiplication {
  public int Add() { //... ignoring implemenetation
  }

  public int Multiplication() { //... ignoring implemenetation
  }
} 

public class Calculation2 {
  public int Add() {//... ignoring implemenetation
  }

  public int Multiplication() {//... ignoring implemenetation
  }
} 

Both of the classes implement the same methods so these are valid:

var one = new Calculation1();
one.Add();
var two = new Calculation1();
two.Add();

However because the first one implements an interface and the second one does not, you can pass the first object to methods that do not need to know the concrete type.

public void MethodNeedsToAdd(IAddition addCalculator)
{
  if (addCalculator != null)
  {
    addCalculator.Add();
  }
}

MethodNeedsToAdd(one);   // Valid
MethodNeedsToAdd(two);   // Invalid

Even though you and I can clearly see they both can "Add" the second class two does not implement the interface.

Answer 2

In this case, the purpose is just to show you how you can cast types. It doesn't make a difference in how the code works, but you can see that if you were to try add.Multiplication(), the compiler would tell you that's not allowed.

In a simple example like this, there's no reason to cast and declare variables like this. However, in larger applications, the Interface Segregation Principle helps us to avoid tight coupling of different pieces of code. For example, you could write a method like this:

int SumAll(IAddition adder, params int[] values)
{
    int sum = 0;
    foreach(int n in values)
    {
        sum = adder.Add(sum, values[i]);
    }
    return sum;
}

The above method would work just fine if you pass it a Calculator, but it doesn't have to use a Calculator. Since you know you don't need to multiply anything in this method, this limits your dependencies to the things that you actually need. You might in the future find it useful to implement an Add method with a ceiling, for example, that never allows numbers to go above a certain number, no matter how many things get added. Passing that IAddition object into SumAll would have a different effect, and you wouldn't have to create a different SumAll method to accommodate this need.

Console.WriteLine(SumAll(new Calculator(), 1, 2)); // 3
Console.WriteLine(SumAll(new Calculator(), 1, 2, 3)); // 6
Console.WriteLine(SumAll(new AdderWithMax(4), 1, 2)); // 3
Console.WriteLine(SumAll(new AdderWithMax(4), 1, 2, 3)); // 4

In general, people find that by separating interfaces intelligently, they're able to write code that's easier to test and less likely to require as much work when changes are made in the future--in other words, more maintainable code.

Oh, and by the way, the explicit cast isn't actually necessary, so this would also have the same effect:

IAddition add = cal;

or:

var add = (IAddition)cal;

Answer 3

The other answers cover the given example code, but it's worthwhile to add that the rules are different for explicit interface implementation.

For example, if the example class was implemented as follows:

public class Calculation : IAddition, IMultiplication {
    int x, y;
    public Calculation(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int IAddition.Add() {
        return (x + y);
    }
    public int IMultiplication.Multiplication() {
        return (x * y);
    }
} 

then the cast is required. For example:

Calculation cal = new Calculation(10, 10);
cal.Multiplication(); // this will cause a compiler error
((IMultiplication)cal).Multiplication(); // This is the required way to do it

For more information see this article on MSDN

Answer 4

Only the second case programs to IAddition and IMultiplication interfaces. The first case would work even if the Calculation class did not implement IAddition and IMultiplication.

what is the purpose of casting?

Note that since you declare variables with an explicit interface type, you can safely drop the casts in the declarations of mul and add:

IAddition add = cal;
IMultiplication mul = cal;

You could also rewrite your declarations with implicit type declaration:

var add = (IAddition)cal;
var mul = (IMultiplication)cal;

What is the purpose of these 2 lines?

These lines declare two variables using the interface type implemented by Calculation. They make no practical difference in this example, but generally you could use add and mul to be specific about the level of abstraction to which you program. For example, IAddition add tells the readers of your program that you do not need to use any aspects of cal except these related to addition.

Answer 5

You don't need the cast. You can say...

IAddition add = cal;

However, the point of that is you are creating an object of any type that implements the IAddition interface.

Answer 6

It's all about concealing complexity. When you do this cast ...

     IAddition add = (IAddition)cal;

You can then handle this add item as if all it can do is implement your IAddition interface. That might prove convenient if you were implementing a complex system.

For example, you might define an IGetNextItem interface. Then, you might choose to implement that interface in a class which fetched an item from a DBMS, and another which generated a random fake item. You would be able to cast either object, and then pass it to some software which consumed those items, without needing to tell the consuming software exactly how the fetching of items actually works.