Programmer’s Blog

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?

13. What is programming?

Let me introduce a small theory of programming. To make everything clear, I will start with elementar terms and present whole concept gradually.
What such a programming is? It is a way how to build functional systems. What such a functional system is? It is a complex of functionality and data. What is functionality and what is data? Data is binar zeroes and ones in defined quantity and locations and functionality is a way how they interact with each other in time.
How do we design such a functionality among data? Using instructions and commands grouped in procedures and functions (methods). What such a method is? Method is a prescribtion how to manipulate data. What data?
There are two basic kinds of the data manipulated. First kind is input data. They are just explicitly entered into the method. Methods which manipulate incoming data only are more elementar kind of methods. I call them service methods. Programming using service methods only would be quite limited.
Second basic kind of data manipulated is context data. What are context data? They are data located somewhere out of the method, but are reachable from within the method.
Existence of context data is what makes products of our programming functional systems. If methods worked with incoming data only, we would create only data transformers. Difference between a transformer and a system is that system can hold it’s inner state in time (generally systems consists of more cooperating components holding their states). Transformer only converts input data to output data using a chain of instructions, so called processing.
If we have context data, we can use either global data sharing (availability) or limited data sharing, sharing data within restricted context.
Here we come into object oriented programming. Though non-object programming was able to share data in restricted contexts too, yet OOP brought this approach into perfectioncy.
Now let us graphically present what was described.

On the first picture we can see a rectangle representing a method, arrows, representing processes (control flow) and a circle representing data.

On the second picture we can see more complex data transformer with more methods transforming data, as well we can see two possible process ways how/what methods are called.

On the third picture we added data shared among restricted contexts. We can see, that methods not only transform incoming data, but modify context data too. As well we can see methods using/reading context data. It is quite obvious, that contexts A, B and C represent objects in OOP.
When we look at the picture, we can detect a certain diagonal symetry there, some similarity between what happens in vertical direction and horizontal direction. Both these directions represent views on our system. In both dimensions we can see methods, processes and data (because everything is processes and data). But in vertical direction we can see more process oriented look at our system, while in horizontal direction we can perceive more context/state data oriented view.

Ok, let’s accept this as our abstraction of what an object oriented system as a product of OOP is. Definitely it is a system which is functional and functioning. But not only that. On top of it we need it maintainable. Thus we need to understand it(!). We need to understand it’s concept and it’s principle. In it’s whole as well as in it’s detail. What ways we make our systems to be understood?

1) we describe data - using names of their identifiers (both types and instances) and commenting. Definition is located in one place.
2) we describe methods - dtto
3) we describe classes (layers A, B, C) - dtto (’place’ here usually means one file)
4) what about processes (layers 1, 2)?

12. Basic Ideas

As promissed, I added some ideas and idea blocks to make the description of the system more complete. I realized, that there are two basic kinds of ideas. Functional ideas describe outer behavior of the system, mainly from the user’s point of view. Framework ideas describe inner concepts supporting development of the system and bring more developer’s view on the system. So I added these two fundamental idea groups to the tree.
The app updated is available on this link.

11. Ideas First

I gained more reasonable and more flexible inner structure and started thinking what to do next. I realised that the idea tree is little bit oppressed there in the top right corner. In general we see a natural hierarchy: idea -> file -> file content. In the meaning: I choose an idea to work with, then files containing the idea’s blocks are filtered, then I choose a file to work with and start editing it’s content. But the layout didn’t reflect such a hierarchy. So why not to adjust that.
Here is the app version with the layout updated this way. BTW recently I have been neglecting updating the ideas concerning the layout changes. It is similar to the situation when developers neglect updating comments while coding. The time to update the ideas will come soon.

10. Back to Ideas

After the few refactorings I updated some idea blocks. Not much changed. Only few idea blocks were added to TreeUc. The idea tree content stayed untouched. So there were couple restructuralizations of the code, but they didn’t influence the ideas. Because ideas are about what is happening. Not how it is happening. We could have seen some ‘how’ morphing, but the ‘what’ didn’t change. That is refactoring nature.

So what such an ideas construct is? Perhaps something I made up artificially because I like having things more complicated than they really are.