Interfaces
-
Hi guys, Quick question - are c# interfaces immutable in the same way that COM interfaces were - i.e. once published cannot be changed?
C# has already designed away most of the tedium of C++.
Interesting question. The first answer is "No" they aren't immutable. You can change them. The second answer is "In certain circumstances, they should be". If you publish an API, then you shouldn't modify a method signature - it's just bad practice. However, you may choose to add new methods and properties, but you have to be aware of the impact - e.g., are you going to cause a serialized object to fail/
Deja View - the feeling that you've seen this post before.
-
Interesting question. The first answer is "No" they aren't immutable. You can change them. The second answer is "In certain circumstances, they should be". If you publish an API, then you shouldn't modify a method signature - it's just bad practice. However, you may choose to add new methods and properties, but you have to be aware of the impact - e.g., are you going to cause a serialized object to fail/
Deja View - the feeling that you've seen this post before.
OK - excellent, pretty much what I thought....so the next question is what is the point of an interface in c# (lol!). I mean, I know the textbook answer, but given a situation where we need to add a field to a database call, if we're using an interface type setup, then we'd have to make the change in 2 places - interface and implementation - so unless I'm expecting my class to have many clients, there's not really much point in going down the interface route? I'm clearly missing something here, just not sure what lol!
C# has already designed away most of the tedium of C++.
-
OK - excellent, pretty much what I thought....so the next question is what is the point of an interface in c# (lol!). I mean, I know the textbook answer, but given a situation where we need to add a field to a database call, if we're using an interface type setup, then we'd have to make the change in 2 places - interface and implementation - so unless I'm expecting my class to have many clients, there's not really much point in going down the interface route? I'm clearly missing something here, just not sure what lol!
C# has already designed away most of the tedium of C++.
If you're just developing an internal application, then an interface is pretty useless in that it won't really add that much value to your code. If, though, you want to expose your application to the outer world, then an interface is really useful - and you should certainly look at using it if you want to move into areas like WCF.
Deja View - the feeling that you've seen this post before.
-
If you're just developing an internal application, then an interface is pretty useless in that it won't really add that much value to your code. If, though, you want to expose your application to the outer world, then an interface is really useful - and you should certainly look at using it if you want to move into areas like WCF.
Deja View - the feeling that you've seen this post before.
OK - that's brilliant....thanks for that. The reason I ask, is that I come from a very "rigid" dev background - kinda places where if you don't have a signed off spec, you don't write a line of code. Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol.... I'm trying to get some more structure into things, and whilst at the moment we're a closed platform, I can personally see the value in a clearly defined API...and from what you're saying, interfaces are probably the way to go for that one. Adittionally, the more "experienced" members of the team need convincing that what I propose will actually help - to give you some idea of the "challenge" here, I put together some unit tests, and they were struck down on the grounds that they're "extra work, why can't you just look at your code and find bugs that way - eyeball Mark 1!" Again, many thanks for the time Pete.
C# has already designed away most of the tedium of C++.
-
OK - that's brilliant....thanks for that. The reason I ask, is that I come from a very "rigid" dev background - kinda places where if you don't have a signed off spec, you don't write a line of code. Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol.... I'm trying to get some more structure into things, and whilst at the moment we're a closed platform, I can personally see the value in a clearly defined API...and from what you're saying, interfaces are probably the way to go for that one. Adittionally, the more "experienced" members of the team need convincing that what I propose will actually help - to give you some idea of the "challenge" here, I put together some unit tests, and they were struck down on the grounds that they're "extra work, why can't you just look at your code and find bugs that way - eyeball Mark 1!" Again, many thanks for the time Pete.
C# has already designed away most of the tedium of C++.
Interface are also good in places where you have an object that depends on another, especially if that other object is passed in at construction time. (This is a lot like Dependency Injection and Inversion of Control.) You can also use them when you potentially have multiple objects that will share common traits. Think of this scenario: You are implementing a Visual Studio-like application so you have a concept of a project and project items. You can have multiple project types and and multiple project item types. There is only a very small bit of functionality that is common across all project types and all project item types. By implement a set of interfaces (IProject and IProjectItem), you can pass interfaces around as method parameters, etc. and always guarantee that the object you are given will implement certain methods/propterties. You can't guarantee the actual implementation, only that the method or property will be available. This allows you to more easily expand the system by adding new project or project item types by simply deriving from the interface.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
OK - that's brilliant....thanks for that. The reason I ask, is that I come from a very "rigid" dev background - kinda places where if you don't have a signed off spec, you don't write a line of code. Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol.... I'm trying to get some more structure into things, and whilst at the moment we're a closed platform, I can personally see the value in a clearly defined API...and from what you're saying, interfaces are probably the way to go for that one. Adittionally, the more "experienced" members of the team need convincing that what I propose will actually help - to give you some idea of the "challenge" here, I put together some unit tests, and they were struck down on the grounds that they're "extra work, why can't you just look at your code and find bugs that way - eyeball Mark 1!" Again, many thanks for the time Pete.
C# has already designed away most of the tedium of C++.
RichardGrimmer wrote:
Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol....
I was on vacation, did you just join my shop? :laugh:
RichardGrimmer wrote:
so unless I'm expecting my class to have many clients, there's not really much point in going down the interface route? I'm clearly missing something here, just not sure what lol!
It sounds like you are missing something but you also said you know the text book definition so this is a bit confusing. In Object Oriented Design an interface is a mechanism of abstraction. So you want to use an interface if it is desirable to abstract the functionality.
RichardGrimmer wrote:
are c# interfaces immutable in the same way that COM interfaces were
First, COM is not Object Oriented Design and there is not generally any reason to compare COM to OOD. Also I am not sure what you mean by immutable. My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code. While there might be some scenarios where that would work, most of the time I expect it would not.
led mike
-
RichardGrimmer wrote:
Now I've moved into a more "relaxed" environment, but the code is basically a big morass of procedural code in an object oriented dress - with inheritance implemented using copy and paste lol....
I was on vacation, did you just join my shop? :laugh:
RichardGrimmer wrote:
so unless I'm expecting my class to have many clients, there's not really much point in going down the interface route? I'm clearly missing something here, just not sure what lol!
It sounds like you are missing something but you also said you know the text book definition so this is a bit confusing. In Object Oriented Design an interface is a mechanism of abstraction. So you want to use an interface if it is desirable to abstract the functionality.
RichardGrimmer wrote:
are c# interfaces immutable in the same way that COM interfaces were
First, COM is not Object Oriented Design and there is not generally any reason to compare COM to OOD. Also I am not sure what you mean by immutable. My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code. While there might be some scenarios where that would work, most of the time I expect it would not.
led mike
led mike wrote:
First, COM is not Object Oriented Design and there is not generally any reason to compare COM to OOD. Also I am not sure what you mean by immutable
He's dealing with the idea of interfaces as the way that COM defined them, i.e. Contracts that were exposed to the outside world (and referenced through IUnknown and so on). In COM, interfaces were supposed to be immutable because COM relied heavily on VTable binding, so changing the interface resulted in the VTable being incorrect, which obviously caused errors when attempting to call a method which had been moved because a new parameter was added to a method.
Deja View - the feeling that you've seen this post before.
-
led mike wrote:
First, COM is not Object Oriented Design and there is not generally any reason to compare COM to OOD. Also I am not sure what you mean by immutable
He's dealing with the idea of interfaces as the way that COM defined them, i.e. Contracts that were exposed to the outside world (and referenced through IUnknown and so on). In COM, interfaces were supposed to be immutable because COM relied heavily on VTable binding, so changing the interface resulted in the VTable being incorrect, which obviously caused errors when attempting to call a method which had been moved because a new parameter was added to a method.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
so changing the interface resulted in the VTable being incorrect
Not incorrect in the compiled module, so what I said then, right?
led mike wrote:
My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code.
led mike
-
Pete O'Hanlon wrote:
so changing the interface resulted in the VTable being incorrect
Not incorrect in the compiled module, so what I said then, right?
led mike wrote:
My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code.
led mike
Well - depending on versioning, yes.
Deja View - the feeling that you've seen this post before.
-
Pete O'Hanlon wrote:
so changing the interface resulted in the VTable being incorrect
Not incorrect in the compiled module, so what I said then, right?
led mike wrote:
My best guess is that you mean, can you modify an interface, build and distribute the assembly without breaking existing code.
led mike
Yep, but rather than the nicely broken like you get in .Net, it was horrible horrible things like stack corruption or jumping to a completely wrong location ;)
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.