At the end of the last blog we had taken a simple calculator class and demonstrated how we can start finding lines of separation within our code.  In this article I want to talk about what actually defines a line of separation.

Whilst our focus in the last article was on the pieces that we were carving off of the calculator, little regard was made to what we were leaving behind, and whether or not what we are leaving behind is worthy of still being called a calculator. So, to start with we need to pose a more fundamental philosophical/ ontic question: What is a calculator? 

Answering this in the context of separating out concerns, it would be tempting to answer this in terms of the objects that a calculator comprises - a calculator is a set of buttons, a display panel, etc.  But, if you consider a calculator through the more existential maxim "you are what you do" we would conclude that a calculator is defined by its function - to calculate.  This is a very Heideggerian way of viewing objects, and his work in ontology (Ontology comes from the Greek word ὄν, which means "existence", and is the etymological root of the word "entity") is very interesting to consider in the context of object-oriented design, so I would like to introduce some of his ideas and see how we may use them in our understanding of SoC.  I have to add a disclaimer however that I would not confess to being a savant on Heideggerian philosophy, and would advise those interested in his ideas, and most certainly anyone studying Heidegger, to look towards much better read authors as I am really just skirting over the huge intricacies of Heidegger's theories.

For Heidegger entities are represented in the human mind in their primordial form in terms of their "in-order-to".  that is to say, a calculator is firstly revealed to us as an "in-order-to" calculate, a seat as an "in-order-to" sit on, etc.  What Heidegger is saying is that we do not perceive entities primarily in terms of its properties, such as having a bunch of buttons and a display, which is how an entity reveals itself when we decide to inspect it , but as a means to achieve some task.  Heidegger distinguishes these two representations of entities as "ready-to-hand" or zuhand (seeing an object as an "in-order-to") and "present-at-hand" (an object as its properties).  Heidegger also sees us humans as a third and distinct category of entity, what he refers to as Dasein, and states that the other two entities exist only because of Dasein.  That is to say that the whole root of our calculator class ever being written in the first place is an abstract phenomena particular to a Dasein.  Heidegger also stresses that a Dasein is in a cultural context that allows him to understand the appropriate application of a calculator as "equipment".  If a calculator was dropped from the sky instead of a glass Coke bottle in the Gods Must be Crazy, the African tribe that discovered it would experience the entity with just as much bewilderment.  That is to say they would experience it as a present-at-hand entity rather than ready-to-hand equipment.

So, as I stated earlier, the lines of separation are not merely representations of the physical world around us, but reflections of the framework through which we experience life, a framework borne out of the evolutionary imperative to perceive boundaries in the entities in our environment, recognise their application, and use them transparently to aid us in our every-day tasks.  What is more, the phenomena of a calculator is a result of working in a particular mode of that framework in which we are focused on achieving a task (a towards-which in Heideggerian terms), and so we are very much treating the entity as ready-to-hand, which in turn would make our class representation of our entity very much behaviour oriented.  To use a famous Heideggerian example a hammer is an "in-order-to" hammer in nails, and so we would expect a hammer class to expose a hammer method (that is hammer in its verb sense).

Heidegger states though in his theory of Umwelt that if an equipment does not function as expected it becomes conspicuous, and shifts to the present-at-hand.  For example, if we go to open a door and the door doesn't open, the door handle becomes conspicuous and we try to figure out what is wrong with it.  In the OO World I think this shift maps quite well to exceptions - the entity may then become conspicuous, and expose its state, through an exception without having to expose its state via public getters and setters on the entity. 

I guess what I am getting at here is: can I really orient my design in such a way that the state of an object becomes as hidden as possible, if not entirely hidden, and that really our ready-to-hand entities' purpose is to expose behaviour.  I tried to think of this in terms of the hammer and nail example.  Traditionally we would hammer the nail in and check its state to see if it was suitably hammered in.  But if we focus on the "towards which" we might test using:

Given a hammer, a wall, a picture and a nail, when I hit the nail into the wall with the hammer, then I expect to be able to hang a picture on it.

This, in my opinion, is far more valid than the state analysis:

Given a hammer, a wall and a nail, when I hit the nail into the wall with a hammer, then I expect the nail to be in a particular state.

The reason is that the tested state could be wrong.  The true focus of our test (the towards-which) is to be able to hang a picture on the wall, and the validity of the state of the nail is borne out by whether or not you can hang the target picture on it.  This may seem less granular, but, I'll stick my neck out here and say that it is in effect testing exactly the same functionality as the second state test and in a much more accurate way.  I might also argue that the often claimed benefits of easier identification of a point of failure afforded by more "granular" tests is just as easy in such behaviour driven tests, as the exceptions should reveal the source and nature of failures.

Another interesting common problem comes when we consider how to represent the relationship between the wall and the nail.  This is where Heidegger can help again with his notion that we are only really interested in the way that entities are presented to us (the phenomena).  I have read a few articles toiling with the concept that entities are "disconnected in the real World" and therefore a separate entity is needed for each and a totally new entity to describe the relationship between the wall and the nail when they interact.  I see this as symptomatic of Dasein acting as an inspector of the present at hand, rather than interacting seamlessly with the ready to hand. 

So, to describe the relationship between the nail and the wall we should look to the phenomena.  When we see a nail by itself or a wall by itself they reveal themselves in a totally different way than a nail in a wall, because a "nail in a wall" in its totality presents us with a new single entity and an "in order to" hang a picture on, much in the same way that we see five pieces of wood nailed together in a particular configuration as a wooden box, and an "in order to" store things in, we don't see it as five pieces of wood and nails.

Putting nails in a wall, brings us somewhat back to the original problem of putting buttons on a calculator and the question of what is a calculator.  In a way the calculator is the totality of the buttons on the calculator.  Primarily Dasein initiates its interaction with the calculator by using the calculator button entities as an in order to enter its calculation.  So it seems that what is left behind really is not the calculator.   So what is left then?  This I will have to leave until next blog along with other remaining themes I was intending to deal with in this blog.