Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Modular Programming - please explain
#11
Quote:I managed to solve the problem myself.
I figured out that ther was something wrong with my arrays, After 2 hours changing REDIM's in to DIM's and DIM's in to REDIM's and making DIM's and REDIM's $STATIC or $DYNAMIC, my program did what is was programmed for to do.
Thank you all anyway for your help.

CRONO: You solved your problem and that's great. But, you started this thread asking about modular programming. Have the answers that were given answered your doubts on this subject?

Let me give you a little example about the advantages of modularity, although I'll use a stereo system instead of a program to highlight the idea. About 40 or so years ago, a hi-fi or stereo system was totally integrated. If it didn't work, you could not identify what part was failing unless you were a technician. Then came modular stereo systems, where the components were completly separte units connected by wires, like mixer, pre-amplifier, equalizer, amplifier, speakers, tape deck, record player, CD player, etc. If something was not working right, or it wasn't up to your expectations, you could repair or replace only that component to get the results you wanted. You don't have to mess with the entire system.

The same idea applies to programs written in a modular fashion. The specific tasks of each module are isolated and not interwoven with the rest of the program. For example, if the user input module is not working right or requires a change, then you can go in and change just that module without messing with the whole program. Also, you don't have to debug the entire program again, just those functions that affect the user input module. You also don't run the risk of screwing up something that was already working. The same thinking applies to output modules, report modules, calculation modules, etc.
I'm sure you've seen the famous IPO flowchart for a program which has 3 boxes or processes. Input, Process, Output. Well, every program, no matter how simple, should at least consist of 3 modules: Input, Process, and Output. If you have problems with the Process, you don't need to fuss with the other 2 processes. Get it?

Get into the habit of programming in a modular fashion. It pays off.
*****
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)