Well that's me mildly patronised! :P I'm not a fan of applying the OO mindset universally as it happens (if for no other reason than this.whatever looking so damn ugly), but that's got nothing to do with my complaint.
Well, my intention wasn't to insult you. So please accept my apologies if I did. You admitted yourself that you were new. I've mentored a fair number of procedural developers to get them to wrap their minds around the OO concept and they all say the same things you did.
Studio does let you define all of the classes in a single file should you want to do that. I imagine for documenting purposes, it's easier to say "refer to file X rather than, look for class at around line ###".
It's all about standardizing your code and applying best practices.
Granted, 80% of the time, the code only needs to be readable by yourself, if you ever want to evolve into a development team, a lot of time is wasted comprehending unpredictable code when you're not conforming to some agreed upon standard. One class per file is a pretty standard way of going about things. This keeps items isolated, and especially if you're using source control, more are able to work on a project without worrying about stepping on each other's code.
To be fair, games are typically not the investment that an enterprise-level application is. So, I suppose it's possible to be overly paranoid about how agile your application needs to be. But then, it doesn't hurt to subscribe to best practices so you can move that habit to gigs that might require several developers on the same project.
Microsoft gets put into a weird position. They're trying to attract the amateurs, yet also need to be compelling to the experienced. From that position, it doesn't hurt to expose amateurs to best practices, as doing something contrary to that hurts their credibility with the experienced.
It's akin to visiting a foreign country. If you're an American tourist visiting Germany, you can't expect everyone there to change their lifestyle around yours. You either attempt to understand their way of life, and fit in or be frustrated in a way that nobody else but yourself cares about.
I know that sounds a little elitist, but that's really the harsh reality of it all.
Isn't this the classic problem with reading and deciphering OO source?
The only time I've had a rough time deciphering OO source-code is when the naming conventions and methods are not terribly self expressive, or common mistakes are made (such as non-side-effect free functions)
Again, you need to change the mindset. OO applications are not "top-down". They exist as an aggregate of "entities" that interact with one another.
I wrote a long reply to the above, but ended up way off topic ('just an implementation detail' indeed - don't get me started!).
Doesn't BlitzMax allow you to switch out OpenGL and DirectX by a single statement (SetGraphicsDriver or something like that)?
At least from my point of view, that illustrates that the engine underneath is an implementation detail.
From your point of view as the API developer, that might be over-simplifying it. BUT, from the client code perspective, that's exactly what it is.
What exactly does C#/XNA have over, say, C++/OpenGL (or even C++/D3D or C#/D3D)?
I haven't browsed too deeply into XNA, but as others have mentioned above, you get the advantages of managed code.
You also get the benefit of IL deployment rather than building a binary for every machine you're targetting. (Java byte code has the same advantage if you were to choose that development platform)
XNA for Mono is well under way. Hopefully allowing deployment to platforms not owned by Microsoft.
The only thing I am not terribly happy about so far with XNA is that it seems to marry your application to DirectX. Therefore, if you want to be able to treat the rendering pipeline as an implementation detail, you would need to take the abstraction out a bit and provide a "common" facade/interface to OpenGL and DirectX.
I know in areas of .Net that have competing providers (i.e. SQL Server vs. Oracle, Source Safe vs. Vaut, etc), Microsoft has created interfaces to allow these environments to interact between one another as plug ins (they call them "providers"). If they haven't done this with the DirectX, hopefully they will in the future so a third party can create a compatible OpenGL provider and allow client applications to utilize it by means of a strategy pattern.
XNA appears technically to be another entry into Microsoft's patterns and practices code blocks.
"They suck" doesn't really help me. Any specific examples I can get my teeth into? I've never had a problem refactoring anything in Express, from variables to function calls. I'm wondering what I should be watching out for that Resharper will help with.
You really do need to try it to see the difference. It takes a little bit of getting used to if you're accustomed to the native refactoring tools, but once you get by that, you might find yourself unable to live without it.
Some of the finer points that re-sharper provides..
- Intellisense is enhanced to narrow the list of selectable items by what you've typed so far (as opposed to just bringing you to that area of the drop-down box)
- Non-inherited methods/properties/members are shown in bold in intellisense
- Code analysis that greys out non-executing or unnecessary code (i.e. you do an unnecessary cast, it will tell you about it, if you're importing unnecessary modules, those grey out as well)
- Hash marks on the side of your source code that allows you to jump immediately to errors and areas that could be tuned.
- Automatically putting end braces, parathesis, etc. in, and placing your cursor between them for your entry
- Re-ordering of parameters on methods will intelligently scan your code and handle the changes on the callers.
Believe it or not, this is a very SMALL list right from the top of my head of the elaborate set of features in re-sharper.