The fourth Clean Coders episode is a monster episode covering a lot of ground— from a run through of Object Oriented, Functional & Structured Programming to a handful of key principles including Dependency Injection, the Law of Demeter, managing Side Effects, Command Query Separation and more. The episode took me a while to get through because I found myself hitting pause almost every minute to take more notes. For the sake of brevity I’m just going to focus on a couple of my biggest “a-ha” moments:

Structure & Organization

“In every application you write you should be able to draw a line that divides where the application lives and where the lower level modules live—the "app” partition and the “main” partition. No dependencies should flow from “app” to “main”, main is essentially a plug-in to the application.“

I really like this quote and the visual that went along with it because it provides a way to start thinking about the structure of your application and how to manage the dependencies. The concept is still a little abstract to me but I’ll try and come up with some UML examples for a later post.

Functional Programming

I have yet to write more than a few lines in a functional programming language, but every time I hear about it or see it I’m intrigued. It sounds so completely different from everything I’m writing now, but also somewhat natural. Soon enough I’m going to dive into the Clojure Koans and I’ll have the opportunity to write a Tic Tac Toe game in Clojure. Here’s the functional programming "teasers” from the video’s brief overview: - There are no assignment statements in functional programming and you can’t change the state of variables. - “Instead of setting a bunch of values as variables, you pass those values as arguments into functions. Instead of looping over a set of variables, you recurse through a set of function arguments.” - A true mathematical function. You will always get the same result back given the same input. - The value of a function depends only on its input arguments. “There are no side effects”.

Temporal Coupling

Temporal coupling is when you have have two functions that must be executed in a certain order and are coupled together. The easiest example would be the functions “open” and “close”. You need to open a file before you can close it and vice versa.

The way out of temporal coupling is by passing in a block to the first part of the couple and then hiding the second part of the couple inside the first. For example:

 def open(file, update_command)
   @fileManager.open(file)
   update_command(file)
   @fileManager.close(file)
 end

Command Query Separation

“Functions that change state should not return values, Functions that return values should not change state”

This sounds like such a simple rule but when followed can go a long way towards “clean” code that is easy to read and easy to maintain. If a function is simply a query that returns a value then your reader or the next person maintaining can rest easy knowing it has no side effects. (Of course in Ruby every method returns the last statement it evaluates so we may be tempted to use the return values even after changing state.) Martin Fowler has a quick little post about CQS and why an example of why you might want to break it.