Transformations transform programming.
Continuing on from yesterday’s post on programming for transformations, the passage today finished off this chapter with an interesting take on data within code.
With object-oriented programming (OOP), many objects are within your program, encapsulating data and remaining hidden from view until a transfer of data is required.
In a way that seems to go against the philosophy of decoupling, the book gives a tip to the effect of “Don’t Hoard State; Pass It Around”.
Rather than having separate objects with separate data flows, spread it out instead:
“Instead of little pools of data spread all over the system, think of data as a mighty river, a flow. Data becomes a peer to functionality: a pipeline is a sequence of code → data → code → data…. The data is no longer tied to a particular group of functions, as it is in a class definition. Instead it is free to represent the unfolding progress of our application as it transforms its inputs into its outputs. This means that we can greatly reduce coupling: a function can be used (and reused) anywhere its parameters match the output of some other function.”
Recycling is good for the environment, why not do it with functions too?
Thank you for reading, see you tomorrow!
#PathToSWE
