Hi Jim,I have a few ideas for you to think about. These are in no particular order, just as I thought of them.
1. Writing down some sort of description of what you want is helpful. If nothing else, it focuses your ideas and clarifies your thinking. After all, if it sounds bad in writing it very well may not be cooked enough.
2. Focusing on dominant nouns in your description generally leads to dominant objects in your system. Other helper objects will, of course, be required as well.
3. Think of object oriented design primarily as a system architecting approach. You will want to use your "structured design" knowledge to structure methods within your objects.
4. You can create object inheritance structure charts just like your previous structure charts, they are really just organization charts for objects.
5. One thing I find useful is to have an overall abstraction that I am trying to model in software. This should work well for a game situation. For example a Monopoly game would have objects like:
a) board object (container object) b) properties base class objectc) various derived property objects like Boardwalk with their own rental rates etc.
d) a bank for each player e) houses/hotels to purchase and put on properties f) and so forth6. The abstract model above leads to methods to produce the required transactions and procedures required to play the game. In Monopoly, most of what is going on is normal sort of financial transactions everyone is generally familiar with.
There may be more, but this should give you a start. Also I like some of Jamal's extreme programming ideas, but I think you need some overall directional guidance first. But don't be reluctant to rip out code and retool when something is not working. I think the biggest mistake most programmers make is reluctance to throw away bad code.
Richard----- Original Message ----- From: <james.homme@xxxxxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx> Sent: Thursday, December 20, 2007 8:50 AM Subject: How Do You Plan An OO Project?
Hi, I know how to write pseudocode for a procedure program. I had to do thatwhen I was learning Cobol. We used things called structure charts. I made atext version of my structure charts that was vertical. Then, I'd refer to it when I was writing my procedures.Let's say I want to make an object oriented version of Tic Tac Toe. I wouldstart with getting the rules to the game. Then, to figure out the objects my program has and how they would behave, how would I write my plan?I have some related questions, but I'd like to save them for another email.Thanks. Jim James D Homme, , Usability Engineering, Highmark Inc., james.homme@xxxxxxxxxxxx, 412-544-1810 "Never doubt that a thoughtful group of committed citizens can change the world. Indeed, it is the only thing that ever has." -- Margaret Mead __________ View the list's information and change your settings at //www.freelists.org/list/programmingblind
__________View the list's information and change your settings at //www.freelists.org/list/programmingblind
