Static connascence

Static symbiosis refers to source-level coupling (as opposed to execution-time coupling), which is a refinement of the afferent and efferent coupling defined by structured design. In other words, whether incoming or outward, the following type of static connascence is how much something is coupled to an architect:

  • Connascence of Name (CoN)

    Multiple components must agree on the name of an entity

    The most common form of code coupling is method names, and it’s ideal because modern ides can easily solve this problem

  • Connascence of Type(CoT)

    The components must agree on the type of entity

    This type symbiosis refers to the fact that variables and parameters are often limited to specific types in many statically typed languages; however, this is not purely a language

    In terms of features, some dynamically typed languages like Clojure and Clojure Spec offer alternative typing.

  • Connascence of Meaning(CoM) and Connascence of Convention(CoC)

    Multiple components must agree on the meaning of a particular value

    The most common example of this type of symbiosis in a code base is using hard-coded numbers instead of constants. For example, in some languages, it usually does

    Int TRUE = 1; Int FALSE = 0. Imagine if someone flipped the meaning of these values, there would be a problem.

  • Connascence of Position (CoP)

    Multiple entities must agree on the order of values

    This is a problem with parameter values for method and function calls, even in statically typed languages. For example, if a developer creates a

    Void updateSeat(String name, String seatLocation) and call it with updateSeat(“14D”, “Ford, N”), that is

    The semantics of making the input parameter types match are also incorrect.

  • Connascence of Algorithm (CoA)

    The components must agree on an algorithm

    A common case for this symbiosis is for a developer to write a secure hash algorithm that must run on both the server and the client and produce the same

    Results to authenticate the user. This represents a high form of coupling, and if either side’s algorithm changes any details, the handshake will fail.

Dynamic connascence

Another type of symbiosis is dynamic symbiosis, which analyzes calls at run time. Here are descriptions of different types of dynamic symbiosis:

  • Connascence of Execution (CoE)

    The order of execution between components is important

    Look at this code

       email = new Email();
   email.setRecipient("[email protected]");
   email.setSender("[email protected]");
   email.send();
   email.setSubject("whoops");
Copy the code

    This code does not work as expected because some properties of the message need to be set before it is sent.

  • Connascence of Timing (CoT)

    Execution timing between components is important

    A typical example of such symbiosis is a race condition created by two threads executing simultaneously, affecting the outcome of the joint operation.

  • Connascence of Values (CoV)

    Occurs when several values are related to each other and must change together

    Example: The developer defines a rectangle as four points, which represent the corners of the rectangle. In order to maintain the integrity of the data structure, developers cannot make arbitrary changes

    One point without considering the effect on the others.

    The more common and troublesome situation involves transactions, especially in distributed systems. When an architect designs a database with multiple databases, or single databases

    In a multi-schema system, when a value needs to be updated across all libraries, all values must be changed at once or not at all.

  • Connascence of Identity (CoI)

    Occurs when several values are related to each other and must change together

    A common example of this symbiosis is when two independent components must share and update a common data structure, such as distributed queues.

Architects have a difficult time determining dynamic symbiosis because we lack tools to analyze run-time calls to achieve the same effect as analyzing call diagrams.

Connascence Properties

Connascence is an analysis tool for architects and developers, and it has some attributes that help developers use it wisely. Here is a description of each of these attributes:

  • Intensity (Strength)

    Architects determine the strength of symbiosis by how easily developers can refactor a certain type of coupling. Different types of symbiosis are obviously preferable, as shown in the figure below. Architects and developers can use refactoring to improve the coupling of code towards better symbiosis.

    Architects should favor static symbiosis over dynamic symbiosis because developers can be identified through simple source code analysis, and modern ides make static symbiosis trivial. For example, symbiosis of meanings can be improved by creating a well-named constant instead of refactoring with a Magic value.

  • Collateral (the Locality)

    Joint is a measure of how close modules in a code base are to each other, and code that is close together (for example, in the same module) usually has more and higher joint than code that is separate (in different modules or code bases). In other words, farther apart means less coupled symbiosis, and closer together means no problem. For example, if two classes in the same component have symbiotic meaning, it is less harmful to the health of the project code than if two components have the same symbiotic form.

    Developers must consider intensity and connectedness together. Strong symbiosis found in the same module is more appropriate than the same symbiosis found scattered.

  • Degree (Degree)

    The degree of symbiosis is related to how much it affects — for example, does it affect a few or many classes? A lower degree of symbiosis is less damaging to the project code. For example, if your project has only a few modules, it’s ok to have high dynamic symbiosis. In reality, however, codebase tends to grow over time, and a small problem can ferment.

    Page-Jones(

    Object-Oriented Design

    , offers three suggestions for using syndication to improve system modularity:

    1. Minimize overall symbiosis by decomposing the system into many encapsulated elements

    2. Minimizes any residual symbiosis beyond the envelope boundary

    3. Maximizes symbiosis within encapsulation boundaries

    Jim Weirich has repopularized the concept of symbiosis and offers two great pieces of advice:

    Law of degree: Transform a strong symbiotic form into a weak symbiotic form.

    The law of association: As the distance between software elements increases, use weaker symbiotic forms.

Unify coupling and symbiosis metrics

From an architect’s perspective, the perspectives of Coupling and Connascence may overlap. Static symbiosis, as identified by Page-Jones, represents the degree of in-and-out coupling. Structured programming is only concerned with in-and-out, whereas symbiosis is concerned with how things are coupled together. To better understand and distinguish between these two views, please refer to the following figure:

In the figure above, the concept of coupling in structured programming is on the left, and symbiosis is on the right. Called data coupling (method calls) in structured programming, symbiosis provides suggestions for how it should behave. In addition, structured programming does not cover the territory of dynamic symbiosis.