| Petersen: You mean Mrs. Chelm is an unqualified liar? Dannreuther: Well, let's say she uses her imagination rather than her memory. Beat the Devil (1953) |
D Vautier
08-10
update 1-14
The idea behind modularity is to reduce physical program size to manageable chunks. It also isolates complexity and makes things easier to understand. From my perspective the only reason--plain and simple, for modularity is a reduction to simplicity. Leave it to future programmers to make things bigger and more complicated.
Originally programmers were a proud bunch of people and the idea was to write a bigger program than the next guy. It was a measure of pride like the old cowboy saying "A man is as good as his nerve", and a programmer is as good as the size of his program. I myself briefly descended into this level of thinking but soon realized that I was doing nothing more than creating gigantic monsters that were to walk the earth for future generations to deal with and too often to be consumed by, kind of like the national debt. Large and inscrutable programs were feared and ignored or given to junior programmers. The old joke was that this guy was sent into a program to fix a problem but he never came back so we had to send in a search party to get him out--much like the TRON story.
A program is a solution to something. The
solution may be put together as one big pie, or it may be several
smaller pieces of pie that work together to do the same thing that the big pie does. The idea is to get
the right mixture and solve the problem with not too many big pieces and not too many little pieces. Not too much cohesion
between the parts, (stickiness), but also not too little stickiness. Not too much data
hiding, not too little. Some pieces of the pie can be common to
other pies or unique to just this pie, probably the latter is better but not
always. Each piece of the pie needs
to do it's job well (robust) or it can drip and ooze all over the place.
Each piece of the pie can perform it's function and just it's function
and not the function of some other piece of the pie.
Each peace of pie should also have just enough ingredients in it. Too much sugar will spoil the whole pie. It's called overkill or the sledgehammer syndrome, the bane of most programs. All programs have too much sugar, extra programming to increase the size or confuse other people.
This briefly summarizes what you can find in books and books. The concepts of cohesion, symmetry, commonality, information hiding, etc, etc. Just as in a university setting, the good teachers are too busy doing things to teach doing things.
This above example also explains some of my philosophy towards programming. I call it the Betty Crocker effect. Just enough to do the job well but not too much seasoning, because it will spoil and then stink and sit around and never go away because nobody knows what it's doing there.
It has been my constant experience when having to modify programs that it takes far less time starting over from scratch and writing a brand new and clean program than to ever attempt to figure out the convoluted and twisted thinking that had gone into the existing program, even a fairly new one. Things are done incorrectly, extra things are added and then more things are added because of what was added before, totally loosing sight of what was needed in the first place. Complexity ruthlessly feeds on itself and the program's death spiral begins, actually a death spiral that never really dies, but just keeps on dying and dying and dying.
Today we have marvelous ways to share subroutines (pieces of pie). We have ways to share common (global) storage or reserve private (local) storage for just our piece of pie. The capabilities are numerous and the abilities of new programming techniques are mind boggling. Yet it doesn't help a bit because "All the perfumes of Arabia will not sweeten this little program". You see the tools for good program construction have been around for a long time, only the names change constantly to keep management happy and confused. Yet whatever the latest names are, programmers do not construct good code anyway. It is cute; it is cleaver; it is impressive; it is abstruse; but it is not good.
Behind every program there is a problem to be
solved. Jimmy Carter was wrong when he said "There are no more
easy answers." There are easy answers if you can reduce
complexity.
The primary idea behind programming is problem decomposition, which can be
overwhelming but is the only way to simplicity. Remember what Aquinas
said to a student. Take the acquisition of knowledge one little stream
at a time "per rivulos" and not the whole river. Take the problem decomposition the
same way. Attack each piece one at a time. I have been struck at
times not so much by the difficulty of a problem but rather by how other people
believed it is so much more difficult than it actually is.
So any slice of pie is a subroutine, a section of code that can be managed easier than the whole pie. The amount of sensitivity this little piece of pie has on the rest of the pie is called cohesion. High cohesion means that any changes in this code could have greater effect on other parts.
Data you work with are called fields or variables or whatever. shared variables are global. I like shared variables a lot more than local ones which can cause all kinds of problems.
There was a big movement in the 1970s to go go-to less, or use structured programming techniques. It simply means that you start your logic at the beginning of a subroutine and end at the bottom of the subroutine. This makes a lot of sense and almost any programming language has the ability to observe such a rule, even non-structured languages like FORTRAN.
Fields are fields. if you choose to call them something else because of a whim, then you just add layers of confusion. Why? GrossAmount or TotalPay sound like good data names. WS-gos-amount, or TotalPaySave or TotalPayForJim do not sound so good.
I have always had this strong objection to excessive nesting and have preached this dogma far and wide. This is the deplorable habit of building dependant conditions upon other dependant conditions (if...than..if...than...if..than). Three nests is the ultimate. If something gets to be more than that then the logic is too extreme and needs to be reworked or the problem decomposition is not sufficient. I have never developed any case where more than three nested conditionals are needed. If such a case presents itself, some more thought can be put into the problem and things can be shuffled around to simplify the nesting structure, or a different method can be used, e.g. matrix resolution, polish notation, case statements.
Many books have been published on the principles of good programming. Every one of these ideas have been beaten to death so many times over, but perhaps not always in light of many actual years of on-the-job experience dealing with all facets of development.
Good program modularity determines it's life. If you want to be a successful programmer and hope to leave some trace of your body of work for posterity than think long term. I have written programs that have lasted 30 years and still perform their primary function. This makes me grateful and humble. It makes my life more meaningful.