quote:Original post by tangentz
...after you've declared "i prefer the Functional Without Wasting Weeks Of Typing Way (tm)"...This thread not only shows that you are stubborn as a
programmer...

Just remember that those who insist you must get the perfect design in spite of all else (including how long it takes to get things done) are just as stubborn (spending excessive time trying to get it perfect and ignoring that fact that they arent getting it done). If your goal is research or to make a highly extendable library, then do it right. Otherwise, if you goal is to finish a product and you know you have a set domain to make it work in, then make a reasonable effort to get it right, but dont get completely hung up on it.

Also be aware that, especially your first couple of times performing a particular task, it can be quite a bit difficult to predict how things are going to turn out and what is going to need to be done. Several times before, I have sat down and done a complete design of something, only to find out later that something I could never have predicted (simply because of lack of experience in the particular domain) threw my design considerably off and would either need to be special cased here and there (requiring a kludge, but a minimun of effort) or a more substantial rewrite of several other areas of the code. Usually, my choice is to special case it and get it done. If I find I have enough special cases that things start to get messy, I go back and (using my new found knowledge) begin to clean things up and fix things the correct way. Note, however, that by the time I get this far (where I decide to rewrite), I have usually discovered several mistakes in my design. Had I reworked it the first time, I would have wasted effort since it would have needed reworking again.

Remembering that (for the most part) we are amateur game developers here, and I suspect relatively few of us have written more than 3 or 4 games of any significant size, a lot of mistakes are going to be made simply becuase of unfamiliarity with the problem domain. Add to that the fact that even if you do come up with the 100% perfect design, sometimes things change mid project. This could be because someone else calling the shots forgot to tell you something important, or even that you discovered after implementing things that your nontechnical design just didnt work out right. In my current project, I had a design from day one, and it seemed (in theory) to be great. However, after getting midway through development, the process of actually playing the game proved that some things just werent as fun as they seemed on paper. Things change. Part of being experienced is knowing when to redesign and when to hack it.

Edited by - LordKronos on February 28, 2002 1:36:25 PM

quote:Original post by SabreMan
One of my heuristics is that you don''t code long dynamic_cast<> chains unless you really have to. I remain unconvinced that krez really needs dynamic_cast<>.

Nobody said he needs to use dynamic_cast. His other option is to redesign his class hierarchy. The thing is, everybody is coming down on him as if to say "if he were smart he would redesign, only a fool would resort to dynamic_cast". Thats not the case. There are other factors involved. He may not have the time to figure out the proper design. He may have too much code invested in the current design. Or he may have a bunch of other problems which he, at this point, cant even figure out the right way to refactor without creating a bunch of silly virtual methods that are twice as kludgy as dynamic_cast.