I also experienced analysis paralysis Basically, it''s a mental juggling of all possible cases and what effects are caused to the design when you change something. The reason this doesn''t work is because it breaks the fundamental human concept of learning from your mistakes. You''re basically trying to create a perfect system the first time out which is impossible for us humans. You learn by dealing with problems as they come up. I have a large program and there is a lot of interaction in it, trying to write this down on a blackboard is completely nuts. You would need several miles of blackboard and a chalk the size of eifel tower.

What you can do however is describe concepts that you can then make objects from. However, due to the nature of our windowing apis and other ones as well they will restrain you in unexpected ways. This won''t be evident to you at design stage because you lack the api specifics. Even worse, the api changes under your feet invalidating your original design. Completely outside your control in today''s age unless you make everything yourself.

So what you do is describe the few important objects you need and hope that the rest will be discovered at later time when your initial codebase is complete. That is why you need a code design that can grow with you and can adapt w/o you having to recode stuff all the time. Hierarchial design is not good for this because it needs to be well defined upstairs and like I''ve said you won''t discover all your concepts ahead of time and most likely you''ll change your mind along the way thru the years that you''re coding it. Major changes like xforming your first person shooter engine into a vastly outdoors terrain role playing engine and such things. Our taste changes with time because we''re growing mentally.

I think the more general term is "analysis paralysis", which applies to other fields of engineering as well.

Object-Oriented Design Heuristics by Arthur J. Riel is an excellent book that really help me with some of the issues you are grappling with. I highly reccomend this book.

"Discipline is never an end itself, only a means to an end." - Robert Fripp

quote:Original post by sprinter_trueno
To specifiy my problems more clearer I'll give you some thoughts:
1. When will objects be created ? (When is it fitting, stack ?)
2. By whom ? (objects and especially threads)
3. Who takes care of them ? (Getting rid of them and such)
All of these very abstract question can be answered quite easily with 'The way I want it'. Yes, my program will of course work but I never have the feeling that I did a good job. Maybe because it is total crap or just that I don't have any reassurance of what I'm doing. It's killing me.

One thing you'll begin to notice while doing OOP is that it is an iterative process. You're not going to come up with the BEST design the first time around (unless you're super cool). What you need to strive to do (and I'll agree, it's tough to tell if you're doing it right) is make is so that the changes you do make don't reverberate through the rest of the code.
I'll start by addressing your questions first.

1.) What I like to do is create the objects themselves on the "stack", but allow them to use an alloc() method that creates all of their memory on the heap (using "new"). How would you go about this? The following is the abstract class that just about every object I create derives from:

class CBaseObject{public:     CBaseObject(){}     virtual ~CBaseObject(){}     virtual bool Init() = 0;     virtual bool Alloc() = 0;     virtual bool Destroy() = 0;};   

This allows me to follow some rules for how I'm going to do my work. Init() initializes my object (so I can re-use the stack based data), Alloc() allocates any memory I need to use (beyond basic data-types), and Destroy() de-allocates all that memory.

This is by no means the "right" answer, just how I tend to do things, and have been very happy with it. I also place calls to Init() and Destroy() in my constructors and destructors.

2.) If you are creating data to be accessed by multiple threads, just make sure you have some sort of locking mechanism built in. Generally, if I'm making a new thread, I try to have that thread started from the thread that "owns" it. Some people will have all threads spawned at the base application level, and although that works, I think it is less intuitive.

3.) Assume that you must take care of everything. If you only need a variable for 5 lines of code, and especially if it uses a lot of memory, scope it so that it's only around while you need it.

As for "writing crap", the fact that you're worried about design places you in a "better" category, at least you care. Sit down and draw some pictures before you start coding. Well designed code can feel/look like artwork, because of how well it can work. Try to map out where things get used, how you intend to use them, where things overlap, etc. Try to find out early on how flexible you want something to be...the more you can plan for ahead of time, the better you'll be.

Another hint that I'd give is that coding style and methods are important too. So many "samples" out there have classes/implementations spread all over the place. Unless the classes are very similar, or utility classes, just have one class per header and implementation file. Try to choose a coding style, and stick to it.

Honestly though, you'll never feel like you've got the "best" solution, because really, you probably don't. I bet you've got a good one though...
Good luck.

- sighuh?

[edited by - redragon on March 17, 2003 3:20:02 PM]

[edited by - redragon on March 17, 2003 3:20:26 PM]

quote:Original post by redragon
I also place calls to Init() and Destroy() in my constructors and destructors.

You are calling virtual methods from ctors and dtors?



"If there is a God, he is a malign thug."
-- Mark Twain

quote:Original post by Arild Fines
You are calling virtual methods from ctors and dtors?

I only call them in the classes that implement them...can't do it in the base level, as they may not be implemented.

- sighuh?

[edited by - redragon on March 17, 2003 10:43:13 PM]