# OOPS Interface use?



## gopi_vbboy (Apr 5, 2012)

Hi i am really confused about application of interface in object oriented programming.I have some code  in C# which i am working on and  there are instances where the original coder uses interface and i am not able to grasp why?


I understand abstract class as it is used to implement something common and concrete.But i feel practically blank about interface


Do you guys share some practical funda about  application of interface in OOPS from practical code point of view.(Not with animal example please or oops definitions please.will be thankful if explained in simple language)

Thanks


----------



## krishnandu.sarkar (Apr 5, 2012)

Well lets take it like this.

I want Download and Upload in many services. So I declare a interface with methods named Download and Upload.

So I can use this thing for HTTP, FTP, SSH etc. over any protocol.

What I mean is I need that download and upload function on all the above right..?? So I can define an interface for common things which I'll use again and again.

Hope this helps. Others correct me if I'm wrong


----------



## abhijangda (Apr 5, 2012)

See, Interface actually tells what a class can do. It defines a contract between classes. For example, in above post an interface with functions Download and Upload can be declared and you can use classes to implement this interface for many protocols. There are many differences between abstract classes and interfaces. Try to read some books for C#, a very good one is Essential C# 4.0.


----------



## gopi_vbboy (Apr 6, 2012)

thanks guys i shud read more


----------



## Zangetsu (Apr 6, 2012)

Interface is the main part of OOPS

it supports multiple inheritance which classes don't
also interface are used to make reusable components


----------



## nbaztec (Apr 6, 2012)

Interfaces exist due to a semantic approach to programming. They essential define a delegation to the implementing class that it _must_ fulfill by implementing the methods.
Considering 2 scenarios of programming:

*Small Scale*
This generally does not require Interfaces, but the developer may implement them for "semantic's sake". You might define an ABC and implement the methods in child classes but the extra functionality of ABC isn't required since your only need is the methods not the properties. In this scenario Interfaces are passable.

*Large Scale*
This is essentially the real-word business scenario where multiple teams work on large projects than span multiple modules. That's an all together different animal. What usually happens is that the Software Engineering team after preparing the SRS, go into Analysis & Design stage wherein they usually take the modular approach by dividing the big application into smaller modules which are easier to design, code, test and integrate. Hence each team gets a module to code and the only thing they know about the other module is it's Interface. These interfaces are well defined and all other teams work using this Interface so that their own module conforms with the system-wide modules. Here lies the true service of Interface.

Either way it's a good idea to know where Interfaces should be used and where ABCs.



> also interface are used to make reusable components


Technically, no. That's inheritance and polymorphism that follow code reuse. Interfaces _support_ inheritance, which makes them reusable.


----------



## gopi_vbboy (Apr 9, 2012)

nbaztec said:


> Interfaces exist due to a semantic approach to programming. They essential define a delegation to the implementing class that it _must_ fulfill by implementing the methods.
> Considering 2 scenarios of programming:
> 
> *Small Scale*
> ...



Thanks that makes sense to me 



Zangetsu said:


> Interface is the main part of OOPS
> 
> it supports multiple inheritance which classes don't
> also interface are used to make reusable components



Thanks.But interface don't have implementations.So how do they constitute to multiple inheritance?


----------



## nbaztec (Apr 9, 2012)

gopi_vbboy said:


> Thanks that makes sense to me
> 
> Thanks.But interface don't have implementations.So how do they constitute to multiple inheritance?



Popularized by Java (can be wrong here though), multiple inheritance was discontinued for classes in C# (Some lame argument that it wasn't necessary). Instead a class could inherit multiple interfaces to accept multiple delegations. Not multiple inheritance in the usual sense (since properties can't be inherited/not allowed in interface) but still inheritance for methods and again the _semantics_ matter.


----------



## Zangetsu (Apr 9, 2012)

gopi_vbboy said:


> Thanks.But interface don't have implementations.So how do they constitute to multiple inheritance?



A Class cannot inherit from more than one Parent Classes but it can inherit from more than one interface...

eg: ICopy & IPrint interface can be implemented by a Class so that it can do both COPY & PRINT


----------



## Faun (Apr 10, 2012)

Considering JAVA:

1. An interface is implicitly abstract. You do not need to use the abstract
keyword when declaring an interface (although it is acceptable to use it).

2. Each method in an interface is also implicitly abstract, so the abstract
keyword is not needed. You can explicitly declare a method in an interface
as abstract, but typically the abstract keyword is left off.

3. Methods in an interface are implicitly public. It is common practice to
use the public keyword when writing an interface, but if you do not
explicitly declare a method in an interface as public, it will be public
anyway.

4. Attributes should be declared as static or final.

Abstract class has is-a relationship with the child class.

Interface has can-implement-this-functionality relationship with the child class which is implementing it.

