Im updating because I havent in too long. Ive spent the past semester using Dvorak and am now trying to get back into the swing of using Qwerty. I hope it doesnt make writing this too hard.
So I was glancing over the first chapter of Event Based Programming, and I had this weired idea about coupling in software engineering. Coupling roughly means any dependency between parts of code. Strong dependency means that if one portion of the code is changed, the parts dependent on it must also. In this sense, a major goal of good software design would be
I should first say that Im not endorsing the book in any way. As far as Ive read, Its full of pseudo-mathematics and needless over-formalisms. In one part he talks about a couplings creating an algebraic space, and starts to apply a euclidean metric for god knows what reason, other than to make it seem more authoritative. This makes me afraid Im wasting my time, but maybe Im just being a jerk and should give it more of a read. Ive never read about formal treatments of the issue of coupling in software development before this.
The author mentions the existence of information theoretic approaches to the problem. Apparently, coupling is a form of entropy and therefore the information theory applies to the subject. His personal approach, on the other hand, is to classify the kinds of coupling, which isnt really satisfying in abstract. Despite this maybe he providing a common language in which to discuss them intelligently. Categorization is often the first step to understanding, but without a theory behind their organization, its pretty much just useless memorization.
My natural inclination is to describe coupling as a graph. Assume all parts of a program are functions in the sense of functional programming. We can draw a directed lines between all the functions in a program so that a points to b if b depends on a. Without any superstructure applied we will have a giant mess. Naturally there will be regions of close mutual connections, giving us a sense that these portions should be located psychologically close to each other in our minds. These portions are the superstructures of software engineering: classes, libraries, modules etc.
Given that there is no way to really remove interdependencies between functions, how can we arrange them to reduce ¨clutter¨. The question is similar to one were confronted with in this game. A strategy is to put the functions in a group sy some kind. These groups are connected to each other whenever they contain functions in each other that connect. Since these groups are abstractions, and all connections in them are abstracted away, we would like to set them up in a way that minimizes the connections between groups. Meanwhile, having too much complexity in a group is unacceptable. We could allow groups to be made of groups. What grouping reduces the clutter the most? With a simple definition of clutter we could write a program that determined the optimal arrangement.