The correct way to organize source code into classes

Hello, fellow programmers!

I have a question about organizing code into logical classes. I am aware of the OOP paradigm that classes should be as much as possible self-contained and self-sufficient. However, each time I am working on a program with more than 5000 lines of code I run into problems creating classes that fit these requirements. I end up with either a number of globally-accessible objects or a huge main class which contains many other classes. I either case they very closely interdependent.

Let me give you an example. Let's say that I am programming a game. Here is a structure I always end up with, and it feels horribly clumsy and incorrect (although it works perfectly fine):

• class Game is the "main" class, and will during whole running time have only one instance created of itself. It initializes instances following classes: TexturePool (loads textures), MissileEngine (handles collision and rendering of missiles), Level (contains level topology, objects, performs collision detection and more)
• The problem here is that all of the aforementioned classes have only one instance during runtime, which makes me feel that OOP is out of place here. Also, TexturePool and MissileEngine need to be available globally since classes GameObject and Player (inherits GameObject) need these to load textures and shoot missiles, respectively. Furthermore, MissileEngine needs access to TexturePool to load missile textures.
• As you see, there is a huge interdependence between classes.

This was just an abridged version of the source code structure, however I hope you understand where I am going with this. Since I have no formal education in programming, I am not sure this is the way it is supposed to be.

If you have any suggestions for me, I will be more than glad to hear them! The same applies for any books on the subject you might recommend.

Thanks in advance!

How much design work do you do before cranking out 5K lines?

To be really effective, the "OO" benefits some up-front design to establish a basic framework for the major components.

Amazon.com: UML Distilled: A Brief Guide to the Standard Object Modeling Language (2nd Edition) (0785342657838): Martin Fowler, Kendall Scott: Books
UML is a monster, so don't get worried if you don't use all of it all the time (no one worries if you don't use every aspect of the C++ STL in every program). If you think some design feature (say Entity Relationship Diagrams) will help you understand the problem, then use them.

Ruled Index Cards
Use one card for each class.
Draw a line down the middle; on the left write down member variables, and on the right put your member functions. Across the top, write your class name.
If you run out of room, consider that a hint to break your class up into several sub-classes.
Sticky yellow notes can also be used for this purpose.

Once you have your classes, and an ERD say showing the relationships between them, you can "run" use-cases through your model (say "fire missile") to work out which classes and member functions are invoked. If it doesn't work here, then it won't work in code either (but at the design stage, it's an easy fix).

When you're happy that the significant stuff seems to work (you can get stuck in the analysis phase, forever tweaking the design and never getting around to writing the code), you'll have a nice point of reference as to what you should be aiming for. There will of course be some tweaking along the way. If the implementation is getting stuck, then feed back that into your model and do a bit more refining.

Quote:

---

Originally Posted by MathFan

[*]The problem here is that all of the aforementioned classes have only one instance during runtime, which makes me feel that OOP is out of place here.

---

My cubicle has only one desk, one chair, one filing cabinet and one telephone in it -- they're still objects.

Quote:

---

The same applies for any books on the subject you might recommend.

---

The omniscient Code Complete, of course :D.

Thank you very much for the input, everyone!

Quote:

---

Originally Posted by Salem

How much design work do you do before cranking out 5K lines?

---

Next to none I am afraid. I oftentimes find that defining the design beforehand tends to work poorly in the long run because I can never foresee all the problems I encounter during coding. Also, I often re-use the most self-sufficient classes from my earlier works; this tends to lock me into a certain design mindset which of course might be far from beneficial (it saves me some time though).

But then again I've never had any efficient tools to do designing with (besides pen+paper). Never knew about UML, so I should definitely check it out - thanks for the link.

Quote:

---

Originally Posted by Salem

If you run out of room, consider that a hint to break your class up into several sub-classes.

---

That's an interesting idea as well. Which actually leads me to believe that I should perhaps really use more inheritance - since by looking at my code, it is only used a handful of time.

Quote:

---

Originally Posted by brewbuck

My cubicle has only one desk, one chair, one filing cabinet and one telephone in it -- they're still objects.

---

Hehe, point taken, thanks :)