tgl@g.gp.cs.cmu.edu (Tom Lane) (03/22/91)
I've run into a system structuring issue that seems like it ought to be a standard problem with standard solutions in O-O programming. However, I've never heard anybody address it in my (limited) exposure to the field. Pointers would be appreciated. The application is JPEG image compression. This involves a large number of logically independent steps, many of which have several possible implementations. In some cases these alternatives are mandated by the JPEG standard; for example, the last phase of compression is either Huffman or arithmetic-coding compression. In other cases the motivation for multiple methods is simply optimization. For example, one step involves subsampling (averaging together small groups of pixels) using varying sampling ratios. It will probably be worthwhile to have "hard-wired" code for the most common ratios (2:1, and especially the trivial case 1:1) as well as a general method to handle any ratio; the inner loops of the hard-wired methods will be much more efficient than the general method can be. I would like to set things up so that the different implementations for any given step are different instantiations of the same object class (or different subclasses of the same virtual superclass, if you prefer). For instance, one could simply invoke last_phase_compression() without worrying about whether this method points to Huffman or arithmetic encoding. More importantly, this lets me encapsulate information about how many different special-case methods there are for any step and what the conditions for choosing each one may be. As a bonus, the conditions for selecting a method can be quite complex since it's only done once at startup (whereas the method may be called many times during a run). Now here's my problem: how do I set up the initial method-selection phase so as to preserve modularity? I don't want to have a central chunk of code that knows the real name of every method in the system and the conditions for its use; that would be big, ugly, buggy, and a total failure of modularity. The only other thing I can think of is to have a list of applicability-test functions, each of which decides whether its associated method is applicable. This has its own faults, the main one being that the order in which the functions are tried could create unexpected interactions. Like I said, this seems like it must be a standard problem. Any advice? (In case it matters, this will all be coded in vanilla C for portability reasons. So the "objects" will just be C structs containing function pointers. I'm not really concerned with hiding representational details about the image data, only in having a cheap and transparent way of selecting one of N similar routines at runtime. But I'm not averse to hearing about solutions that depend on features of real O-O languages; maybe I can adapt their ideas.) -- tom lane Internet: tgl@cs.cmu.edu BITNET: tgl%cs.cmu.edu@cmuccvma