I have a project that I've chosen as my first project in my quest to teach myself Java. I've written a bunch of little programs that do trivial things, but that's losing my interest so I'm doing one larger one that'll incorporate many aspects of Java.
I need to start writing some pseudocode to organize thoughts, classes, etc. I don't know where to start. Its not that I don't understand pseudo, but rather I don't know how to organize things and group things. I know to build one piece at a time and add pieces slowly.
I'm having the worst time explaining my dilemma, but basically its where do I start. Writing small stuff according to an "assignment" is easy especially when its 20 lines all contained in main.
Overall, I know what the program will do at completion, but how do I segregate that off into smaller sections. I assume I will have one main larger section and the others will contain methods that the main will be able to call?
Putting 20 lines in main might be useful for testing segments of code (or demonstrating basic language concepts), but it's definitely not helpful from an object-oriented perspective.
So I suggest thinking about what sort of objects your program might need. For example, if your program were a car, then you might define separate objects to represent the engine, transmission, air conditioner, stereo, adjustable seat, etc. Note that each of these might contain other objects as members. For example, Engine might contain 6 instances of Cylinder, and each instance of Cylinder might contain an instance of Sparkplug.
As you're identifying your objects, think about what each of these do, and how they send messages to one another. For example, what happens when the arc() method of Sparkplug is called? [ November 21, 2004: Message edited by: marc weber ]
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
There are a couple approaches to breaking up big problems. Functional decomposition is associated with procedural programming, currently out of favor but not altogether evil. I still use it just to get a handle on what needs to be done even if it doesn't translate directly into my design. Object oriented design starts thinking about objects at the beginning of the process. If you read books on OO design you may come away thinking there is a moment of magic when the author asks you not to look behind the curtain as he comes up with candidate objects. Sure enough it takes some getting used to and some practice. Wander on down the forum list to the OO, UML etc forum if you want to ask the gang how they do it.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Depending on how big your project is (or how little really), don't get a case of paralysis by analysis. Afterall, you say your intent is to learn Java, not OO design.
Originally posted by Matt Fielder: Overall, I know what the program will do at completion, but how do I segregate that off into smaller sections. I assume I will have one main larger section and the others will contain methods that the main will be able to call?
If you know what the program will do, then think of how your users will interact, which will give you a series of events, such as "customer orders product." Nouns suggest objects. In the example event, these could be "order" and "product".
Once you have some classes chosen, you should think of the characteristics that each would share, like order number, products ordered, etc; these become instance variables. Then you should think about the things the class needs to do, such as total the order, apply appropriate taxes, etc; these become your methods.
Then you write the pseudocode for your methods. Then write the real code.
Wannabe SCJP 1.4<br /> <br />It wasn't raining when Noah built the ark.<br /> --Howard Ruff