Object Oriented Programming series introduction

Tue, May 10, 2016 ❝The introduction to the series on Object Oriented Programming.❞

Contents

Object oriented programming is a well known term. Well, … literally, the term “object oriented programming” is well known. What object oriented programming exactly is, or how you do this thing, is less clear.

There is confusion about the exact meaning of the term Object Oriented Programming, as well as the semantics and even into specific details. Take, for example, this email conversation with Dr. Alan Kay, who is believed to have coined the term originally. Even if you take, for example, the Java/C#-esque notion of Object Oriented Programming, then there is still the confusion about whether or not class hierarchy is a necessary component. Some consider Go an object oriented programming language, while others do not. Similarly we can look at Javascript suspiciously: it uses prototypes instead of class hierarchy. And what do we think of Javascript’s EcmaScript 2015 standard (formerly known as Javascript ES6)? Is this pure evil, a wolf in sheep’s clothing? Classes as syntactic sugar for prototypes. And finally, there are many variations in which object oriented code can be produced for a particular functionality. Some are “more object oriented than others”. Some variations are particularly suitable for code reuse. Others are excessively abstracted and as a consequence have become very complicated to use.

My personal take on this is that I think that Dr. Alan Kay’s view on object oriented programming makes most sense. It introduces the new dimension ‘concurrency’, which is orthogonal to existing concepts in programming. You reason about smaller independently functioning (i.e. executing) objects and their interaction between them. Similar to how we like to see our micro-services these days. However, in principle it does not matter what the philosophy is. As long as we can work with the programming language given whatever flavor of object orientation is supported.

Now comes our second problem. Even if we pick a particular notion of Object Oriented Programming, and we accept any given variation of objects such as the one based on class hierarchy. Then there is still confusion on how to structure objects and how to distribute code (both state and logic) over these objects.

There is the notion of the SOLID principles (or alternatively there is GRASP). These are a group of principles that when followed should lead to better code. Unfortunately, these principles are defined very weakly, so there is often discussion on their interpretation. This defeats the purpose and therefore can only be used as guidelines.

For example: Single responsibility principe.

The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. – part of description in Wikipedia article.

Even if we assume that “responsibility” is clear, then what do we consider a “single functionality”. Now, what is a “single part” of this functionality? In practice, there are a number of concerns that are intertwined. It is hard to distinguish one specific part. Or if you take the other approach, how large is a part allowed to be?

In this series, I am looking into the challenge of defining some clear rules. Rules that can be followed in order to design/write an object in a way that reasonably matches expectations one has for an object oriented design.

In an earlier post, I already looked into a third characteristic of objects that was never clearly recognized or explicitly defined. In future posts I will look into clarifying notions that we can use to make clear distinctions, rules, recognizable (clearly defined) characteristics. And how those are indicators for required decisions or how they can be used as guidance with decisions that already need to be made.