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