|
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/
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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? 
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.
|
|
|
|
|
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.
|
|
|
|
|
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 
|
|
|
|
|
Are there any software with modeling can get knowledge from texts?
Something like terminology extraction software
With modeling that can idenfify texts, get knowledge from texts.
Will be install on Novell Linux Enterprise, Sun Solaries, openSolaries.
OCR from books.
OCR to turn the text into a digital format
Reference, some machine learning software:
http://www.dmoz.org/Computers/Artificial_Intelligence/Machine_Learning/Software/
http://www.cs.waikato.ac.nz/~ml/weka/
http://www.ph.tn.tudelft.nl/PRInfo/software.html
http://www.fml.tuebingen.mpg.de/raetsch/workshops/MLOSS06
http://www.mloss.org/software/
http://maltman.hmdc.harvard.edu/socsci.shtml
http://home.earthlink.net/~dwaha/research/machine-learning.html
http://dir.yahoo.com/Science/Computer_Science/Artificial_Intelligence/Machine_Learning/Intelligent_Software_Agents/
http://www.google.com/Top/Computers/Artificial_Intelligence/Machine_Learning/Software/
http://www.nec-labs.com/research/machine/ml_website/main/software.php
http://www.isp.pitt.edu/information/software.html
|
|
|
|
|
Hi,
I am new to MVP architecture. Can anybody please send the sample project like student/Employee which will demonistrates the MVP architecture. The article is good help to me which is posted by you.
Thanks in advance.
|
|
|
|
|
sreenivasaraok wrote: I am new to MVP architecture. Can anybody please send the sample project
Is there something wrong with this sample project?[^]
led mike
|
|
|
|
|
|
(Cross posted from the c# forum)
A Customer can have multiple Products and a Product can be assigned to zero to more Customers
But, there are some items (such as BasePrice and DefaultPrefix) that are implicit to a customer-product relationship.
In the database this can be modeled as
Table Customer with Columns CustomerId, Name, etc.
Table Product with Columns ProductId, Name, etc.
Table CustomerProduct with Columns CustomerId, ProductId, BasePrice, DefaultPrefix, etc.
How would you model this as Domain Objects?
All I could think of is
Customer
..CustomerId
..Name
..AssignedProduct[] Products
Product
..ProductId
..Name
..Customer[] Customers
AssignedProduct : Product
..Customer Customer
..BasePrice
..DefaultPrefix
But that doesn't strike me as too slick (an Assigned Product has a Customer and a Customers[]???) and as this simplified example gets closer to what I actually have to model, this design starts to have problems among which is that NHibernate can't model some of this stuff
|
|
|
|
|
I'm toying with the idea of using 'virtual' menu items to allow a user to configure a menu. When placed in an 'edit mode', each real menu item will get extra 'virtual' child items such as 'Add Child', 'Add Above', 'Add Below', etc. which will bring up a dialogue for configuring the menu item. Any thoughts on this approach?
|
|
|
|
|
Brady Kelly wrote: Any thoughts on this approach?
Works for the Windows Forms designer.
|
|
|
|
|
Personally I hate the menu editor as it sits today. It is a real pain in the butt to use when you need to build them menu and then go back and set properties on it, etc... Just a big pain.
I am a much bigger fan of the interface used for edit toolbar buttons really. Just give me a separate window with a tree view and a property grid. Seems much more effective that using in-place editing for the menu items.
Just MHO.
|
|
|
|
|
My bad not stating it's an ASP.NET menu control I want to make editable, so it already renders a left hand, vertical tree structure that I would like to use for editing, also with a property page in the main pane.
|
|
|
|
|
I'm curently trying to simplify testing in my company by enabling the use of the command pattern.
So I need:
Command - interfact/abstract class defining public contract for concrete commands
ConcreteCommand - and command to use
Receiver - class that receives command to execute
Invoker - class that invokes the command on the receiver.
Ok so this is all standard GOF stuff, where I'm scratching my head is the implementation of the command and receiver classes.
We use selenium for testing the web apps UI and will make a call something like:
selenium.Click("link")
or
selenium.GetXPathCount("//div[@id='ctl00_MainContent_pnlWork']/table/tbody/tr")
What I want to do is enable a developer to create a command to perform a selenium action such as the code above (ok technically they're 2 different commands since one has a return and one doesn't) but I don't want to have to create a concrete class for each type of selenium action i.e. method but at the same time in my receiver class I don't want to have a huge switch statement that caters for each type of command.
I didn't want to pass the receiver to the concrete command object as I have other types of command I need, such as db commands, which need different receivers and where possible would like to use a generic interface for the receivers to enable easy expansion in the future (I already have 3 potential receivers and this may grow).
I'm using C# and Asp.Net with the .Net 3.5 framework.
Any help appreciated.
|
|
|
|
|
Lowest of the Low wrote: Any help appreciated.
Ok, I suggest you ask at least one question. That way people here might be able to help you.
led mike
|
|
|
|
|
Thought I had 
To be clear I'm asking the best way to implement the ConcreteCommand & Invoker (which sort of go hand in hand as command passed through needs to be interpreted by the invoker).
Once specific example of this is utilising selenium and being able to pass a command to an invoker than will execute that command by calling a method on an instance of the selenium.
Hope thats clearer.
|
|
|
|
|
Lowest of the Low wrote: To be clear I'm asking the best way
My experience in forum discussions on design issues indicates that it's normally not possible to gain sufficient understanding of the problem domain (due to the limits of text messaging conversations) to definitively know what the "best" solution is. Most likely what you can get is some ideas. Some may not be based on a correct understanding of your problem domain and therefore won't seem very good to you because you do have a more comprehensive understanding of the problem domain. Ultimately it will be up to you to determine which is the "best" solution.
Lowest of the Low wrote: but I don't want to have to create a concrete class for each type of selenium action i.e. method but at the same time in my receiver class I don't want to have a huge switch statement that caters for each type of command.
Keep in mind what I said above about not having a clear picture, but that statement seems to say something like, we have options A and B and I don't want to do either. So I guess you are asking if someone knows of a another option. I suppose delegates or since you are in 3.5 maybe Lambda expressions could be leveraged to provide a solution that is neither a class for each selenium action nor conditional statements for each selenium action.
I am doubtful that delegates are superior to classes and I have not yet ventured into 3.5 and Lambda. However many people that have seem enamored with it, so you might want to spend some time looking at it.
led mike
|
|
|
|
|
Thanks for the feedback.
I think I'll post in the C# forum about Linq and see if anybody can offer some advice there.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
