Programmer’s Blog

Two sides of program code

What I wrote at the end of the last post wouldn’t be true if OOP was more complicated than non-OOP, like it was some artificial construct. Just opposite, it is true because OOP is closer to natural human way of thinking than non-OOP. To realise and appreciate this we have to understad the difference between the principle of human way of thinking and machine / computer way of thinking.

We can tend to mistakenly think that computers ‘think’ similar way as humans. Isn’t it true that human brain can emulate processor way of thinking? And isn’t it true that a computer can emulate humans behaviour? They both are true. But we have to emphasise the word “emulate”. And to emulate means to imitate. In fact we are good in human’s way of thinking and computers are good in their own style of thinkig. The most obvious difference is that computer doesn’t have a clue what it is doing. It just processes bunch of instructions in a microfraciton of time and that is all. If we play tennis against a wall and it returns the ball back to us, we could tend to think there is someone alive playing against us. Luckily it is quite obvious that the wall is not alive. With computers it is not so obvious. What doesn’t mean they aren’t perfect toys.
Back to our topic. Computer ‘thinks’ it’s own way. And we write programs for it to make it behave as we need. Thus we create canvases of code for the machine to make it behave as we want. Have you ever seen pure machine code? You probably did. Just numbers. It is what machines like. Yum, yum, yum… We humans don’t. Ugh, ugh, ugh… For us this form is not understandable. And even if some of us pay the effort, learn it and claim they can understand it, we will argue that this form is not natural for us. We need something more human. So symbolic instructions languages (assemblers) were designed. Then first generation of higher level programming languages, then second and so on. Why? Because of the machine? No. On the machine side nothing changed. Only the diameters, volumes and speed. As concerns quality no changes. So why other and other generations of programming languages were created? Because there was need to bring programming closer to human. To make it more understandable. The more understandable you make the programming, the more effective programmer you are and the more ambitious projects you can start. With pure machine languages you could never do things as we have everywhere around today.

Program code has two sides. The machine side and the human side. Or better just opposite. The human is first. First we have an idea, second we can convert it to the form processable by computers. Each code is millon times processed from both the sides. From the computers’ one as it is run again and again (when we test if it realy does what we want) and from the human’s one, as it is observed again and again by the programmer to re-understand it, to work on it, to finish it, to extend it, to correct it etc. And the way how it is being perceived from each of the sides is different. So when we write a code, we do two things in one.
We as programmers by default know that the first goal we need to reach is to make our program running correctly. What means we concentrate at the computer’s side of the code. It is our primary goal. So we use the human side of the code as a tool to reach our goal on the machine’s side. In such a case we can underestimate the human’s side. And if not underestimate, then at least not appreciate enough. I don’t say we can not to appreciate it. I say just “not enough”. Human’s is never derived from machine’s. It only can happen that machine’s is derived from human’s.

OOP - Interface

In non-OOP languages the official top most unit of ‘interface’ is a procedure or a function. Such a unit is offering a data manipulation. Specific format data manipulation or a processing. In OOP the essential unit of interface is - interface. Something more complex. It is not a unit of manipulation, it is a unit of purpose. Purpose generally is something more than just manipulation. Purpose can be something more abstract and something more philosophical than just straightforward manipulation. They say that OOP comes with (higher level of) abstraction. It is so.

interface PersonalData {}

interface Office {
void ProcessPersonalData(PersonalData data);
}

You can never do something like this in non-OOP language. In OOP it is very correct. And yet no object nor specific data type on the scene.

Interface splits world into two parts. Part of a “user” and part of a “performer”.

Though both these sides have their responsibilities, interface re-presents mainly proposal of responsibility of the performer side. Generally the performer side is a unit with certain character. This character is imprinted into the interface and promises certain behaviour.

Important is, that the performer unit is generally independent on the interface itself. In practice the unit can be a static class (then the interface is inseparable from the performer) or a dynamic (representation of class) object, what is more interesting possibility, though both the variants are relevant

because in case of using interface dynamicaly, we can use object of different class type and connect it to the same interface (interchangeability)

We can even use object of descendant class extending the interface and connect it to our interface

We can switch objects connected to an interface dynamicaly in runtime (interchange)

