I am an experienced C++ developer, I know the language in great details and have used some of its specific features intensively. Also, I know principles of OOD and design patterns. I am now learning C# but I cannot stop the feeling not being able to get rid of C++ mindset. I tied myself so hard to the strengths of C++ that I cannot live without some of the features. And I cannot find any good workarounds or replacements for them in C#.
What good practices, design patterns, idioms that are different in C# from C++ perspective can you suggest? How to get a perfect C++ design not looking dumb in C#?
Specifically, I cannot find a good C#-ish way to deal with (recent examples):
- Controlling the lifetime of resources that require deterministic cleanup (like files). This is easy having
usingin hand but how to use it properly when ownership of the resource is being transfered [… betwen threads]? In C++ I would simply use shared pointers and let it take care of 'garbage collection' just at the right time. - Constant struggling with overriding functions for specific generics (I love things like partial template specialization in C++). Should I just abandon any attempts to do any generic programming in C#? Maybe generics are limited on purpose and it is not C#-ish to use them except for a specific domain of problems?
- Macro-like functionality. While generally a bad idea, for some domain of problems there is no other workaround (e.g. conditional evaluation of a statement, like with logs that should only go to Debug releases). Not having them means that I need to put more
if (condition) {...}boilerplate and it is still not equal in terms of triggering side effects.
Best Answer
In my experience, there is no book to do this. Forums help with idioms and best practices, but in the end you're going to have to put in the time. Practice by solving a number of different problems in C#. Look at what was hard/awkward and try to make them less hard and less awkward next time. For me, this process took about a month before I "got it".
The biggest thing to focus on is the lack of memory management. In C++ this lords over every single design decision you make, but in C# it is counter productive. In C#, you often want to ignore the death or other state transitions of your objects. That sort of association adds unnecessary coupling.
Mostly, focus on using the new tools most effectively, not beating yourself up over an attachment to the old ones.
By realizing that different idioms push towards different design approaches. You can't just port something 1:1 between (most) languages and expect something beautiful and idiomatic on the other end.
But in response to specific scenarios:
Shared unmanaged resources - This was a bad idea in C++, and is just as much a bad idea in C#. If you have a file then open it, use it, and close it. Sharing it between threads is just asking for trouble, and if only one thread is really using it then have that thread open/own/close it. If you really have a long lived file for some reason, then make a class to represent that and let the application manage that as needed (close before exit, tie close to Application Closing sort of events, etc)
Partial Template Specialization - You're out of luck here, though the more I've used C# the more I find the template usage I did in C++ to fall into YAGNI. Why make something generic when T is always an int? Other scenarios are best solved in C# by liberal application of interfaces. You don't need generics when an interface or delegate type can strongly type what you want to vary.
Preprocessor conditionals - C# has
#if, go nuts. Better yet, it has conditional attributes that will simply drop that function from the code if a compiler symbol is not defined.