Connascence of Type

Connascence of type is the second lowest level of connascence in the static category, just above name. Connascence of type refers to when multiple components must agree on the type of a particular entity. This can be the explicit type in a statically typed language like Java, where most type issues will be guaranteed to be correct by the compiler. It can also be the implicit type that’s expected in a dynamically types language like Javascript, where type issues will either cause runtime exceptions or just weird behaviour to occur. 

Consider the following classes:

Our classes have connascence of type, both in the class declaration and in the method declaration. If we try to get our DinosaurHandler to handle a Chicken instead, she’s not going to be very happy- our dinosaur handler is coupled to the Dinosaur based on it’s type. If we try to feed the dinosaur anything except Food- like say the dinosaur handler herself- things aren’t going to be pretty. Both of our components are dependent on being called and created with the correct types of objects.

Like connascence of name, you can’t really get rid of connascence of type either- we’re always going to have either:

A) an explicit contract stating we will only work on this type of thing, and don’t even try giving us anything else, or

B) an implicit contract stating that ok sure, give us anything but don’t expect us to work properly if it’s not what we’re expecting.

This is the reason connascence of type is only one level above connascence of name- types are an incredibly important aspect of programming and are inherent to the way that we program.

Connascence of Name

Connascence of name is the lowest level of connascence in the static category. Connascence of name refers to when multiple components must agree on the name of a particular entity. 

Consider the following class:

Our Dinosaur class has connascence of name- both for the class declaration and the method declaration. If we change the class from Dinosaur  to Chicken , anything that references the class by name will break. If we change the method name from feed()  to devour()  or anything else, anything that is using that method will break. All components that use Dinosaur  are dependent on the names that it uses.

You can’t get rid of connascence of name- it’s fundamental to the way we refer to different components and entities in programming. Whenever we change the name of a component in it’s declaration, we always have to change all code that refers to the old name. This is why we refer to connascence of name as the lowest level of connascence- it’s littered all over our codebases, and there’s not anything we can do about it.

Connascence

Connascence is a term used to describe the relationship and taxonomy of dependency between two software components. Connascence was used Meilir Page-Jones in the 90’s in the book What Every Programmer Should Know About Object Oriented Design (later updated to use UML instead of Page-Jones’s own modelling language in Fundamentals of Object-oriented Design in UML (Object Technology Series)) but has not seen widespread popularity in the development community outside of specific areas such as this talk by Jim Weirich and a series of blog posts and a talk by Kevin Rutherford.

Connascence provides a taxonomy for dependency and coupling, allowing developers to reason about the quality of their code. There are two broad categories of connascence, and 9 different types or levels. Connascence also has three properties which can help us decide how bad the particular level of connascence is.

But we have to know what connascence is first- how to spot it, how to classify it, and how to decide whether it actually is a problem or not given the level and properties of the connascence we’ve identified. 

That’s where this series of posts come in. We’re going to go over the different levels of connascence and how to spot them in the wild, as well as touch on the different properties of connascence to decide when we need to act.

We’re going to cover the following areas:

Static Connascence 

  • Connascence of Name
  • Connascence of Type
  • Connascence of Meaning
  • Connascence of Position
  • Connascence of Algorithm

Dynamic Connascence 

  • Connascence of Execution
  • Connascence of Timing
  • Connascence of Value
  • Connascence of Identity

Properties of Connascence

  • Strength
  • Locality
  • Degree