What is Connascence? (Software Architecture Ep. 5)
--
Developing a better understanding of connascence will make you a better software developer nearly instantly. It’s THAT important.
Indeed, connascence is a fundamental concept needed to understand distributed systems, how to prioritize refactoring, componentization, domain-driven design, modularity, and coupling.
Transcripts (the following transcripts are auto-generated and may have typos or inaccuracies):
now I know what you’re thinking miles
why can’t we just talk about the coolest
hippest new architecture that I can try
to use on the job yet and the thing is
we’ve talked about coupling we’ve talked
about cohesion we’ve talked about
modularity and the conversation would
not be complete if we didn’t cover this
topic which is Con Nations say it with
me con nasons what a weird pronunciation
of that word and I double checked that
is how it’s pronounced cognasance all
right let’s get into it
all right so what is Con nasons let’s
break down the word so we’ve got con the
prefix which means with or together
right and then we’ve got nascent which
means coming into life or being born so
cognacence means things that are being
born together coming up together and in
the programming sense it’s basically
used to describe two components where a
change to one of them would require a
change to the other in order to
maintain the correctness of the system
that is the definition that Meyer page
Jones put forth
um when uh he investigated coupling that
Jim weirich took forward in in his
description of a more modern concept of
of cognizance
now the reason you should be excited
about Khan Nations is because it gives
us a really measurable objective way to
know what to refactor First how to
prioritize refactoring code and that is
extremely powerful in a world where
often it’s hard to know what should be
refactored
um it tells us a ton about the system in
terms of the coupling it tells us what
is most likely to break if we change
something so this is very very important
and useful information
we’re gonna break conditions into two
different types static and dynamic
static is going to be source code level
coupling that is things that can be
discovered by Static code analysis now
Dynamic cognizance is going to be at
execution time coupling okay so that’s
going to be not discoverable by Static
code analysis static cognizance includes
cognizance of the name so two components
must agree on the name of the type they
must agree on the type of the meaning so
that this would be
um
for example like magic numbers would be
an example of cognizance of meaning
where you have like a number that’s
defined in your code rather than pulling
it in as an environment variable which
is something we always look for when
we’re trying to refactor and make better
code that’s that’s an easy type of
coupling you can get out of your code
um
and then uh condescence of position so
like what order are the parameters
coming into the function does it do
component multiple components rely on
that and then you can have cognations of
algorithm so are they relying on the
same algorithm is there some implied
coupling through the use of a given
algorithm so in Dynamic cognacence we
have the execution so if the order of
execution matters things are said to be
dynamically cognacent for example in
Express middleware where the order of
that middleware can matter you may see
that as a JavaScript developer
um
then you get into cognations of timing
um which for example can result in a
race condition if your components are
relying on the timing of certain events
happening then there’s con nations of
values so when the values depend on each
other for example
um if you’re doing some kind of
distributed database and you’re relying
on the same value being in all of those
databases
um can you rely on that actually being
the case or if you’re doing some math
and you’re updating some value that’s
shared across something
you know this for example could happen
in JavaScript where you have some
variable that you’re changing the the
value of that and it’s getting
referenced in different places if you’re
relying on that then you’ve got some
Dynamic cognizance issue
um and then finally identity which
similarly would be if multiple
components are um relying on the same
entity I think it’s really important to
break Dynamic conditions into
synchronous versus asynchronous calls so
when we think of a synchronous call
between two components the first
component is waiting for the response
from the other before it can continue
this creates a dynamic cognizance that
means that those two systems
um component a and component B must have
roughly the same architectural
characteristics because if they don’t
then imagine that one is putting out a
bunch of calls and the other is not as
scalable and it can’t scale up to meet
that demand and you start getting
timeouts and your system starts breaking
down which is why typically we like to
refactor those examples of synchronous
cognizance into asynchronous cognizance
or the fire and forget Paradigm this is
where
the the component that’s making the call
can make that call it fires and it
forgets and then for example that may go
into some q and it um it gets taken up
by the other component as it’s able to
which means that they are not their
architectural characteristics are not
coupled in the same way so that’s a
that’s a really interesting kind of um
feature of dynamic cognizance so if you
go back to our discussion about
modularity you can see how cognasance is
something you may want to minimize
across component boundaries but that
within a component it actually makes for
a really nice module so
um we can Define the architectural
Quantum as a component that is highly
coupled
meaning it has high cohesion so you can
go and see my video on cohesion
um and so it has high cohesion and it
has
a high Dynamic cognizance within that
component
um synchronous Dynamic cognizance
um within that component
this means that it can be deployed
independently and with its own
architectural characteristics
we just don’t want that to be coupled to
other architectural quanta in such a way
that makes them actually one
architectural Quantum because that
coupling is so high so when you start to
get into distributed systems it’s
important to think of your assist your
components in terms of the coupling
within that bounded context so that you
know that when you deploy it and it may
have different architectural
characteristics it’ll still fulfill the
duties of the system requirements now if
you’re like me this whole idea of the
architectural Quantum makes you start to
think wait are all of the systems I’ve
built a single architectural Quantum
because they’re all coupled through a
single data source and the answer is
that if you’re using a single database
the answer is yes you’ve been working
with a single architectural Quantum your
entire career if you’re working with
distributed data in a microservices
environment for example
um then you’re going to have a system of
multiple architectural quanta which um
you know kind of opens up a whole world
for you
English (auto-generated)
AllArchitectureRelated