We can have classes / objects implementing more than one interface, thus agregating more than one character and utilization (multiple inheritance)

All of this makes Interface term centerpiece of OOP approach and makes OOP more advanced and powerful than non-OOP.

Multiple Inheritance

If you think about the concept introduced, you soon find the main bottleneck. It is the conservative inheritance ordinance, that you can inherit (define interchangable class) just from one predecessor (single inheritance). Then you could build just tree hierarchies of classes what would be limiting.

In such a case for any existing class you would have just one linear definition path (path to base class alone) and you could never fully utilize the potential hidden in the concept. It is why real OOP languages come with multiple inheritance (either from classes or at least from interfaces) that allows us to freely (as needed) connect and share classes characteristics.

Temporary Interchange

Interchangability as was introduced in the last post could be interpreted like one-way transformation. But we know that it is not the case. When we have
B : A
A a
B b

and make an assignment
a = b

we have object of type B in the variable of type A. Now we can manipulate object B like it was object A. For example

a.CallMethodOfClassA()

Now object which was originaly of type B is treated as if it was of type A, what means reduction of it’s itnterface to A form (subset of B). But what is important, there as well is a way back:

b = a // ??? no, we can’t do this

but we can make this

b = a as B // in the case we know there is an object of type B in the variable ‘a’

In other words, putting object B into variable of type A doesn’t reduce it. It just changes the view at it. So the interchange can be just temporary. If one-way interchange gives us some nice possiblitites reversible commutation makes such approach perfect. What is such bidirectional exchange useful for? Generaly for two types of operations:

1. Higher level operations (operations offered by interface of A are ‘higher level’ from perspective of B)

Let’s note that in such operations big role is played by virtuality, thus possibility to re-define body of methods in a descendant (interchangable class).

2. Transfer

This concept allows us to design and use families of classes which can be processed on a platform of intersection of their characteristics by program modules which don’t need to be modified specificaly for each individual class type. This is extremely ellegant and effective approach that elevates us one level higher above possiblities offered by bare non-OOP approach.

OOP - Interchangeability

There are definitions and descriptions of Object Oriented Programming (OOP) and they work somehow. They talk about objects, classes, encapsulation, inheritance, polymorphism, abstraction and maybe something else, but none of them refers to one aspect of OOP which I think is essential. An aspect, that makes OOP really more useful and effective for building software systems than non-OOP. An aspect that was not introduced by OOP, but that was made by OOP a handy tool. The aspect mentioned is Interchangeability.

In our context we are talking about class (or object) interchangeability. It has something to do with compatibility. Let’s look at it more detaily.

A bit of math now

Definition 1: Class outer type is a set of declarations of it’s public members (data members and methods including their parameters) containing their types and names.

Class outer type is called class interface. They are synonyms. Careful, class type is not the same as class outer type. Class type is a synonym to class. See later.

And now interchangeability itself:

Definition 2: Class B is interchangeable with class A and we write B : A when (whole) outer type of class A is a subset of outer type of class B.

Definition 3: We call elements of a set of classes classes mutualy interchangeable with class X, when each class of the set is interchangeable with class X.

These definitions have consequences. First consequence is that class A is interchangeable with class A. Second consequence is that when B : A for B <> A, then never applies A : B. It looks theoretical. But it has a practical significance, when you have classes in a program where descendant doesn’t extend interface of it’s predecessor, so they have ‘like’ the same interface, the interchangeability is still one-way, not symetrical.

When we apply defintion 3 to 2, then we could say, that for B : A, A and B are mutualy interchangeable, what could sound like symetric relation, but it is not symetric due to there must be the supplement with A.

As well applies that when C : B and at the same time B : A, then definitely C : A. It follows from set definition of interchangeability.

Now more practical view.

Example 1: When

B : A
C : B
D : B

then A, B, C, D are mutualy interchangeable with A
B, C a D are mutualy interchangeable with B
but as well for example B and D are mutualy interchangeable with A

Example 2: When we have classes B : A and we define for them variables ‘a of type A’ and ‘b of type B’, thus

A a
B b

from definition 3 we can define an assignment

a = b // so ‘a’ can refer to an object of interchangeable class, because B is interchangeable with A

