Exploring the philosophy of objects
forkit
forkit at gmail.com
Sat Jun 25 23:11:18 UTC 2022
On Saturday, 25 June 2022 at 20:06:45 UTC, Ola Fosheim Grøstad
wrote:
>
> ....
> There is a lot truth to that. The reason being, of course, that
> the users of the software are more important than the
> programmers… so you need to extract what users' needs are,
> communicate about it and turn it into something that is
> implementable (by whatever means). And you invariably end up
> with focusing on objects, processes and communication.
>
Actually the concept of programming is really, really simple:
(1) You have objects (big and quantum size, they're all objects!).
(2) You have interactions between objects (no object is an island)
(3) You have processes whereby those interactions come about.
(4) You have emergent behaviour (side effects if you will) - the
program itself.
The bigger the object, the more difficult it becomes to model it
using quantum physics. The easier it becomes to understand the
interactions, cause they're more visible (encapsulted if you
will). The easier it becomes to identify the processes by which
those interactions come about, cause they're more visible. And
the easier it becomes to model what the emergent behaviour looks
like, because it too is more visible.
On the otherhand, the smaller the object, the harder it becomes
to model it using the same object decomposition used with larger
objects, the harder it becomes to understand the interactions,
the harder it becomes to identify the processes by which those
interactions come about, and the harder it becomes to model what
the emergent behaviour looks like.
The smaller the object gets, the less chance you have of
understanding item (1), let alone items (2), (3), and (4).
In the end, you end up with something like the linux kernel!
It's just works. But nobody really knows why.
More information about the Digitalmars-d
mailing list