An interface can be used 

1. to expose certain behaviors of a class, without exposing all of the behaviors of a class. 

2. to force behavior on other objects, ensuring that certain methods are implemented by an object. 

Interfaces can be used for polymorphism reasons, since an object can take on the form of an interface type.


*Exposing certain behaviors*

Let's have a class Employee with various attributes and behaviors relevant to the same

```
public class Employee
{
private String name, address;
private double weeklyPay;
public Employee(String name, String address)
{
this.name = name;
this.address = address;
}
public String getName()
{
return name;
}
public void setName(String n)
{
name = n;
}
public String getAddress()
{
return address;
}
public void setAddress(String a)
{
address = a;
}
public double getWeeklyPay()
{
return weeklyPay;
}
public void computePay(int hoursWorked)
{
weeklyPay = hoursWorked * 6.50;
System.out.println(“Weekly pay for “ + name
+ “ is $” + weeklyPay);
}
public void mailCheck()
{
System.out.println(“Mailing check to “ + name
+ “ at “ + address);
}
}
```

Now consider that there are two other departments: *Payroll Department* for handling the weekly payroll duties, and a *Human Resources Department* for managing general information about employees

The Payroll Department does not need to access or change the personal information about an employee. The Human Resources Department needs access to an employee’s information, but should not be accessing any paycheck details.

We will expose the methods relevant to both on separate interfaces:

For Payroll

```
public interface Payable
{
public void computePay(int hoursWorked);
public void mailCheck();
public double getWeeklyPay();
}
```

For HR

```
public interface EmployeeInfo
{
public String getName();
public void setName(String n);
public String getAddress();
public void setAddress(String a);
}
```

Now let the Employee class implement both of these interfaces:


```
public class Employee [B]implements payable, EmployeeInfo[/B]
{
private String name, address;
private double weeklyPay;
public Employee(String name, String address)
{
this.name = name;
this.address = address;
}
public String getName()
{
return name;
}
public void setName(String n)
{
name = n;
}
public String getAddress()
{
return address;
}
public void setAddress(String a)
{
address = a;
}
public double getWeeklyPay()
{
return weeklyPay;
}
public void computePay(int hoursWorked)
{
weeklyPay = hoursWorked * 6.50;
System.out.println(“Weekly pay for “ + name
+ “ is $” + weeklyPay);
}
public void mailCheck()
{
System.out.println(“Mailing check to “ + name
+ “ at “ + address);
}
}
```



> By implementing Payable and EmployeeInfo, through polymorphism an Employee object becomes a Payable object and an EmployeeInfo object. If someone in payroll needs an Employee object, we can pass the Employee object to a Payable reference. If someone in human resources needs an Employee object, we can pass the Employee object to an EmployeeInfo reference. With a Payable reference, only the Payable methods can be invoked. With an EmployeeInfo reference, only the methods in EmployeeInfo can be invoked.



Now, lets have a PayableDemo class which will be only able to access behaviors relevant to it (no employee personal information should be accessed):
computePay(int hoursWorked);
void mailCheck();
getWeeklyPay();


```
public class PayableDemo
{
public static void main(String [] args)
{
Payable e = new Employee(“George Washington”, “Mt. Vernon”);
e.computePay(30);
e.mailCheck();
}
}
```

And another class HRDemo, which will be able to access only these behaviors:
getName();
setName(String n);
getAddress();
setAddress(String a);


```
public class HRDemo
{
public static void main(String [] args)
{
EmployeeInfo e = new Employee(“George Washington”, “Mt. Vernon”);

e.getName();
e.getAddress();
}
}
```

*Forcing Behavior on Class*

Typical examples are Mouseevent listeners etc.

Note: A long post but cleared my doubts too. Excellent question OP.


----------



## gopi_vbboy (Apr 10, 2012)

Thanks a lot faun for awsome funda and effort.Appreciate it. 


Spoiler






Faun said:


> Considering JAVA:
> 
> 1. An interface is implicitly abstract. You do not need to use the abstract
> keyword when declaring an interface (although it is acceptable to use it).
> ...






Also i researched stackoverflow forum , they are advising to read design patterns to understand OOPS more deeply.Any suggestion for good book on Design pattern.


----------



## Faun (Apr 10, 2012)

gopi_vbboy said:


> Also i researched stackoverflow forum , they are advising to read design patterns to understand OOPS more deeply.Any suggestion for good book on Design pattern.



This should be good for beginning but I have not read any books on design pattern. Take my recommendation with a pinch of salt.

Amazon.com: Head First Design Patterns (9780596007126): Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra, Elisabeth Robson: Books


----------



## gopi_vbboy (Apr 10, 2012)

Good..i had a glance on google books preview...looks like a reading gonna b fun and creative


----------

