Articles in category: OOP
Introduction
Imagine you need to use a fixed numeric value in your code, let’s say 20000. It is what we call a literal constant, that is a value that will always remain the exact same in your code.
Now imagine you need to use that value more than once. Sooner or later you will read your code and you will not remember what 20000 was, it will happen for sure. But what if you assign the value to an immutable variable with a meaningful name? Let’s say something like this:
Google from zero to infinite
Sometimes I do a full immersion on topics of my interest, generally related to programming, topics on testing, good design, etc.
I apply a technique invented by me named: “Google from zero to infinite”.
Basically I use one or more keywords in Google, then I literally follow all the links of all the pages. It is a very long and laborious activity. However, most of the time I find very interesting documents, otherwise difficult to reach. This time I decided to use the final keyword of PHP.
A few days ago I stumbled on a strange tweet that was highlighting a controversy about scalar type hints.
After asking references about this, someone alluded to this very short video: “PHP Bits: Visual Debt” (it’s only 3 minutes, please watch it before continue reading). After that, the author of the video was dragged into the conversation, and it blew up into a big tweetstorm in the following few hours.
Maintaining state is the main cause of complexity and headaches in software development: without a careful consideration of state, our projects will inevitably become impossible to understand. In fact, various development techniques and programming styles are mainly there to handle state in a responsible way: for example, monads, as used in functional programming, are often employed for this very task. A good general way of managing state is trying to make it immutable, either through the use value types, that is, types which instances are passed around with deep copy semantics, or simple immutable objects, which have reference semantics but because they’re immutable their state is fixed.
There is an unwanted guest with us as we write code and build software projects: it’s the code that’s already written, and we must take into account its complexity as the code base increases in size. High complexity of the existing code can make the following activities particularly difficult:
- understanding the meaning of old code, written by others or ourselves;
- tracing the causes of bugs, i.e. errors, in code;
- making changes to a certain procedure;
- adding features to existing structures;
Even if we approach the development of new software with agile methodologies, we always have to deal with the existing code, and to do that we must at least be able to understand it without overexertion. So when I talk about complexity I am referring in particular to the difficulty with which a programmer can reason about the existing code: the preface of the well-known academic textbook Structure and Interpretation of Computer Programs contains the following sentence:
