Archived

This topic is now archived and is closed to further replies.

Basic OO Software Design

This topic is 5121 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I''m someone who wouldn''t probably be called a beginner anymore but am still finding my way learning to code in C++. I feel I''ve mastered most of the basics by reading thro Accelerated C++ and C++ in 21 Days. I''m now ploughing thro "Design Patterns" by Gamma et al. I have had a go at programming some simple games in MFC (ie pong, Tetris etc) and a more complex game which is the beginnings of a game based around Railroad Tycoon. Anyway my problem with all this has been designing effective classes. In particular deciding what aspects of what I''m modelling should be represented by a class and how to design the interface for each class and deciding how they should interact. An example of the problems I''m having is with things like accesor functions. Some of my classes seem to need accessor functions for most of their members (usually for read only). All this seems to me to be down to poor design. So I''m hoping some of you guys could give me advice on the approach I should use when designing a game. ie What I should be doing before I even start coding. I haven''t bothered to learn UML or anything similar as I am working alone at the moment on relatively small projects and need advice on structuring and documenting the design process for such small projects so I design better more flexible code. Thanks Jon

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Making a game is alot of work. Decide what you want to do, and allocate your time toward that. For everything else, find a library or an open source solution. That''s your best bet for completing a solo project.

From your post it seems your intrested in how to design the class framework for a game. The rule is design to the specficiations. Most likely you''ve got poor or vague specifications, and this in turns results in poor or vauge class structures.

If there are unknowns, you can factor them into the class framework so as to minimize the impact of additional code and possibly a refactoring. So dont let unknowns stop you.

Games usually are designed, their technical specificaiton written up and enumareted, and then a general framwork is devised. The better the techinical specificaiton, usually the code framework will be too.

Good Luck.

-ddn

Share this post


Link to post
Share on other sites
I think that you are making a good start on learning more about OO Software Design by taking a look at the design patterns book. You''ll get a good understanding for several elegant ways of handling various different problems and it should inspire you a little more.

I''d also recommend the PLOP (pattern languages of programming) series of books. These are a little more advanced than the design patterns, although with similar intent. Just more detailed and complete.

The Meyers books Effective C++ and More Effective C++ can also teach you a lot about good practices.

However, pick and choose what you think is useful and remember that these things aren''t the ''be all and end all'' of programming. You''ll do well to read these things, but experimenting with variants of these ideas, looking at other code and gaining more and more experience as an OO programmer is what you really need to do.

As for UML. I''m a strong proponent of it and you might want to learn a very basic level of common notation just in case you come across some interesting diagrams you can learn from. However, I''d recommend against learning it now in full as you''ll likely give yourself far too much to study - and this is the killer of time better spent developing and learning.

Share this post


Link to post
Share on other sites
Bjarne S. interview that I find interesting:

http://www.artima.com/articles/index.jsp

the one titled "c++ sweet spot"

I think the idea is to model behavior and a bit of state as well. I think behavior is more important because that''s what defines hierarchies. I think people are moving away from deep hierarchies and into shallow/flat ones layering them and putting them into components or using the bridge pattern to separate implementation from interface so the impl. can vary. This adds flexibility. I think open/close principle is also useful. I used the state pattern with finite state machine to close event handler switch code and put logic into separate tasks.

You know those accessors are necessary so that you don''t end up with an object with huge public interface(you can actually have the whole program in a single object). It''s a hierarchial data structure which is better split into more sections so those can communicate. It''s a tradeoff there isn''t a black or white here but gray areas. You do need out of class worker functions when a func is manipulating two unrelated types. I did a.merge(b) with objects which suprisingly got rid of lots of code from merge(a,b)and it worked because a&b were same type. Anyways, if you think about it, you could have been done with the project if you used C instead. Design is always about tradeoffs and there is a reason why John Carmack writes engines in C still. The OO might be overkill here. Though it works great for game logic.

Share this post


Link to post
Share on other sites
The most important thing in *any* software project is clear requirements. You can''t build it if you don''t know what it is. I prefer a lot of the practices from the Extreme Programming methodology. XP calls for iterative development and discourages doing a huge up front design before any coding. Rather, design, code, test, refactor, repeat. (Actually, true XP''ers put test before code). Add a feature at a time and always have a working system, no matter how small the feature set.

For more on this, Google for Extreme Programming.

--
Dave Mikesell Software & Consulting

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I''ve found iterative developement only works after one has gained a sufficently broad knowledge of successfull software techniques and practices. If your starting out, using XP won''t be that benifical, i feel. Start with small projects and design them as through as you can. The idea is with small projects you can in theory design the entire framework, as they have fewer components and are less likely to change requirements. Then once you''ve implemented the framework, you will have a better idea of how to improve or reuse the framework. From there increasing your knowledge base and fundemntals software engineering pratices. Once you''ve implemetned a few frameworks, i think then you can really do iterative developement. Otherwise, you might not have the experience to know when or how to refine your design.

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
On the other hand, Dion Picco aka Turd Ferguson always wrote the code. And rewrote it. And rewrote it for optimization. Etc. Iterative can have many meanings, and the thing is that you''re going to iterate regardless. Applying a formal mechanism can sometimes help focus efforts.

ld

Share this post


Link to post
Share on other sites