clipka <nomail@nomail> wrote:
> Ah, yes - here we enter the realm of blah that scared *me* away from OOP when I
> first came into contact with it:

> "WTF - what does *this* crap have to do with *programming*?!"

  It has to do with program design. The larger the program is, the more
important it is for it to have been designed properly. A large program
without proper design easily becomes unmaintainable and incomprehensible.

  One of the most basic methods for keeping a large program manageable is
to subdivide it into smaller parts, hierarchically. When you write something
inside the large program, you shouldn't have to be keeping in mind the
*entire* program in order to be able to write that small part. You should
be able to keep in mind only the *relevant* parts of the rest of the program
necessary to make that small part work.

  It's the same in almost everything that is big and complex, not just
programming. The CEO of a large company doesn't have to worry about what
every and each single one of the ten thousand employees is doing. That would
be impossible. He just can't be managing ten thousand things at once. It
becomes even more complicated when they have sub-contractors and other such
companies to deal with. Instead, there's a *hierarchy* of management in the
company: The CEO controls a dozen or so bosses, who control a dozen of
managers, who control individual employees, or however a big company is
subdivided.

  The functionality of a large program can be largely divided into a
hierarchy by distributing the code logically into functions. However,
functions are not enough when you need to handle enormous amounts of
different types of *data*. Data management has to also be divided into
logical parts, often hierarchically.

  The solution presented (although not originally invented) by object
orientedness to this problem is the concept of modules: Modules can have
both functionality and data, and they enclose both in a way that makes
managing the data easier in a large project. Modules can also form a
hierarchy (so modules can define sub-modules inside them, or own instances
of other modules, etc).

  Most concepts can be naturally expressed as modules. If you have, for
example, the concept of "string", you can write a module which represents
such a string, with all the necessary data and functionality related to
strings. When such a string module has been properly designed, it becomes
easier and more manageable to handle strings in the program. The rest of
the code doesn't have to worry about how strings are handled; they just
use the functionality provided by the module. This also makes it easier
to *change* the implementation of this string module without breaking
existing code.

> Despite all claims, I'm convinced this has virtually *nothing* to do with how
> normal people *really* think (at least when faced with the task of explaing to
> some dumb box how it should *do* something), and has even less to do with OO
> *programming*.

  Oh, it has a lot to do with how normal people think, and how other things
(such as big companies) are organized.

  When you go to a grocery store to buy food, you don't have to care how
the grocery store works internally. You just use its "interface" to buy the
food and that's it. The store takes care of its own inner functionality.
That's modularity and object-orientedness in action, in real-life.

> David, you hear me? *This* is *not* OOP. This is indeed BS originally from
> people leaning on the shallow theoretical side, trying to sell "OO"-labelled
> products (compilers, tools, training, consulting, whatever) to people who
> haven't experienced the benefits of OOP in practice yet.

  I'm sorry, but I think that the one writing bullshit is you.

-- 
                                                          - Warp

Post a reply to this message