Skip to main content

Coupling / Cohesion

There was a question asked on the 97 Things Every Software Architect Should Know Linkedin group about coupling and cohesion that got me thinking.

My first response was to point to the video by +J. B. RainsbergerUnderstanding Coupling and Cohesion. But this video didn't satisfactorily coupling and cohesion question.

As a follow up, heres what I wrote on the group, to solidify my understanding of coupling and cohesion, since it's not a topic that comes up directly during development.

Let me describe how I view coupling / cohesion, and see how it lines up with your understanding.  
For me, coupling is the ease of which you can pull modules apart. You notice this when moving classes and functions around during refactoring. Until you make a change, you don't really feel the pain of tight coupling. To minimize this pain, you remove needless dependencies, depend on abstractions instead of concrete classes, pay attention to the law of demeter, etc (i.e. use good design, e.g. SOLID principles). You also notice tight coupling during unit testing. The more objects you have to mock out during a test is an indication that there are too many dependencies.  
Cohesion is a measure of how well modules fit together. For me, this is a little harder to get a read on, but in general I think adhering to the single responsibility principle is a good way of increasing cohesion. I'm not as concerned with cohesion as I am with coupling. However, I like to review all the methods of a class during refactoring to ensure they all serve a single purpose, and all classes in a namespace fit together as well.  
In my experience, low coupling and high cohesion are by products of good design. You don't set out with coupling / cohesion as design goals.  

Patterns in Practice: Cohesion and Coupling by Jeremy Miller on MSDN seems like a good treatment of the topic.

How do you view coupling / cohesion, and how does it influence your coding?


Popular posts from this blog

Generating Java Mixed Mode Flame Graphs

Overview I've seen Brendan Gregg's talk on generating mixed-mode flame graphs and I wanted to reproduce those flamegraphs for myself. Setting up the tools is a little bit of work, so I wanted to capture those steps. Check out the Java in Flames post on the Netflix blog for more information.

I've created github repo (  that contains the scripts used to get this going, including a Vagrantfile, and JMeter Test Plan.

Here's a flame graph I generated while applying load (via JMeter) to the basic arithmetic Tomcat sample application. All the green stacks are Java code, red stacks are kernel code, and yellow stacks are C++ code. The big green pile on the right is all the Tomcat Java code that's being run.

Tools Here's the technologies I used (I'm writing this on a Mac).
VirtualBox 5.1.12Vagrant 1.9.1bento/ubuntu-16.04 (kernel 4.4.0-38)Tomcat 7.0.68JMeter 3.1OpenJDK 8 1.8.111linux-tools-4.4.0-38linux-tools-commonBrendan Gregg's Fla…

Basic Web Performance Testing With JMeter and Gatling

Introduction In this post I'll give a quick way to get some basic web performance metrics using both JMeter and Gatling.

JMeter is a well known, open source, Java based tool for performance testing. It has a lot of features, and can be a little confusing at first. Scripts (aka Test Plans), are XML documents, edited using the JMeter GUI.  There are lots of options, supports a wide variety of protocols, and produces some OK looking graphs and reports.

Gatling is a lesser known tool, but I really like it. It's a Scala based tool, with scripts written in a nice DSL. While the scripts require some basic Scala, they are fairly easy to understand and modify. The output is a nice looking, interactive, HTML page.
Metrics Below are the basic metrics gathered by both JMeter and Gatling. If you are just starting performance testing, these might be a good starting point.

Response Time – Difference between time when request was sent and time when response has been fully received

Latency –…

Multi Threaded NUnit Tests

Recently I needed to reproduce an Entity Framework deadlock issue. The test needed to run in NUnit, and involved firing off two separate threads. The trouble is that in NUnit, exceptions in threads terminate the parent thread without failing the test.

For example, here's a test that starts two threads: the first thread simply logs to the console, while the other thread turfs an exception. What I expected was that this test should fail. However, the test actually passes.

readonly ThreadStart[] delegates = { () => { Console.WriteLine("Nothing to see here"); }, () => { throw new InvalidOperationException("Blow up"); } }; [Test] public void SimpleMultiThreading() { var threads = delegates.Select(d => new Thread(d)).ToList(); foreach (var t in threads) { t.Start(); } foreach (var t in threads) { t.Join(); } }
Peter Provost posted an article that describes how to make this test fail. It works…