When and Where to use Interface
Hi All,
I have a question here.Im bit confused of interface usage.
Is it correct to have a separate separate interface for data objects?
I have around 10 business classes and have corresponding 10 data classes.
Do we need to have a separate separate interfaces for each and every data class?
What is the correct norms of using interface?
Please clarify this.
Thanks in advance.
[429 byte] By [
pkarun] at [2007-12-25]
It depends... are you going to be making these classes COM accessible? If so... then yes, you’ve got to use interfaces for everything that will be visible as a COM component.
Do you have to use them? No, you do not *have* to use interfaces with your classes... and without know much more about your classes, how you use them today and how you plan to use them tomorrow it is difficult to say.
As you probably know, interfaces can make ones life much easier when they want to define a specific interface... but no actual implementation details. Are any of your classes related in such a way? Do you expect to have other classes that will externally look very similar to one of the existing ones?
If the answer to either of those is yes, then you should think about using some interfaces... however you shouldn’t need to go overboard and make an interface for everything unless as mentioned above, you are making a COM component... in which case you’ve got little choice.
Hi Brendan,
Thanks for the information.I ll give more information about the classes being used here.
I have 5 business objects and similarly 5 data objects.
All the classes are internal and within application domain and no COM components being used.
Question 1
In the above mentioned scenario do you feel it is necessary to have separate separate interfaces for each and every data objects.
Question 2
I have five business class and similarly 5 data layer class.All the data layer class implements a common interface with common methods.
My business class talks to the data class through the interface.Lets assume tomorrow two methods has to be added in one of the datalayer class.In this case i need to add those two methods in the common interface as well as all other data layer classes that implements this common interface.Do we have any other solution to have a minimal change.Because in the above said scenario an inclusion of a method in a class makes us to change all other classes and the interface.
In an Object Oriented system, interfaces are used as abstract boundries between communicating objects. Such a boundry should be used when the actual implementation of the interface may be different in different situations - which basically means you should probably use an interface when you can think of at least two possible implementations of it (classes implementing the interface).
Thanks Yoni.Im expecting a solution for the following scenario
I have Business class named customerBL and EmployeeBL
I have an interface named IPeople with the following methods
GetData()
UpdateData()
DeleteData()
And i have two Data class named customerDL and EmployeeDL which implements the interface IPeople.If tomorrow i need to add a functionality in customerDL of GetAddress(int customerID), i also need to add this method declaration in the interface and as well as implmentation in another Data Class EmployeeDL.
My business class talks with the Concrete Data class via interface.
Is there any other solution to make the change minimal,its ok to include the methods in two classes.Lets assume for a big application which is having 50 classes or more, a change of this kind needs to be changed in all the impacted data class and the interface it implements.
I think the question to ask here is why do both customerDL and EmployeeDL implement IPeople? Is there a situation in which customerBL calls a method on IPeople and actually gets to EmployeeDL? If customerBL is actually using customerDL all the time then there is no need for an interface between them...
So I think the solution is to stop using IPeople (unless you have a good reason you didn't mention for it)
hi arun,
im also confused with same questions because lots of people(even the geniuses) say have an interface for everything. they all cant be wrong. but still heres my view.
First of all, interfaces shouldnt be used everywhere . Interfaces are used to protect the variation points of an application . If there are too many interfaces , that means the application requirements are not understood properly or the application is varying so much(unstable).
Have interfaces for every class. Thats simply overarchitecting.
Do we have to have a interface for the Math Class . No way , there cannot be two implementation for Adding two numbers . of course we can speculate, aliens will have a different way to add two numbers.
Why we need interfaces for data classes ?
Interfaces are preferred only when behavior is going to change.Data Classes dont have or have very less behavior..
I would prefer to program with classes ,and in future , if two different implementations are needed for a data class , refactor and extract the interface .
I would go for an interface when
1) there can be more than one implementation for a class.
2) the class is at a very important location of the architecture for example a service point in SOA
3) for multiple inheritance in C#.
Also Using interfaces has an impact on both performance and security.
Its just " Applying common sense Vs following principles blindly."
thanks
vinothkumar
vinxter wrote: |
If there are too many interfaces , that means the application requirements are not understood properly or the application is varying so much(unstable).
|
|
A design based on interfaces should be used by anyone who expects application requirements to not be understood properly (at least not at first) and to vary on a daily basis - which is reality for most software projects I've seen...
vinxter wrote: |
Why we need interfaces for data classes ? |
|
In Object Oriented Programming there is no such thing as a "data class" so refering to interfaces in that context is point-less...
thats the point , we overuse interfaces and abstraction as an excuse for our lack of understanding of the domain and domain requirements .
i think , we have to Put the effort on sitting with the domain experts and understanding the domain requirements , instead of five developers discussing inside a meeting room using their creative speculation over the future requirements and coming up with the great design that can handle most changes.
Thats why we are seeing the move toward all the domain centric stuff , DDD, MDA ,DSM , DSL .... (Im really looking forward for DSL)
and about the data classes ( i was referring to the pkarun's data classes) and I 100% agree with you .. there is no such thing as data class in OO , atleast in theory , but in practice ,it will be in almost all projects .... Even the software gurus once said Anemic domain model is a pattern and now its an antipattern. Entity Beans , NHibernate all use dataclasses ( anemic objects)...
Even in my own project , i have seen interfaces defined with only properties and no methods....
Finally in practical reality , requirements will never be clear , they change and we dont have the luxury of talking to domain experts daily (atleast here in india). Its the way it is...
thanks
vinothkumar