Connascence of Name (CoN) occurs when two components must agree on the same name of an entity. CoN is the lowest and weakest form of connascence. CoN is also unavoidable because we must give all components a name — objects, methods, variables, and so forth — in order to implement a solution. Here’s a basic example:

We can use the above implementation to output the playing of music by messaging Music.play. Should the module and/or method name change, we’d have to refactor all of our code to deal with the name change. We can take this a step further by using the Cogger gem to log the song being played:

A few points to note with the above implementation:

None of the above is cause for concern but we are using a handful of public and private names. Should the public API of this object change like Music::Player#call or the injection of the logger via Music::Player#initialize, then dependent objects would need updating.

Internally, we use message and song for logging song information and those names are much easier to change since none of the names would break dependent objects due to being highly localized.

Another potential cause for breakage is use of Kernel#format because if that method name changed, we’d have to update the Music::Player#call implementation accordingly. Chances are low since this Ruby core language feature is not likely to change anytime soon.

All of this is to say that names are everywhere and important to use in a manner that is self-describing and intuitive to understand.

Connascence of Type (CoT) occurs when two components must agree on the type of an entity. In static languages, the compiler will catch and ensure type safety but in a dynamic language, like Ruby, we can use duck typing. Consider the following:

Notice we are checking for specific types which makes the code more brittle. We can avoid CoT through duck typing to reduce complexity. For example, if we wanted to obtain the size of different objects, we could do this:

While the above is a decent example of duck typing, this isn’t foolproof as you’d need any object passed to the print_size method to respond to the #size message. There are tradeoffs but avoiding complicated type checking logic and not updating your type checks reduces CoT complexity.

CoT is most insidious when repeated in the name. The Ruby on Rails framework is the worst offender in this regard. Example:

The solution, as you can see, is to use modules because they are perfect for organizing components without constantly repeating yourself or losing meaning (more on this shortly). A slight variant — in an effort to emphasize this further — is when the CoT infects variables. Example:

People, falsely, believe you need to inject or pass a dependency as both class and instance when you shouldn’t be concerned about type at all, only the messages. The above solution is one remedy but the main question to ask yourself is what is the missing behavior you need to expose? Can you resolve this without caring about type? If so, great, because you can reduce down to CoN instead of being stuck with CoT. As a bonus, your tests will be easier to maintain too!

Connascence of Meaning (CoM) — sometimes referred to as Connascence of Convention (CoC) — occurs whenever two components must agree on the meaning of specific values. Magic numbers — as a code smell — is a good example of ambiguity in the meaning of a value. For example, the following uses integers 1 and 2 to represent booleans:

When defining TRUE and FALSE constants, we reduce CoM to CoN complexity so the code is more self describing.

Another example in which meaning is abused — which, unfortunately, happens a lot in the Ruby core objects — is Boolean Parameter Control Coupling. For instance, consider the following:

The fact that we have to use comments to explain the above is a clear indicator of CoM and could be easily solved by introducing a #ancestor_instance_methods method without the boolean confusion. To illustrate how far this can get out of hand, take the PStore default gem which has a confusing Object API:

Due to the above confusion, I created the Lode gem which enhances and wraps the PStore Object API in a more intuitive and self describing manner.

Connascence of Algorithm (CoA) occurs when two different objects/methods must agree on same algorithm. This can be solved by refactoring to a common object/method which reduces the degree of complexity down to CoN. When resolved, CoA ends up being similar to Don’t Repeat Yourself (DRY) refactorings.

CoA is easier to solve when in the same language/codebase but becomes complex when repeated across multiple languages/codebases. For example, OAuth is a complex authorization specification which requires having a client and server implementation.

For example, consider the following, contrived but simple, encryption example:

Notice SHA2 encryption is tightly coupled to the Encrypter which happens to write to a file. You might not want this specific behavior but might need the same encryption algorithm. Unfortunately, you’d need to use Digest::SHA2 in multiple places which increases CoA through duplication. Here’s a quick refactoring:

With the above, we’ve encapsulated our encryption algorithm to a single Encrypter object with safe defaults. As a bonus, the cipher can be swapped out with a different algorithm if required. This simplifies testing since we can swap out the cipher with a spy since we only care encryption is performed but not how it’s calculated since we can trust the Digest library to have sufficient testing.

Connascence of Position (CoP) occurs when multiple components must agree on the order of values and definitely gets uncomfortable with more than three values. CoP can be reduced to CoN via keyword arguments, using a Hash, using a Struct, or using a Class depending on degree of behavior. Examples of CoP are:

Structs provide an excellent way to demonstrate mixing order and unordered arguments as well as the impact of Method Parameters and Arguments in general. Consider the following:

Thankfully, with Structs, we can use keyword arguments to avoid CoP via the lesser cost of CoN:

As you can see, despite the order in which the keyword arguments were used, we get a proper first, middle, and last name regardless of position. In this case, we don’t have to refactor our code to support keyword arguments to avoid CoP. Otherwise, you’d have to.

Connascence of Execution (CoE) occurs when the order of execution is important for multiple components. Examples, which reduce CoE, are:

Here’s a few simple examples:

Here’s a concrete example. Consider the following implementation:

Assuming total is reset before each execution of operations, notice we get different results:

The Pipeable gem, for example, helps alleviate the CoE burden by encapsulating order of operations within a single pipe (or multiple pipes if you need to compose them).

Connascence of Timing (CoTime) occurs when the timing of execution is important for multiple components. Examples:

CoTime is similar to CoE especially in terms of parallel processing. Here are a few examples:

Connascence of Values (CoV) occurs when the values of two components are related. The good news is CoV is rarely widespread and tends to be more localized to the class or method that needs to work with multiple values at once. Here are a few examples:

Connascence of Identity (CoI) occurs when two components must reference the same entity.

Notice, in both examples above, we have CoI due to creating multiple objects with different different object IDs (first example) and mutating the same object with different values (second example). The first can be solved by constantizing and/or freezing while the second would benefit from being a Whole Value Object where identity is determined by the values and not object ID.

💡 If you need identity by value instead of by object ID, then the generic Wholeable or specific Versionaire gems might be of interest.

Strength is determined by the work required to compensate for changes applied to downstream objects. As the difficulty increases, so does the strength which increases the cost of the change to be applied. For example, CoN is the weakest of all forms because refactoring an object’s name, method, variable, and so forth is trivial using modern Integrated Development Environment (IDEs). CoM, on the other hand, is harder to decouple because no IDE can help extract meaning from ambiguous values so you have to manually refactor the code, on a case-by-case basis, to properly give definition to confusing code.

Degree is determined by the number of occurances you must fix in order to reduce the complexity of your code. For example, a method with three parameters is generally accepted as the maximumn number parameters to use before needing to abstract to a new object but a method with ten parameters vastly increases the complexity especially if you have to apply the change across a high number of downstream objects that would break otherwise.

Locality is how close or far the elements of your implementation are. A simple example is when using positional parameters for private methods. The knowledge of these positions is highly localalized and you have everything you need, within a single object, to make changes without effecting objects elsewhere in your architecture. On the other hand, expanding positional knowledge across multiple objects would increase complexity and make your code less flexible by forcing the reader to decipher what positional parameters are requried and in what order they should be used. Plus, positional parameters tend to be less flexible than keyword parameters so now you’ve made your Object API less flexible as well.

In general, you want to increase locality. A fair amount of locality within a module, class, and/or method is acceptable versus having this knowledge spread throughout your application across multiple components. Being able to see the coupling directly is better than being obscured through indirect, or multiple references, throughout your application.