and at the same time it applies that we can’t make an assignment

b = a // because A is not interchangeable with B

This applies to program code. There is interchangeability that applies to objects in running system. In fact they both are different demostrations of (one) interchangeability principle.

It is instantiability (ability to create any number of instances of a class) together with interchageability what makes OOP much more powerful than non-OOP.

And what relation is between class type and the class outer type? Following

class X type : class X outer type

Class is a specific implementation of it’s (implicit) outer type. We can see that class outer type (class interface) plays quite an important role in the context of OOP. So when we talk about OOP, we can’t omit this term.

Single Responsibility Principle & C#

Back to the SRP topic. At the end of the post Single Responsibility Principle of SOLID I stated my hope that nested classes could be the way how to apply SRP in C#. Unfortunately this presumtion didn’t show quite right. There is problem with mutual members visibility. A nested class can reach private memebers of the owner class, but the owner can’t see private members of the nested class. And there is no simple way how to cope this.
When you want to split responsibilities to more classes, you need to have open communication channels between the classes so that they can naturaly cooperate. And the fact I mentioned is a blocker. Of course I could use events to communicate from owner class to it’s nested class, but it would be not welcome overhead. Funny is that if the visibility was just opposite, it would be little bit better (but still not ideal). The owner class would be the master controling it’s nested components. But nested classes were not designed with such an intention.
My conclusion is - C# is not a language friendly to apply SRP.
I find SRP itself right. But to be able to apply it reasonably you need appropriate infrastructure. And C# doesn’t have it.

16. Process vs. action

This post is a reminiscence of a post 15. Process vs. method. While in the article mentioned I was talking more program-oriented, today I want to talk more system-oriented. Software application or a program is a special case of a system. Like a method is a special case of an action.
I used to have a blog where I was talking about systems and subsystems. An important observation was that system and sub-system are both the same, just seen from a different perspective. When we talk about a system, we don’t consider it being subordinated to a superior system, but we consider it consisting of some subsystems. When we talk about a subsystem, we consider it being a component of a superior system. But in both cases the quality of the entity is the same.
With process and action it is similar. When we talk about a process we consider it a chain or a graph of actions. When we talk about an action, we consider it a dynamical phenomenon with some effect. But they both are the same qualities. The two names just describe them from different perspective.
In modern programming we tend to see all dynamical phenomenons as actions. We locate them in methods. But the truth is that the process aspect of actions in considerable amount of cases is predominant. When we tend not to pay enough attention to it and not to maintain it properly, we waste important perspective to our software system.
When you look at the code of programmers, in many cases you will find deficit of proper processes articulation. Articulation of processes is one of the last programming aspects developers appreciate. But is essential.
First step to do it well is to realize that many of our methods are not just actions, but processes too, to distinguish between the two aspects and give the process one adequate form which it deserves.

Single Responsibility Principle of SOLID

First member of SOLID principles (I would rather say practices or recommendations) group is Single Responsibility Principle (SRP). This principle definition can be found little bit vague. I have to admit that I couldn’t have identified myself with it for a long time. This principle like invokes a conviction that program code is equivalent of software system logic and in thinking about the code alone is the grail of good programming (what is even emphasized by the explanation that responsibility here means a reason for change). It would not be right presumption. Program code is just functional reflection or projection of the system logic.

If you state principles so that you want to prevent state of BBM (Big Ball of Mud - not maintainable code) you must have these principles complete and correct. And you must understand them correctly.
It is true that you can get into trouble with programming when facing complicated assignments. Then you have an opportunity to think about what really is relevant. Instead of SRP I always felt like there was a different principle of logical or domain aspects. Single logical aspect principle. And it claims that you should carefuly consider what logical aspects are present in your system. And dedicate them appropriate form in your code. It doesn’t have to be necessarily a class. It can be a group of variables or properties or group of methods. Each such an aspect is a latent theme which needs it’s own infrastructure and attention(!). Problem comes when you are not sensitive enough, overlook relevant (logical) aspects and start mixing them in the code together, or better said if you don’t make them visible and obvious enough.
Programming from certain point is not about a code. It is about logic. And logic is first. Code is second. Code must serve logic. Not the opposite. It is and always was my conviction.
Back to the SRP. I realized that SRP is and was exactly what I ment and described in my definition. And I probably discovered the reason of this my long term incomprehension. The reason is that I use a programming language that goes against SRP. Truly. To be able to apply SRP the way it is meant you need to have “friendly classes”. Without them you can barely be consistent in SRP without remarkable overhead or breaking encapsulation OOP principle.
Luckily the SRP definition doesn’t insist that it is necessarily a class what you need for single responsibility. It can be a “module”. And it is quite a general term.
But the truth is that now I miss the friendly classes in C# more than ever before. Well, may it have something to do with partial classes which were introduced into C# couple years ago. But when you use partial classes, you don’t have an institute how to name the aspects appropriately. Only comments. And filenames.

