Recently, when giving a presentation on Integration Design Best Practices, the idea of Separation of Concerns was brought up. We like to start with this concept because whenever we talk about best practices here at iNTERFACEWARE, we emphatically stress the importance of Separation of Concerns.
So, what is it? It’s when you make sure that any/every component of your interface that does “something” only does that one thing (the Separation of Concerns). Doing this greatly reduces the complexity of your interfaces and makes it easier for you to maintain the code.
Today I’ll look at how you can apply the principles of Separation of Concerns to your own integration projects.
Separation of Concerns in the Real World
Some of you may still be scratching your head at the concept, so here are some real-world examples of Separation of Concerns:
- An assembly line
- Each stage of the line is responsible for completing a single task
- Your morning routine
- You don’t get dressed, shower and eat at the same time and place (or do you?)
Basically, in most phases of life it’s important to separate tasks that aren’t directly related in order to avoid confusion and mistakes. The same is true for your interfaces.
How You Can Get Started:
When I think about separation of concerns, I tend to think about writing.
Often, to get over writer’s block (or that glaring blank white page), I’ll do a brain dump of ideas. Sometimes it’s just better to write and not edit along the way; get the words out and onto the page, then reread and edit. This is the point where long sentences are broken up and new paragraphs are introduced. The writing gets clearer.
So, you may be wondering, what does this have to do with interfacing? I hear that this process is akin to writing code. Naturally separation of concerns is the furthest thing on your minds as you’ll get to work writing a stream of consciousness. The key to the “brain dump” process is remembering to go back and clean things up. Make your “edits” and separate the concepts that can be contained on their own. It may be a small pain in the beginning, but eventually you’ll realize doing so will make your life a lot easier.
Instead of doing repetitive (and often boring) tasks you’ll have more time to do whatever it is that excites you. Separating the independent concepts from each other reduces coupling but increases cohesion. Huh, coupling, cohesion?
Coupling? It’s the degree of dependency between two modules.
Cohesion? It’s the measure of how strongly related the set of functions are to each other and making sure that they’re used together.
Why is it important to remember Separation of Concerns in your daily jobs? Well…
It affects how much code you have to change:
If your code is separated out in distinct functions and modules, you’ll only have to change code directly associated with whatever new feature you’re building. That means less code changes which is always a good thing.
It affects the ease of making changes:
If the behaviours you are interested in are separated from the rest of the application it’s more likely you’ll be able to swap in a new implementation of a function or module without fully understanding the rest of the script. It also makes it easier to spot which code you need to change.
It affects the likeliness of accidentally breaking existing features being used by current customers:
Splitting up the concerns helps you avoid breakage in unrelated features by preventing you from having to change code that they could call. If your features are all mixed up you might change the behavior of one by accident while trying to change another one. Say hello to a bunch of unhappy customers and your Support Team.
It affects how much you can reuse your existing model/architecture:
If your architecture is agnostic to technical or business logic detail then changes to implementation are less likely to require new architectural features.
So going back to best practices, I thought I’d reiterate the process that one of our developers, Jonathan Marshall, presented at the 2015 Iguana User Conference:
Best Practices: The Process
PLAN: Develop a strategy that will achieve your ultimate goal. Your ultimate goal — creating a maintainable code base.
Consider other best practices you know, but be sure to avoid analysis paralysis!
WORK: Hack out a solution, even if imperfect, but ensure you return and refine it.
“If you are not embarrassed by the first version of your product, you’ve launched too late” Reid Hoffman, founder of LinkedIn.
REVIEW & REFACTOR: Look for patterns and duplications. Move them into modules or configuration files.
MAINTAINABILITY: You’ve achieved your goal, and in doing so, have increased your productivity and work quality substantially.
You probably already know some of these things, but I figured a reminder doesn’t hurt.
Want a deeper dive on Best Practices and more? Attend the Iguana User Conference, September 21-22, 2016.
