Organizing program problem
Hi there
i was wandering how can i divide my program into parts so i can write it easily
when i watch youtubers writing codes it seems like it's too easy to write it
but when i get into it my head stuck.
thanks for helping me
i was wandering how can i divide my program into parts so i can write it easily
when i watch youtubers writing codes it seems like it's too easy to write it
but when i get into it my head stuck.
thanks for helping me
this takes practice more than anything.
For small problems, I tend to work 'forward' from the user interface.
what will the user DO? (click a button)
What happens when they DO that? (some thing happens to my data. Oh, I need a data structure … what goes in that?)
- design data structure
- Oh, that button click was really a method in my class!
This is the old "RAD" tool approach, where you slap a mock-up UI together and back into what is needed for it. Its awesome for small projects suitable for 1 person, like schoolwork. It assumes you have a bit of understanding about what the program should be doing, though... you can't just add button "take over the word" and then try to code that up, it still has to be driven toward your original requirements and needs and be broken into sensible chunks.
a great rule of thumb is that functions/methods that do user I/O should not do anything else. That is, do not compute a value and then display it; compute it in one method and display in another (disposable data does not count). That is, if you compute it only to display it, its ok together, but if you save the computation for use, they need to be apart. Graphics are similar -- keep graphical drawing code away from the core code entirely. Mixing them makes a mess.
Otherwise, the old ideas are still the best... a function should only do one thing. An object should only implement one concept.
For small problems, I tend to work 'forward' from the user interface.
what will the user DO? (click a button)
What happens when they DO that? (some thing happens to my data. Oh, I need a data structure … what goes in that?)
- design data structure
- Oh, that button click was really a method in my class!
This is the old "RAD" tool approach, where you slap a mock-up UI together and back into what is needed for it. Its awesome for small projects suitable for 1 person, like schoolwork. It assumes you have a bit of understanding about what the program should be doing, though... you can't just add button "take over the word" and then try to code that up, it still has to be driven toward your original requirements and needs and be broken into sensible chunks.
a great rule of thumb is that functions/methods that do user I/O should not do anything else. That is, do not compute a value and then display it; compute it in one method and display in another (disposable data does not count). That is, if you compute it only to display it, its ok together, but if you save the computation for use, they need to be apart. Graphics are similar -- keep graphical drawing code away from the core code entirely. Mixing them makes a mess.
Otherwise, the old ideas are still the best... a function should only do one thing. An object should only implement one concept.
Last edited on
There's "top-down" where you start with the highest level stuff and then work your way down. Then there's "bottom-up" where you start with the low level stuff and build your way up from there. Then there's the's the method of starting with the user interface that jonnin mentions. Let's call that "outside in" because you start with the interface to the outside world.
I find it's best to do all of these. It's sort of like peeling an onion: you know that you'll need XYZ at the top level , and you know that you'll need QRS at the bottom level. You also need ABC to handle inputs and LMN to generate outputs.
So you sketch those out a little. That's one layer of the onion.
Now you discover that XYZ needs 123 and QRS will need 456, etc. So you sketch those out.
Pretty soon you'll get to the inside of the onion where pieces connect directly together.
The important point is that you start with what you know you'll need from all aspects. Design it (i.e., figure out the class interfaces) but don't code yet. Now go down a layer. Repeat until you're convinced that you have a design that will work.
In a school environment, I recommend a slightly modified approach. This is based on the fact that the assignment usually have very specific requirements and is carefully worded (because the professor has used it before):
Read the assignment to get a feel for what you're supposed to do.
Now copy the assignment into a new document. Go through it again and convert it to a bullet list. Don't change the wording, just turn it into bullets that list requirements.
Put the bullet list into a source file and convert each bullet to a comment.
Fill in the code. Don't delete any bullets. Move them around as needed so that each bullet is the comment to one or more blocks of code.
This will help ensure that you actually do everything that's required.
I find it's best to do all of these. It's sort of like peeling an onion: you know that you'll need XYZ at the top level , and you know that you'll need QRS at the bottom level. You also need ABC to handle inputs and LMN to generate outputs.
So you sketch those out a little. That's one layer of the onion.
Now you discover that XYZ needs 123 and QRS will need 456, etc. So you sketch those out.
Pretty soon you'll get to the inside of the onion where pieces connect directly together.
The important point is that you start with what you know you'll need from all aspects. Design it (i.e., figure out the class interfaces) but don't code yet. Now go down a layer. Repeat until you're convinced that you have a design that will work.
In a school environment, I recommend a slightly modified approach. This is based on the fact that the assignment usually have very specific requirements and is carefully worded (because the professor has used it before):
Read the assignment to get a feel for what you're supposed to do.
Now copy the assignment into a new document. Go through it again and convert it to a bullet list. Don't change the wording, just turn it into bullets that list requirements.
Put the bullet list into a source file and convert each bullet to a comment.
Fill in the code. Don't delete any bullets. Move them around as needed so that each bullet is the comment to one or more blocks of code.
This will help ensure that you actually do everything that's required.
Topic archived. No new replies allowed.