{"id":1712,"date":"2012-10-21T17:22:18","date_gmt":"2012-10-22T00:22:18","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=1712"},"modified":"2023-02-13T22:15:22","modified_gmt":"2023-02-14T03:15:22","slug":"there-are-only-two-roles-of-code","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/there-are-only-two-roles-of-code\/","title":{"rendered":"The Purpose of Code"},"content":{"rendered":"

All code can be classified into two distinct roles; code that does work (algorithms) and code that coordinates work (coordinators).\\n\\nThe real complexity that gets introduced into a code bases is usually directly related to the creation of classes that group together both of these roles under one roof.\\n\\nI\u2019m guilty of it myself – even though I try my best to code at expert level<\/a>. I would say that 90% of the code I have written does not nicely divide my classes into algorithms and coordinators.\\n\\n<\/p>\n

<\/h2>\n

\\n\\n<\/p>\n

Defining things a bit more clearly<\/h2>\n

\\n\\nBefore I dive into why we should be dividing our code into clear algorithmic or coordinating classes, I want to take a moment to better define what I mean by algorithms and coordinators.\\n\\nMost of us are familiar with common algorithms in Computer Science<\/a> like a Bubble Sort<\/a> or a Binary Search<\/a>, but what we don\u2019t often realize is that all of our code that does something useful contains within it an algorithm.\\n\\nWhat I mean by this is that there is a clear distinct set of instructions or steps by which some problem is solved or some work is done.\u00a0 That set of steps does not require external dependencies, it works solely on data, just like a Bubble Sort does not care what it is sorting.\\n\\nTake a moment to wrap your head around this.\u00a0 I had to double check myself a couple of times to make sure this conclusion was right, because it is so profound.\\n\\nIt is profound because it means that all the code we write is essentially just as testable, as provable and potentially as dependency free as a common sorting algorithm if only we can find the way to express it so.<\/strong>\\n\\nWhat is left over in our program (if we extract out the algorithms) is just glue.\\n\\nThink of it like a computer.\u00a0 Computer electronics have two roles: doing work and binding together the stuff that does the work.\u00a0 If you take out the CPU, the memory and all the other components that actually do some sort of work, you\u2019ll be left with coordinators.\u00a0 Wires and busses that bind together the components in the system.\\n\\n<\/p>\n

Why dividing code into algorithms and coordinators is important.<\/h2>\n

\\n\\nSo now that we understand that code could potentially be divided into two broad categories, the next question of course is why?\u00a0 And can we even do it?\\n\\nLet\u2019s address why first.\\n\\nThe biggest benefit to pulling algorithmic code into separate classes from any coordinating code is that it allows the algorithmic code to be free of dependencies.\u00a0 (Practically all dependencies.)\\n\\nOnce you free this algorithmic code of dependencies you\u2019ll find 3 things immediately happen to that code:\\n\\n<\/p>\n

    \\n <\/p>\n
  1. It becomes easier to unit test<\/li>\n

    \\n <\/p>\n

  2. It becomes more reusable<\/li>\n

    \\n <\/p>\n

  3. Its complexity is reduced<\/li>\n

    \\n<\/ol>\n

    \\n\\nA long time ago before mocks were widely used and IoC containers were rarely used, TDD was hard.\u00a0 It was really hard!\\n\\nI remember when I was first standing on the street corners proclaiming that all code should be TDD with 100% code coverage.\u00a0 I was thought pretty crazy at the time, because there really weren\u2019t any mocking frameworks and no IoC containers, so if you wanted to write all your code using TDD approaches<\/a>, you\u2019d actually have to separate out your algorithms.\u00a0 You\u2019d have to write classes that had minimal dependencies if you wanted to be able to truly unit test them.\\n\\nThen things got easier by getting harder.\u00a0 Many developers started to realize that the reason why TDD was so hard was because in the real world we usually write code that has many dependencies.\u00a0 The problem with dependencies is that we need a way to create fake versions of them.\u00a0 The idea of mocking dependencies became so popular that entire architectures were based on the idea and IoC containers were brought forth.\\n\\n\"MP900175522\"<\/a>We, as a development community, essentially swept the crumbs of difficult unit testing under the rug.\u00a0 TDD and unit testing in general became ubiquitous with writing good code, but one of the most important values of TDD was left behind, the forced separation of algorithmic code from coordinating code.\\n\\nTDD got easier, but only because we found a way to solve the problems of dependencies interfering with our class isolation by making it less painful to mock out and fake the dependencies rather than getting rid of them.\\n\\n<\/p>\n

    <\/h2>\n

    \\n\\n<\/p>\n

    <\/h2>\n

    \\n\\n<\/p>\n

    There is a better way!<\/h2>\n

    \\n\\nWe can still fix this problem, but we have to make a concerted effort to do so.\u00a0 The current path of least resistance is to just use an IoC container and write unit tests full of mocks that break every time you do all but the most trivial refactoring on a piece of code.\\n\\nLet me show you a pretty simple example, but one that I think clearly illustrates how code can be refactored to remove dependencies and clearly separate out logic.\\n\\nTake a look at this simplified calculator class:\\n\\n<\/p>\n

    \\n\\n