3 ms·
DoesTheThing is fine for a function. E.g. if TheThing is cosine(x) then that works. But most computer systems are not functions. They have some internal state.
by discreteevent 4y ago
DoesTheThing is fine for a function. E.g. if TheThing is cosine(x) then that works. But most computer systems are not functions. They have some internal state. So it becomes DoesAThing. AThing may different every time depending on the internal state. This is neither an object nor a process in the articles terms. It's more like an object in OOP terms.
- raydiatian 4y agoPerhaps what I mean to convey here is that OOP (to my dumb newbie brain from N years ago) sounded like classes/objects were the hammer, everything else was a nail. The truth as I see it now is, I think, more that the patterns/problem statement are the hammer, and classes/objects are the nail. I spent a long time early on trying to map real-world objects to coded abstractions. In practice, at least as far as enterprise goes, it’s nothing of the sort: the objects we tend to create are DoThingClient, BrokerThingRepository, CreateThingFactory, HandleThingSevice, and then whatever STL & Framework you might build/ship with. Everything else might be a “class” out of restriction by the language, but they’re really just data records or procedures. I’m sure things might be different in game development, embedded, OS, etc. But object oriented programming feels like it doesn’t quite convey what we actually do as we trying to get a senior-level understanding of SE. Anyway, this is my hottake and it’s totally warped around my perspective
- discreteevent 4y ago> the patterns/problem statement are the hammer, and classes/objects are the nail. Very good analogy. Matches my experience also.