Added: Nested classes in combination with partial classes could be the answer. I will try.

15. Process vs. method

I have mentioned that from time to time we need to know what process a method is part of. Not only that. We need to know what individual processes we have in our system. So what it is such a process? Is it just a method with side-effects?
Yes and no. Process is a significant activity unit within our system as whole. As well it is a chain of activities. While individual method can either represent a whole process or be just a process subelement (and these are many more). Method represents a set of activities with somehow unitary effect. This effect is imprinted to the method name and description. Methods bring that simplification that they hide their processes behind their signatures. But to have a good awareness of what happens we need understand whole process and not to stop on method signatures.
And again not only that. Usually when we think about individual methods, we don’t consider wider context. When we talk about processes within a system, we do care about wider context, we do care about purpose. Thus we care about callers. Which can be not just other methods, but they can be some outer systems or human users.
Methods are useful elements, but good knowledge of the system is knowledge of system processes.
Nowadays software systems get big. We as programmers face quantity and complexity. And it brings difficulties asking for updated views.

14. What about processes?

At the end of the last post I asked this question. The answer is - nothing. We document data, methods, classes. And that’s all. We don’t consider something like processes is worth documenting, if we accept something like it even exists. The difficulty comes from the fact that processes are distributed, they are not defined in one specific spot like the other units mentioned.
Let me ask another question. What is the difference between a newly incoming programmer into a team and a programmer who has been there for some time? Which one is more knowledgable, more effective, more useful? Of course the second one. But why? Because (s)he knows all the methods, data structures and classes in the system? How long does it take to get to know bunch of classes and read what is in them? How long does it take to read? And how long does it take to comprehend? And what to comprehend? How long will it take?

To be fair. We have methods and they are documented quite well. Isn’t it just it? Description of processes?
We know, that methods and their signatures are part of class interfaces and thus they represent principle of encapsulation and principle of abstraction. And encapsulation and abstraction are principles of hiding and simplifying. These are great principles, that help to understand quickly and use instantly.
But as developers we need not only to understand quickly and use instantly, on top of it we need to understand thoroughly.
At the second picture in the last article, there is a process 2 with it’s entry method. I said it is data transforming process only and thus it can be substituted with one single method. The tree is there just to systematize the data transformation somehow.
The process 2 on the picture three is something different. It not only transforms input data, but takes in consideration context data. Maybe it modifies some context data. We say it has some side-effects.
But as concerns entering method, we don’t care much. We don’t need to know much. The process 2 entry method signature will not differ much in situations on picture two and three. Because method signature hides and dramaticaly simplifies what is behind the scenes.
As developers we appreciate this simplification a lot. But on the other hand we need to understand the process as whole. We need it because it is our craft. You might say, no problem, use “go to definition” function and discover. Yes this way I get to the method called body. If I am lucky. I can end up in an interface definition easily too. And even if I get into the method called body, I will face another bunch of abstractions and I will ask myself, are they just service methods or other deep processes? Who knows? That’s magic of abstraction.
And not only that. If I am in a method, every now and then I need to know what process(es) it is part of. Careful, what process(es), not what individual caller it is target of.
Since ancient times, programming has passed a long good journey and now we are satisfied with what we have. But we shouldn’t forget that at the beginnig, programming was mostly about processes. Today we hide them behind abstractions, what is good. But again, why it takes so long for newly coming programmers to ‘get into’ the system being developed for some time? Isn’t it because we like playing ‘hide and seek’ game?