[Bench]

Hi C# folks. This isn't really a straight question, more of a discussion point which just struck me as I carry on exploring the world of .NET.

Until now I have only dabbled here-and-there in C# and the .NET framework - it's not my forte, and there are times when seeing a bit of C# code offends my sensibilities which are well and truly rooted into the world of C++ where deterministic finalisation and templates have shaped my ideas about what a "good" bit of code looks like.


But with technology moving the way it is, I need to make that mental leap into the world of understanding the peculiar ways in which C# programmers think about problem solving - it's clearly different to the way I see things; I'm aware how terrible some of my attempts at writing managed .NET code often are. (And equally, I sometimes find it maddening when I see a bit of C++ code written by a C# programmer who has liberally thrown pointers all over the place)


Just today I came across a C# design pattern known as IoC (Inversion of Control) which partly flies in the face of my C++ sensibilities (Although as I type this and think about it a little more, its not so far removed from the ways in which I write template classes - in fact IoC and Dependency Injection seems conceptually similar to 'policy based design' which has been part of C++ template programming for a long time).

My initial reaction upon reading the MSDN article about IoC was along the lines of "Hey, doesn't this go against encapsulation? surely this is a step backwards?" , but upon pondering a bit further, it dawned on me that the reason C++ objects take control (ownership) of objects is that they are fully capable of doing the construction, copying and cleanup of those objects straight out-the-box without any extra fuss; so in C++ it makes all kinds of sense to bundle objects together into a controlling class, but in C# the tables are turned and it becomes a liability because of the way that C# treats class variables as smart-pointers/references means that you suddenly need to think about copying and cleanup (boilerplate code alert!).


Has anyone else who moved from native code to managed code had a similar realisation that they needed to mentally shift their ideas in order to feel comfortable that the code they're writing isn't "Junk"?


I feel as if IoC has opened my eyes to one bit of the C# puzzle for me, but there are still other bits of C# which make me feel uneasy; in particular the Dispose pattern makes me wonder how its possible to write C# code without needing massive amounts of boilerplate everywhere to clean up non-memory resources (IDisposable and try..finally both me long for C++ destructors for things like sockets, databases, etc) I guess people must have found other patterns and idioms which let you avoid all of this?
- In a way, it almost seems that 'good' C# design is sometimes the polar opposite of 'good' C++ design (But then again, there are certain things which C# has taught me which I'm sure has made me a better C++ programmer too - particularly when it comes to writing multi-threaded code).

Is it maybe the case that C++ has taught me to become so hung up on object ownership and finalisation that I'm struggling to see a better way to write code which uses resources? There seem to be too many situations where it's crucial to know precisely when an object will be destroyed. Obviously of the "evils" which have existed in C and C++ code for so long, the necessity of calling delete or free() is right up there, but C# seems to have only shifted the problem in having to remember using, try/catch/finally or .Dispose() instead

I've seen suggestions about using Event-Driven-Disposal code to avoid the problem (For example, WPF apparently has a "Shutdown" event which can be used like a C++ destructor for WPF forms). Do people do this quite a lot?


PS - the reason for this thread is that I'm curious on others' opinions and experiences about how you all learned to write better C# code - especially if you started out with a language such as C++, since it seems that many "C++ best practices" don't apply. (I'm already looking into buying the Effective C# books - hopefully these are as insightful as Scott Meyers' Effective C++ books)


/END Wall of text. Thanks for reading

[AdamSpeight2008]

Inversion Of Control is a Design Pattern, so is restrict to C#.
I think the Gang Of Four book was written before C# was even conceived.
IOC helps a lot in testing.

You only have to Dispose of OS Resources Handles ( like File Handles ).
If the object being invoked implements IDisposable the us Using ... End Using block.
.net a big source of memory leaking is forgetting to remove event handlers your class uses.

