|
-
Nov 5th, 2002, 05:43 PM
#1
Thread Starter
yay gay
interfaces
hmmm...what is the real use of them? they look very similar to classes
-
Nov 5th, 2002, 05:44 PM
#2
Thread Starter
yay gay
hmm...they:
have no access modifiers...
cant contain code bodies
cant define field members
type defenition members are forbidden
-
Nov 5th, 2002, 05:47 PM
#3
Thread Starter
yay gay
ah i see...interfaces are like bones so i can inherit from them and has some built-in options?
edit: yea..looks like they are bones so then one can see what to has to make in a class..
Last edited by PT Exorcist; Nov 5th, 2002 at 05:57 PM.
-
Nov 5th, 2002, 06:00 PM
#4
Hyperactive Member
They are just a contract. They don't have any implementation. This means if you inherit from an interface, you will have to implement all the methods and properties of the interface.
But, what this buys you is that you can treat the same any object that inherits a particular interface.
-scott
he he he
-
Nov 5th, 2002, 10:19 PM
#5
Frenzied Member
I'm having a really hard time coming to terms with interfaces. It just does'nt make any sense to implement an interface then writing all the code for the methods and properties it exposes. Why not just write your own methods or class? I guess I just need to see a real world example.
Dont gain the world and lose your soul
-
Nov 5th, 2002, 10:30 PM
#6
PowerPoster
Image you're given a task to create an object model, 'Vehicle'. Two common actions present in all vehicle types would be 'TurnLeft' and 'TurnRight'. This is something that you want all objects of type 'Vehicle' to implement. Rather than trying to come up with a generic method and let all subclasses override, you could just set up an interface that contractually binds all subclasses to adhere to. I hope that helped a little..
-
Nov 5th, 2002, 10:35 PM
#7
Frenzied Member
Ok, I think I got it, I'll go read my text now
Dont gain the world and lose your soul
-
Nov 6th, 2002, 12:45 AM
#8
You can also think of it like this: You know how in .NEt a lot of the objects have the same method (i.e. Clone, Contains). Objects that can work as enumerable (can be used in a For...Each) implement the IEnumerable which has a GetEnumrator method that it must implement in order to work with For..Each. Same with IClonable which has a Clone method that must be implemented. Then when You go to run a For..each or Clone the Framework queries for one of these interfaces then uses that part to do the expected method. Its almost like getting a derived class because you can do things like this:
VB Code:
Public Class MyObject1
Implements ICloneable
Public Function Clone As Object Implements ICloneable.Clone
'blah blah
End Function
End Class
Public Class MyObject2
Implements ICloneable
Public OtherProperty As String
Public Function Clone As Object Implements ICloneable.Clone
'blah blah
End Function
End Class
Dim MyObject1Instance As New MyObject1()
Dim MyObject2Instance As New MyObject2()
Dim ic As ICloneable=MyObject2Instance
Dim obj As Object=ic.Clone()
ic=MyObject1Instance
Dim obj2 As Object=ic.Clone()
'regardless of the object type if it supports the interface you can convert it to the interface object and use it as such.
-
Nov 6th, 2002, 09:49 AM
#9
It's called polymorphism. Using this mechanism you can treat objects like the interfaces you derive from.
All the buzzt
 CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
-
Nov 6th, 2002, 10:22 AM
#10
Thread Starter
yay gay
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|