When to define interfaces
-
Hey all, I'm working on a mid-sized project and trying to do some class modeling. I was wondering if there is a good test that I can use when deciding if I should base a class on an actual interface data type as opposed to just having the class outright. For example, having: public interface ICustomer{ ... } public class Customer: ICustomer{ .... } Is it a good idea to have interfaces (the datatype) for each class we model? Thanks much *->>Always working on my game, teach me *->>something new. cout << "dav1d\n";
-
Hey all, I'm working on a mid-sized project and trying to do some class modeling. I was wondering if there is a good test that I can use when deciding if I should base a class on an actual interface data type as opposed to just having the class outright. For example, having: public interface ICustomer{ ... } public class Customer: ICustomer{ .... } Is it a good idea to have interfaces (the datatype) for each class we model? Thanks much *->>Always working on my game, teach me *->>something new. cout << "dav1d\n";
C# interfaces are not as great as COM interfaces. COM interfaces were supposed to act like a contract, and by the way do separate the interface from the actual implementation. Using C# this is no longer true, as there is no more "header" files. The only thing good about C# interfaces is that your class can derive from more than one interface, whereas your class cannot derive from more than one class (same Java limitation).
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
-
Hey all, I'm working on a mid-sized project and trying to do some class modeling. I was wondering if there is a good test that I can use when deciding if I should base a class on an actual interface data type as opposed to just having the class outright. For example, having: public interface ICustomer{ ... } public class Customer: ICustomer{ .... } Is it a good idea to have interfaces (the datatype) for each class we model? Thanks much *->>Always working on my game, teach me *->>something new. cout << "dav1d\n";
As C# is currently not having a
constkeyword for return values, I certainly would make an interface for structures that I want to pass as readonly. Another thing to consider is whether the implementing structure needs to subclass something other than ICustomer, e.g; CPenquin: public ICustomer and CHuman: public ICustomer... I also find code more readable when you pass interfaces with a limited number of members. And last: using interfaces makes your code very flexible. "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus -
Hey all, I'm working on a mid-sized project and trying to do some class modeling. I was wondering if there is a good test that I can use when deciding if I should base a class on an actual interface data type as opposed to just having the class outright. For example, having: public interface ICustomer{ ... } public class Customer: ICustomer{ .... } Is it a good idea to have interfaces (the datatype) for each class we model? Thanks much *->>Always working on my game, teach me *->>something new. cout << "dav1d\n";
You define an interface when you have two or more classes implementing common behavoir. For example "Customer" and "Supplier" might both implement a IContact interface with methods for setting their address, name etc. You only want to define an interface when there is more than one class that implements that interface, or if there might be in the future.
-
You define an interface when you have two or more classes implementing common behavoir. For example "Customer" and "Supplier" might both implement a IContact interface with methods for setting their address, name etc. You only want to define an interface when there is more than one class that implements that interface, or if there might be in the future.
I have to agree with Stephane. I always try look for places where interfaces will be beneficial, but rarely find such places. One example of the top of my head is for "late-binding". Other than that I find them only really useful in Collections. I'm still pretty new to C# (6 months) so maybe they will start making more sense later. :) Cheers Give them a chance! Do it for the kittens, dear God, the kittens!
-
Hey all, I'm working on a mid-sized project and trying to do some class modeling. I was wondering if there is a good test that I can use when deciding if I should base a class on an actual interface data type as opposed to just having the class outright. For example, having: public interface ICustomer{ ... } public class Customer: ICustomer{ .... } Is it a good idea to have interfaces (the datatype) for each class we model? Thanks much *->>Always working on my game, teach me *->>something new. cout << "dav1d\n";
The usefulness of interfaces is best described (IMO) in terms of ArrayList.Sort(). An ArrayList can hold an array of pretty much any kind of object. So how does it sort them? What is the easiest way to define a function that could be sorting strings, objects, numbers, and so on? You can't use ToString() because 10.ToString() == "10", 5.ToString() == "5". Thus 10.ToString() < 5.ToString(). So ArrayList.Sort calls IComparible.CompareTo(object obj) on each object to sort them. Thus if you want to do an ArrayList.Sort then all the objects in the ArrayList must implement the IComparable interface or it will not be able to cast it. eg.
private class SortableObject : IComparable { // normal class code here public int CompareTo(object Item) { // Comparison code here } }This way I can exactly define how I want one SortableObject to compare to another. ArrayList.Sort doesn't give a damn how I compare them, just that I define a method in the exact formatpublic int CompareTo(object Item). It is a contract between my object and ArrayList.Sort saying I'll do the comparison, you do the sort. Paul -
I have to agree with Stephane. I always try look for places where interfaces will be beneficial, but rarely find such places. One example of the top of my head is for "late-binding". Other than that I find them only really useful in Collections. I'm still pretty new to C# (6 months) so maybe they will start making more sense later. :) Cheers Give them a chance! Do it for the kittens, dear God, the kittens!
It's only useful when saying "I have two or more very different objects that do the same thing in very different ways, but I want a seperate piece of code to perform that common action regardless of the way te different objects act during that action." And if that makes no sense, read the other post I just put in this thread ;) It's not infinitely useful but then neither was COM Interfacing but it was forced on you. This is just a simplification on the grounds that some people might still want this kind of functionality. In other words, don't look for a place to use it, just remember it's there if you ever stumble upon something complicated like this :-D Paul
-
The usefulness of interfaces is best described (IMO) in terms of ArrayList.Sort(). An ArrayList can hold an array of pretty much any kind of object. So how does it sort them? What is the easiest way to define a function that could be sorting strings, objects, numbers, and so on? You can't use ToString() because 10.ToString() == "10", 5.ToString() == "5". Thus 10.ToString() < 5.ToString(). So ArrayList.Sort calls IComparible.CompareTo(object obj) on each object to sort them. Thus if you want to do an ArrayList.Sort then all the objects in the ArrayList must implement the IComparable interface or it will not be able to cast it. eg.
private class SortableObject : IComparable { // normal class code here public int CompareTo(object Item) { // Comparison code here } }This way I can exactly define how I want one SortableObject to compare to another. ArrayList.Sort doesn't give a damn how I compare them, just that I define a method in the exact formatpublic int CompareTo(object Item). It is a contract between my object and ArrayList.Sort saying I'll do the comparison, you do the sort. PaulYou're right:-D. Interface names such like ICompare, IClonable and stuff like that are in fact useful when searching the MSDN doc for classes with particular features, and as such act as search filters. In the end, you get faster to what you are looking for. I vote on that a 5.:-D
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
-
You're right:-D. Interface names such like ICompare, IClonable and stuff like that are in fact useful when searching the MSDN doc for classes with particular features, and as such act as search filters. In the end, you get faster to what you are looking for. I vote on that a 5.:-D
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
:laugh::laugh::laugh: Paul