More of a general question on Code Organization..

[USNavyFish]

Hey folks, thanks for taking the time to read my post.

I'm trying to develop a clean way to organize my latest program (first time developing with C#). I'm trying to avoid global/public variables while at the same time trying to avoid massive chains of function calls, particularly on performance-sensitive blocks (i.e. rendering).

So first off, I have a MainForm class, which represents the primary window of my application (and is utilized by the Application.Run() function within Main(). The first question I have is about this MainForm class - should I make this static? I have no intention of allowing multiple instances of the window open. The alternative to this would be to create a public instance of the MainForm class, stored in the Program class, so that other classes in my program can access the mainForm. The second solution feels a bit ugly, but is generally what I've done in the past. Any comments?

Next, I use an openGL control within my MainForm (thanks to the TAO library). I would like some other classes (particularly, the Graphics Class) to have access to this control, i.e. to determine its size etc. Currently, I pass it the the graphics class's constructor, and allow the graphics class to store a reference to the control locally. This again feels ugly, and basically entangles the two classes.

It feels like I'm only really using classes to put code into separate files. They all end up horribly intertwined anyway! How do you handle this situation? Something I've considered is making various controls on my UI class read-only (not through the keyword but by creating a public property which only defines a get accessor), so that other classes can access but not modify them... but then this brings up the problem of having to create a program-wide public (global) instance of the UI! Kinda brings us back to square one.


As you can probably guess, I'm suffering this 'problem' throughout all of my work. Yeah, I've gotten better over time, but still don't feel like it's down solid. I'm not looking for a particular answer - instead, I'm hoping to hear some methodologies or general guidelines that you guys have adopted over time.

Again, thanks for reading the post, despite its slight-rambling. I look forward to learning some new tricks!

[Arjay]

Hey folks, thanks for taking the time to read my post.

I'm trying to develop a clean way to organize my latest program (first time developing with C#). I'm trying to avoid global/public variables while at the same time trying to avoid massive chains of function calls, particularly on performance-sensitive blocks (i.e. rendering).

You don't have to worry about that, since C# doesn't allow global values.

So first off, I have a MainForm class, which represents the primary window of my application (and is utilized by the Application.Run() function within Main(). The first question I have is about this MainForm class - should I make this static? I have no intention of allowing multiple instances of the window open. The alternative to this would be to create a public instance of the MainForm class, stored in the Program class, so that other classes in my program can access the mainForm. The second solution feels a bit ugly, but is generally what I've done in the past. Any comments?

No need to make it static. Are you going to create two instances of it? Probably not, and no one else is either, so don't sweat it.

Next, I use an openGL control within my MainForm (thanks to the TAO library). I would like some other classes (particularly, the Graphics Class) to have access to this control, i.e. to determine its size etc. Currently, I pass it the the graphics class's constructor, and allow the graphics class to store a reference to the control locally. This again feels ugly, and basically entangles the two classes.

If you are worried about this, then just pass the size/position data.

It feels like I'm only really using classes to put code into separate files. They all end up horribly intertwined anyway! How do you handle this situation? Something I've considered is making various controls on my UI class read-only (not through the keyword but by creating a public property which only defines a get accessor), so that other classes can access but not modify them... but then this brings up the problem of having to create a program-wide public (global) instance of the UI! Kinda brings us back to square one.

There isn't any concept of global in C#. Classes shouldn't be designed based on file layout. You might want to read up on how to design a classes for a given problem. It doesn't really relate to files (btw, with partial classes, a class can be defined over several different cs files).

[vcdebugger]

Even I am working on a similar kind of setup for my project. Sometimes you feel you have to leave with it as your application requirement is so complex and get used to dealing with classes getting entangled with in one another !!

mine is basically a design tool ( UML tool) developed in C# for drawing various UML diagrams...

[darwen]

Sometimes you feel you have to leave with it as your application requirement is so complex and get used to dealing with classes getting entangled with in one another !!

That's where Test Driven Development comes in.

In addition to giving you good unit test coverage, I've found it also helps you organise and design your application.

Darwen.

[vcdebugger]

can you provide useful links for that test driven development...

[darwen]

Try googling... that's all I would do to give you the links

Darwen.

[USNavyFish]

I wiki'd Test-Driven Development.. http://en.wikipedia.org/wiki/Test-driven_development

Thanks for mentioning that practice.. It seems like a really good idea. I like the notion of feature-oriented programming, getting the program to first produce a desired result and only then going back to refactor.

@Arjay - thanks for the feedback. I am aware that 'Globals' aren't a part of C# per-se, but I am using that term to describe a public variable within the main "Program" class. Not technically the same, but I think the end functionality is similar to a global. Of course correct me if I'm wrong!


W.R.T. Partial classes - I have seen the Visual designer spread my MainForm over several files, using partial. I think that's very convenient, so I don't have to see all the initialization code for the controls and their properties. Would you elaborate on what you mean by "Classes shouldn't be designed based on file layout" ? I'm under the impression that it's best to make no more than one class per file (and one class can be spread over multiple files using partial). Is this what you mean?

If you are worried about this, then just pass the size/position data.

Yes, I think that is good advice. It also seems to agree well with the TDD concept. I think I will apply that kind of solution to alot of other classes - basically, have them send only the required data to another function (i.e. just width/height instead of the whole object's reference). Of course, there will still be cases when one class requires data members from another....

And that's my next question.. Say I have a MainForm class and Input class. When the input class calls its "ProcessPolledInput" function, it needs to check if MainForm.ActiveControl == MainForm.openGLControl.. and only process the input (i.e. WASD for movement) if the openGLControl is active.

Of course, the issue here is how to give the Input class access to the MainForm class, WITHOUT writing "MainForm.openGLControl" into my ProcessPolledInput function - because doing so essentially ties the two classes together.

The only solution I've got so far is to create private instances of each class (i.e. MainForm, Graphics, Input) within the program class, then locate my update loop in the program class, and have that loop pass these private members back and forth between each other, i.e.:

public Class Program
{
     private MainForm _MainForm;
     private Input _Input;

     ...

     private void UpdateLoop()
     {
           ...
           If ( _MainForm.ActiveControl == _MainForm.openGLControl)
           {
                 _Input.ProcessPolledInput(_MainForm.openGLControl);
           }
           ...
     }
}

I suppose it's OK to expose openGLControl in this way, through the use of a Property, or the readonly keyword (I might shy away from properties due to the extra CIL-overhead, especially since this particular function call is made very often).


Any more tips or techniques on good ways to expose data members in a consistent, logical way while avoiding a mess of entanglement? Again, thanks for reading..

[Arjay]

USNavy, since you are just stating development with C#, I'd skip the whole Winforms route and move directly to WPF (Windows Presentation Foundation).

One of the goals of design is to decouple the UI from the business logic and there are several design patterns that help with this (MVC, MVP, MV-VM, etc.).

In my opinion, because WPF has more advanced data binding than WinForms, the application of design pattern is more straightforward.

WPF also offers greater control customization capabilities, dynamic skinning and other features over WinForms.

[USNavyFish]

WPF and XAML certainly look interesting. I'm concerned about the performance of 3D applications though. That and having to learn a version of D3D (not even the full thing, I take it). I'm fairly well into OpenGL at this point, and jumping ship isn't very appealing.

Then again, the flexibility of those interfaces, and the fact that all the UI is basically in a XAML file and not mucking up my code is pretty neat.

Thanks for the recommendation. Not sure what I'll end up doing in the long run, but in the short-run I'm sticking with my TAO-enabled WinForms, OpenGL... and perhaps a few small projects to learn WPF, on the side ;-)

[vcdebugger]

Try googling... that's all I would do to give you the links

Darwen.

thanks for that