Another thing I try to practice where possible, is to make by objects immutable and do things in Functional Style. Make use of Inheritance ( both on classes and Interfaces. )
A benefit of .net is inter-operability of the languages, so if something is hard to do in one, write that section in a language more suitable and import it. ( C++/CLI (a little neglected), IronPython, F#, C#, VB.net, Boo, Javascript (winRT) etc).

Use vs2010 or higher, so can utilise NuGet packages, so if you do have to rewrite/reinvent to wheel. Speaking of which use the Generic Collections over their Object based counter parts.

I think one of the hardest things to do in .net is implementing copying of an object, that are true copies and not shallow ones. Unlike C++, .net tends make it reference copy.

This post has been edited by AdamSpeight2008: 09 March 2012 - 04:47 PM

[tlhIn`toq]

Quote

in particular the Dispose pattern makes me wonder how its possible to write C# code without needing massive amounts of boilerplate everywhere to clean up non-memory resources

I hated C++, in part for this exact reason, only in reverse.
It seemed to me that a massive amount of responsibility was left on the coder to be sure they disposed of everything they made when it went out of scope, otherwise you created the dreaded 'memory leak'. I alway thought "There has to be a better way. When the OS realizes I'm not using that xyz any more and there are no references to it, then kill it your own damned self. If I have a very specific and rare occassion to keep it alive, I'll mark it as such" "unsafe" as it turned out would be how you do that.

I also hated C++ need for .h files. I mean really, I need to define the signature over here... then write the method over there... and if I change one I have to change the other because the IDE isn't that bright...

Very rarely do I even encounter things that aren't disposed of automatically. My dispose methods tend to consist of nicety stuff like raising an event if the object is dirty so the user can be offered the option of saving their changes. The exception there is GDI+ plus drawing and low-level bitmap manipulation. But it becomes automatic. You make the whatever in a using{} block so it disposes of itself when it is done. That's just the way its used. It becomes the syntax, no different than separating values with ;'s in a for loop.

Quote

Is it maybe the case that C++ has taught me to become so hung up on object ownership

Maybe. This sounds like my boss. Its all about micromanagment of his code. He *has* to do and track and sync everything himself. The idea that he doesn't have to keep arraylists of indexnumbers so he can decide when something dies just feels wrong to him.

I think its the same mindset that keeps some people away from Macintoshes: What do you mean there isn't a command line where I can micromanage every last command with a string of 50 /switches? Get over it: Its not 1980 any more and this isn't DOS.

Same with C#. Just dive in. Let all your cares go. Trust in the IDE. Use the tools it gives you like IntelliSense and the ability to refactor smartly where it will change all of the references instead of you doing it through Find/Replace like you are on WordStar.

Work these two tutorials. Then tell me if it doesn't hold some potential for you:
Bulding an application - Part 1
Building an application - Part 2

[Psyguy]

tlhIn'toq, you crack me up! Always entertaining.

This post has been edited by Psyguy: 09 March 2012 - 04:47 PM

[AdamSpeight2008]

RX ( LINQ over Streams) has a what I think is a simply elegant use of .Dispose

Have a look in the C# News And Articles Section for a few, recent Event Talks.

If you want to see what the IDE can be made to do. I strongly suggest watching the Project Rosyln one.
Or want your brains to implode. Behind The Scenes Of C# 5.0 And Visual Basic 11 "Async"

You to use Plug-In architecture design look at MEF.
Code-By-Contract

This post has been edited by AdamSpeight2008: 09 March 2012 - 05:15 PM

[MrShoes]

I took a diploma in C++ and always found it so difficult to master; just when you think you have it, boom, stack overflow.

I taught myself C# much later and it really is much better. If a piece of software demanded so much of you as C++ it would be labelled unfit for purpose.

On saying that, I've just left a 2nd interview for my first software developer job (purely been a hobby until now) and one reason they're interested in me is because they have legacy C++ applications that need some attention. *sigh*

[marty617]

IoC is a broad topic, so I will only speak to the pimary way take advantage of it. First I would also like to state that I find the term to be unfortunately misleading. I can't see the control is being really inverted. I think the way it does not go against ecapsulation is that a central controller only needs to know how to interact with the services it is being told to use and the requestor of those services only needs to know the collection of services it wants to be provided. None of the actors involved needs to know how the other is achieving their divided tasks. I know this is a limited application of the broad topic of IoC, but it is sort of a pluggable module approach to programming that is very object oriented, imho. Dependency Injection it just a mechanism that the consumer of a class can tell it what to use, it it still completely ignorant of how it is being using or what it is doing.