Programming made a major leap from the pocket-calculator style "data-in" into "a program" which produces "data-out" when computers became able to refer to themselves, so to speak, via the concept of "reference".

Initially conceived as having access to a memory address (and still the case in programming languages such as C/C++), this is now more commonly referred to as a handle, in the case of data, and as a collection of all sort of funny little things like delegates, method-pointers and so on in the case of code.

A data reference allows us to work with the address of data about which we either know nothing (weakly typed) or everything (strongly typed). The weaker the typing, the greater the flexibility and the bigger the risk of losing track of what we're doing (a polite description of a bug).

A code reference allows us to work with the address of some executable code about which we either know nothing (weakly typed) or everything (strongly typed). We can even jump into it and see what happens (see previous comment on flexibility).

Object Oriented Programming has allowed us to start thinking of both in terms of knowing certain, different, things about our reference targets at different times, according to our need. This is a tremendously powerful programming advance and so is, not surprisingly, one of the principles of software engineering all by itself (#5).

The basic principles, however, are still important.

Although template/class/code libraries have provided ready-made mechanisms for storing and sorting lists of data, there are times when building your own linked data structures results in clearer code. Genealogy provides a good example. Although you would want a master list of your population keyed by their name, say, you would want each person to directly link with their relatives rather than force you to keep looking up cousin "Jane" and her brother "Harold" and so on.

(Someone may argue against me with this, and unless performance is an issue (which it frequently is) there is an argument for not trying to maintain multiply linked lists (because it's an error-prone headache)).

Although high level programming constructs have largely removed the need for function pointers the "goto" syndrome persists in a way which makes me think it must be tied to an ancestral memory. C#, for example, wraps a function in a class in a weird "transparent" way and even C++ has pointers to class methods (an OO term). Then, of course, there are "exceptions", a goto by another name (IMVHO) with a transparent function pointer passed in by way of an exception handler.

Whether we like it or not function pointers seem to be here to stay in some guise or another so, again, it's a weapon worth keeping in a programmer's arsenal.

Richard

The Principles of Software Engineering: start previous next