|
>>>C# is a strictly typed language. Whenever types don't match, casting is necessary.
This is simply not true. C# allows you to upcast and perform implicit conversions (eg double to int) without needing a cast.
The whole issue of implicit vs explicit is not mentioned.
The existence of a range of other conversion functions (CInt, CDbl, etc) is ignored. Likewise the Convert functions, ToString(), etc.
I'll wait for V2.
|
|
|
|
|
|
Where were you when I just started doing C# & VB.Net?
Anyway, a couple of comments:
1) Your explaination of DirectCast isn't really clear. Maybe it would help if you showed some example.
2) I don't really see the difference for point 4 & 5.
Besides that good article. A lot of newbie would undoubtably find it helpfull
|
|
|
|
|
I liked the style of this article as you consider both C# and VB.NET. I learnt something new - I did not know about the as operator
Do any C++ purists agree with me when I say: casting is never needed in good OO design.
Even in an XML parser you don't need it. Consider a simple example: if you can always predict what nodes you might need to 'cast' into you can provide a function:
CommentElement Node::GetAsComment()
...where Node is the superclass of all Xml element nodes.
|
|
|
|
|
dog_spawn wrote:
Do any C++ purists agree with me when I say: casting is never needed in good OO design.
Just off the top of my head, here are some examples where very good design in C# requires casting:
* Creating a plug-in architecture - try loading and instantiating dynamically assemblies without polymorphic reflection tests and casting.
* Using pretty much any of the Asynchronous programming methods in the FCL - all use boxing and un-boxing, which can't be done without casting.
* Adding queue items that return values to a the ThreadPool requires boxing and un-boxing, which again is casting.
|
|
|
|
|
You seem to have missed my point. I will try to explain myself better.
Obviously using C# requires casting. But that is because most of the framework is not designed as well as it could be. My point is about design not about the way the framework happens to be setup
Most of the time we only cast because C# doesn't allow us to make specialized collections easily enough yet. 'generics' will solve that hopefully.
No plugin architecture ever needs casting. Any plugin object inherits some interface. Obviously a give program only knows about the interface. If you end up casting using plugin objects your interfaces need redesigning
|
|
|
|
|
First, thanks for the compliment!
Concerning your good OO design (btw, I don't know if C++ purists are by definition to be considered as OO purists, but please, let's not start that discussion here... ):
Casting is in my opinion not a matter of design. Casting originates from the fact that the implementation is done in a strong-typed language. Would you implement in a purely object-oriented language as SmallTalk, then you would never have to cast, since it does no typechecking, and even does not know what casting is...
Now, should you design in such a way that casting will not be necessary in an implementation language ? My answer would again be no. Good OO designs are caracterised by their good distribution of responsibilities. Is it a good distribution of responsibility to have the superclass know about all it's (current but also future !?!) subclasses, since it should provide GetAsSubclass methods for each one of them ? I believe the contrary. By the way, as I pointed out, you can only provide GetAs methods for known (=current) subclasses, so you disallow extension by subclassing by 3rd parties. Wasn't OO meant to be extended that way ?
Consequently, if C# requires casting, it's not due to bad design (although design could have been better), but due to it's strong-typed character.
|
|
|
|
|
Rudi Breedenraedt wrote:
Consequently, if C# requires casting, it's not due to bad design (although design could have been better), but due to it's strong-typed character.
C# is a strongly typed language. However the collections are not, hence my comments about bad design.
I think you have got mixed up here You do not need casting with a strongly typed language. That is the point of types. C# requires casting so frequently because of the bad design of the collections.
Rudi Breedenraedt wrote:
I believe the contrary
I agree it is bad design to have GetAsSubclass method However that is a better solution than casting. This problem can be solved by good design. For example GetElementsByTagName in the XML part of the framework should return a list of XmlElements, not a list of XmlNodes as it currently does.
|
|
|
|
|
Casting in C# is nothing else than querying for another interface. The cast is verified to be valid. So what?
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
Heh, well 'So what?' is a perfectly practical point of view It kind of misses the point but it's less hard work.
|
|
|
|
|
What is the difference between a cast and a QueryInterface in C# ?
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
I assume you already know that
I don't really want to say this again but I will: in good design you do not need to downcast because the type of the object you are dealing with should already be the correct interface. That is basic OO programming using types and I refuse to discuss it anymore. Please have mercy
|
|
|
|
|
dog_spawn wrote:
Please have mercy
No
If you don't want to discuss it, and you can keep yourself from replying, don't reply.
otherwise:
dog_spawn wrote:
I assume you already know that
lets, for this discussion, assume I don't.
dog_spawn wrote:
in good design you do not need to downcast because the type of the object you are dealing with should already be the correct interface
This propagates requirement of knowledge of this interface through large parts of the project, In my experience, tight coupling is always the downfall of large projects, so I tend to reduce the coupling to the absolute minimum.
Do you accept the "virtue" of QueryInterface - or is this "wrong" too?
dog_spawn wrote:
That is basic OO programming using types
OO is no religion, just a set of rules that have reasons. In programming, I refuse to accept a rule when noone can tell me the reason.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
peterchen wrote:
This propagates requirement of knowledge of this interface through large parts of the project, In my experience, tight coupling is always the downfall of large projects, so I tend to reduce the coupling to the absolute minimum.
Sorry, but that is insane. If you are saying pass only Object around that is just madness. You have to know the interface anyway as you have to cast it.
You must be winding me up here Ok, I get it now - please stop
|
|
|
|
|
dog_spawn wrote:
I learnt something new - I did not know about the as operator
Just find out about that one a month or so ago. Quite useful!
Rocky Moore <><
|
|
|
|
|
The 'as' and 'is' operator can be very useful if it is used in pair.
For example think about a treeview control where you've different grouping levels, where each level has a different treenode derived class.
When you've to show different context menus depend on the node type what the user right clicked, then the
if (nodTemp is MyNodeLevel1)
{
MyNodeLevel1 nodCurrent = nodTemp as MyNodeLevel1;
... code here ...
}
else if <repeating the="" above="" for="" different="" type="">
...
...
...
And these operators provide cleaner code then the "normal" () type casting.
So this is great artticle to point out these things!
Attila Hajdrik
|
|
|
|
|
Dog_spawn, Your obviously an Idiot. Go get a book and read it instead of posting a useless negative comment on every damn tutorial.
|
|
|
|
|
Dog_spawn - if your such a great developer, why do you even need to read these tutorials, you obviously know everything anyway.
Nick Graham
|
|
|
|
|
I would like to see a dog spawn example. Anyone else??
|
|
|
|