>Ugh, a correct transfer function should conceptually just be the composition of our well encapsulated withdraw and a deposit functions, but defining it correctly has forced us to remove the locking from both withdraw and deposit, making both of them less safe to use.

I know OOP isn't cool any more, but the above is what OOP solves.

TFA's transfer() and withdraw() functions aren't compliant with double-entry accounting anyways, so you'd mark them private and only expose Transfer to callers. Let the class handle its own details.

OOP does not provide any help in solving the problem in question, and indeed encapsulation is a major obstacle to solving it. I think you haven't understood what problem is being discussed.

> I know OOP isn't cool any more, but the above is what OOP solves.

The article was a lengthy explanation of why the problem occurs in non-STM settings. In OO settings.

What do you propose as an OO solution?