I normally don’t write a lot about programming, but today, I felt like writing about programming and more specifically, about how to program — or how to solve a given problem. One of the most logical ways to solve a problem is the top down design methodology. The general idea is to understand the full problem and then begin to break the problem down into its components. At each step, determine if the simpler problems can be broken down further until all that remains are problems that do not need or cannot be decomposed any further. The big trick, of course, is knowing when the problem has been broken down enough to a point that one can begin to work on each problem. This part takes time and practice to know or get a feel for when enough decomposition has occurred and you are left with the simple to solve problems.
You’ll hear people say that top-down design and programming makes sense from a functional programming perspective and not with object-oriented coding, which is designed from the bottom-up. However, I think that once the problem has been broken down, the use of objects becomes much simpler. One can look at what is being done with each bit of code and determine where objects can be reused, modified or created and then write the code to integrate the objects into the program that is to be written.
The biggest problem with learning a methodology of how to program is that there is no better teacher than experience and school and universities are equipped to do it. I haven’t seen a good method for allowing students to work on a larger program that requires the use of critical thinking in breaking down the application into its various functions, classes and objects.