C++ – When one should use template specialization, if not for metaprogramming

Whether C++ or JAVA, a Notification to the observer can come along with the information of what is changed. The same methods notifyObservers(Object arg) can also be used in C++ as well.

Generally, the issue will remain is that there could be multiple subjects dispatching to one or multiple observers and hence, the class arg cannot be hard coded.

Usually, the best way to do is to make arg in the form of generic message/tokens that forms the same data type for various classes but values differ for different observed classes. Alternatively, if all such notification values are derived out of the class on some based class which is common to all.

For observer pattern, it is important that Arg data type is not hard coded between the observee and observer - else it is a coupling that makes things difficult to evolve.

EDIT
If you want that observer not only observes but also needs to do a lot of other tasks based on the what has changed then, you can also check out Visitor pattern. In visitor pattern, the observer/visitor calls the modified object and hence can not only know what the modification is but can actually work on it

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.

How to get a perfect C++ design not looking dumb in C#?

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.