Introduction I spend some time in the evenings working on various toy projects. It’s a good way to exercise a programmer brain in a way that a day job generally doesn’t. Anyway, a while back I bought an Analogue Duo, which is a high quality FPGA clone of the old 8/16-bit PC Engine console. I say 8/16 rather than just 16-bit, because while the GPU was 16-bit, the CPU was an 8-bit HuC6280 – a derivative of the legendary 6502 CPU, with a bunch of handy extra instructions and so on.

Introduction One of the first code smells we encounter when working with an object-oriented language where everything is an object, or everything subclasses a common base class, or there are no static methods, is how OOP typically handles equality of objects. For value types such as integers and floating point numbers, it’s not controversial that we should be able to compare them and decide if they’re equal or not. Integers can be compared by bits, and data structures can be compared by descending into the structure and comparing elements.

Introduction If you are gainfully employed as a programmer, you have probably been forced to accept object-oriented programming into your life. When working with a language like Swift or C++ which doesn’t have garbage collection, you will end up in the debugger, trying to locate a strong reference cycle which has resulted in a memory leak. Or, you’re reviewing a Pull Request and notice that there is a cyclic relationship between some classes.

Introduction An object maintains a reference/pointer to another object so it can call a method or access a property. References are called strong if the relationship between the objects is one of ownership, and weak or unowned if it the object containing the reference does not own the object being referred to. In languages like Swift, Objective-C, and C++, it’s required that we don’t create cycles of strong references, or we get memory leaks.

Introduction In order to guide programmers to effectively apply object-oriented design, the industry settled on what we call the SOLID principles. I believe that while the SOLID principles were marketed to encourage “good” use of OOP, they just as effectively discourage the use of OOP! The principles Single responsibility principle every module, class or function in a computer program should have responsibility over a single part of that program’s functionality, and it should encapsulate that part.

What is OOP? First, read Wikipedia. Characteristics of OOP Division of the problem into Objects which implement Classes The programmer is able to model the problem space in terms of objects that talk to each other via messages (method calls.) I believe this to be a poor approach to most data transformation problems. Noun-ification To encapsulate with OOP, you have to invent names (nouns) for the classes which encapsulate the functionality (verbs).

Introduction This page borrows heavily from Mike Acton. Transformation of data Writing code is a means to solving a problem, and primarily the problem is that some data (input) needs to be transformed into something else (output). Examples of inputs: Button taps Incoming HTTP responses Events coming from the OS Events coming from 3rd party SDKs Examples of outputs: The view hierarchy Audio HTTP requests Requests sent to 3rd party SDKs Frequently the output is not only dependent on any particular input, but on some stored state that is maintained as the app runs.