Wednesday, July 18, 2007

Basic design principles of programming

I'm going to try to compile a list of the most fundamental design principles of programming. The current list will most likely not be the last one, but I have to start somewhere. I want perhaps 4-5 principles (although it's not entirely up to me to decide -- it depends on the nature of the subject).

The criteria of a fundamental principles, which probably will become updated in time, is something like:

1. The principle should be broad, cover a lot of ground. So a design pattern doesn't count, it's too narrow. On the other hand, the principles these patterns are based on (using interfaces, loose coupling, etc) are candidates.

2. Not be trivial. The principle could (and maybe should) be easy to understand definition-wise, but not be easy to apply fully. (A counterpart in chess would be a positional principle like piece activity. Takes 15 seconds to understand the meaning of, but a lifetime to apply fully. Both a beginner and a grandmaster can study aspects thereof.)

3. I should have experience with it directly. There are some design principles that sounds great and useful that I've read about, but that I haven't thought in terms of and haven't seen in action directly. They may be great, I just don't know yet.

Also, it should, of course, really be a design principle, and not a design goal. You can't say for example "my design principle is to write efficient and correct code. Yihaa!", because that's a goal. It doesn't really guide or tell how to achieve that, just what to achieve. And I don't know what "yihaa" was supposed to contribute. Be serious, and cut that silly stuff out, okay? Okay.

What I've come up with, so far: (There are no revolutions here; these are well established principles, but they are usually not compiled into a list like this, or they may be mentioned together with less fundamental principles etc. The subject is somewhat chaotic, perhaps like the pre-modern area in chess was. So I'm basically extracting and compiling my personal collection, but I don't originate anything really new. Maybe someday I'll become an evil nerd-genius, but until then I'm just a lost farm boy.)

  1. Avoiding duplicity. This applies on many levels, anything from using a loop and a table instead of 30 assignments in a row, to merging two big units of some sort. Usually what is merged isn't literally duplicates, but it's similar enough so that you can extract one aspect of it and put it separately. Or something like that.

  2. High Cohesion. I think of this as 'classification'. It's basically putting related instructions (and data) in the same place, neither having non-related info in the same place nor having highly related info spread out. So it's clearly related to avoiding duplicity (but not the same), and this also applies on all levels: functions, classes, units, libraries, whatever. I once read an interview with one the programmers behind Age of Empires, and when asked for some programming advice, the only one he gave,as I recall, was having a well defined task (no more and no less) for each function. Well, the principle of high cohesion covers that, and more.

  3. Loose coupling. Often mentioned together with high cohesion. It means not having unnecessary connections between different parts of the program. A simple example: Three parts, A, B and C. A calls both B and C, and B calls C upon receiving a call from A. Now, instead of B calling C it's, or could be, possible to make B return whatever value it sends to C, to A and then let A send it to C. That would eliminated the (direct) connection between B and C, with A as an operator. Assuming that's a reasonable task for A (which it probably is since it already has contact with both anyway.)

  4. Encapsulation. As in information hiding. Maybe this is too object oriented to be included. But I feel three principles are too few, so I'll include it for now, and maybe remove it when I have 1-2 new principles. Or maybe I keep it, because OO is growing stronger by each day, and is, in my opinion, the best paradigm. (Let the flame war begin...)

  5. Modularization. Another principle with close ties to the other principles, yet different. It's breaking up the code into different units, each as independent of the others as possible. Loose coupling, mentioned above, is an important principle in achieving this.

That's it for now.

No comments:

Locations of visitors to this page