Connascence of Algorithm

I’m not sure where the term “connascence of algorithm” originated from. The first place I saw the phrase was in the 1996 edition of “What Every Programmer Should Know About Object-Oriented Design”. The book contains a great deal of practical advice, although its terminology and notations are well out of fashion 10 years later.

Two components share a connascence of algorithm when they both rely on a specific algorithm to work properly. If I change the algorithm in one component, the other component will need to adjust. In today’s terms, we’d say the components are tightly coupled in a bad way. The examples that spring to mind are all about relying on how a particular piece of software will order its results. (These examples might not fit the author’s precise definition, but are examples of coupling too closely with what is happening behind the curtain of encapsulation).

Relying on the implicit ordering of rows returned by a SQL SELECT statement is dangerous. The ordering will depend on the execution plan the database server generates to fulfill the query, and thus depend on the current indexes and possibly the server’s runtime environment. Appending an ORDER BY clause solves the problem by giving the database explicit instructions on how to order the records.

Here is a piece of code that believes the GetFiles method will always order file information in alphabetical order:

The code might work for me most of the time, even though the documentation for GetFiles makes no mention or guarantee on how it will order the FileInfo array. If I were to place a wager on the implementation of the GetFiles method, I’d wager it uses the Win32 FindFirstFile / FindNextFile APIs. The Win32 documentation for FindNextFile specifically mentions:

The order in which this function returns the file names is dependent on the file system type. With the NTFS file system and CDFS file systems, the names are returned in alphabetical order. With FAT file systems, the names are returned in the order the files were written to the disk, which may or may not be in alphabetical order.

Indeed, if I try GetFiles on an SD Card with a FAT filesystem, then the resulting FileInfo array contains files in the order they were written to the card. Because of this (and remember there is also a new transactional file system on the horizon), I’d never rely on the ordering of objects returned by GetFiles.

Finally, it’s interesting that Microsoft decided to introduce some randomization in reflection methods like GetFields:

The GetFields method does not return fields in a particular order, such as alphabetical or declaration order. Your code must not depend on the order in which fields are returned, because that order can vary.

I wonder what sort of dangerous code (and how much dangerous code) Microsoft was seeing to go to this amount of trouble.