Re: modularity... (was: Re: Looking for real world examples to explain the difference between procedural (structured?) programming and OOP)


"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote in message
news:dUu%l.300$9l4.89@xxxxxxxxxxxxxxxxxxxxxxx
Responding to cr88192...

I was mainly objecting to the notion of JavaScript as an OOPL. It does
not <directly> support very basic OOA/D concepts, such as the separation
of relationship implementation, instantiation, and navigation. Worse, it
encourages bad OOA/D practices, such as passing object references
around. Those issues, in turn, adversely affect the maintainability of
large applications because one cannot properly isolate and encapsulate
concerns separately when necessary.


it depends a whole lot though on ones' definitions of OO.

you seem to equate OO with OOA/D.

Yes, I do. The OOPLs came first but OOA/D formalized what the paradigm is
actually about. If one gets the OOA/D right, then it doesn't matter what
compromises the OOPLs make with the hardware computational models.

Also, I am a translationist. B-) We don't do 3GL code at all; that is a
job for the transformation engine (aka code generator). I doubt I have
written 10 KLOC of 3GL code total since 1989. So I would lose my
translationist union card if I cared about OOP practices.

[FYI, in R-T/E, where performance is usually critical, it is fairly
routine for the transformation engine to produce either C code or Assembly
code directly from an OOA model rather than OOPL code. That's because one
does not have to maintain the code so one can employ languages that are
inherently more efficient. So in principle there is nothing to prevent a
transformation engine from generating JavaScript. As long as changes are
made to the model and the code is regenerated there is no problem with 3GL
maintainability.]


for those of us who do use 3GLs, coding issues are primary...


others associate OO with classes and inheritence.

Those are in OOA/D as well.


they "are in" OOA/D, but this is very different from saying "classes and
inheritence == OO", which is more what was in question here.


others associate OO with "passing around things by reference";

That's a really bad habit to get into because it is the worst form of
coupling. It is definitely not good OO practice at any level.

Unfortunately OOPLs like Java strongly encourage it. That's one reason why
jumping into OO development starting directly with OOP is a really bad
idea. Show me an "OO Guru" who advocates indiscriminate passing of object
references to behavior methods and I will show you someone who converted
from procedural development to OO development directly at the 3GL level
without bothering to learn OOA/D.


this is, however, a line of thinking which some people had before used to
promote Scheme as an OOPL...

under my definitions it is not, as my personal defintion of OOPL is "has
C/I-OO or P-OO facilities".


There are five dead giveaways to such converts:

-- passing object references to behavior methods (coupling, caller
cohesion problems, and hierarchical dependencies)

-- behavior methods returning values (hierarchical implementation
dependencies)

-- defining behavior responsibilities for one object that are just a
pass-through for delegation of the implementation to another object
(bleeding of cohesion across objects and hierarchical structure)

-- objects with names like XxxManager or XxxController (god objects and
hierarchical functional decomposition)

-- method calls with lots of arguments (failure to separate knowledge
access from behavior access and hierarchical dependencies).

[You might note that 'hierarchical' shows up in each problem description.
That's no accident because all of these things represent a procedural
developer overlaying the functional decomposition paradigm on OOPL code.
One can argue that the OO paradigm's primary contribution to maintainable
software is elimination of hierarchical dependencies.]


yes, ok.


others associate it with "code which looks like Java";

That's only relevant to OOP where the languages needs to provide explicit
mappings into the hardware. Without proper OOA/D the OOPLs provide myriad
opportunities for foot-shooting.


these people would likely reject something as an OOPL if it doesn't look
like Java...


On my bookshelf I have three entire books devoted solely to refactoring of
OOPL code to make the code more maintainable. Those books exist to support
code-focused OO development during OOP. In essence they distill good OOA/D
practices into cookbook guidelines for refactoring during OOP. Note that
those techniques are applied *after* the code is working. In effect, they
help the developer recover from the bad habits the OOPLs tend to
encourage. (One never has a need to refactor working OOA/D models to make
them more maintainable because one is practicing the methodology that the
OOP refactoring books distill.)


ok.

it can be noted that cookbook style rules are the "real" part of the
practice.
apart from specific rules and constructions, it is all amorphous and
ill-defined...

it is like, to have law and order, we need laws...



thing is, there would not seem to be any "solid" definition as to what
exactly this "OO" is, so FWIW, I don't think it particularly relevant to
argue what is and isn't OO.

<Hot Button>
People keep saying this, but there is no basis for it. OMG spent nearly
two decades defining a formal semantic meta model for it (i.e., UML is a
standard just like the ANSI C standard). In addition, there is the
Dictionary of Object Technology as an authoritative reference on the
semantics. (IIRC, the DoOT has 16 pages of definition for 'object', which
is a lot more definition than most things have.)

Finally, there are a gazillion books on OOA/D that pretty much agree about
what the paradigm is about. More important, their methodologies may differ
in detail but they are very much in agreement about the underlying
fundamental principles (e.g., what inclusion polymorphism is and how it is
used or that everything starts with problem space abstraction and defining
static structure in terms of classes and relationships).
</HOT Button>


OOA/D "agrees" as what the terms mean.

this does not mean, however, that everyone else agrees with OOA/D...


it is much like if you ask a Muslim if pork is immoral. they will say it is,
and may provide links to many relevant and authoratative books as to show
the immoral nature of pork.

now, go ask someone else who does not agree with the Islamic view on pork
(and who is not a Muslim). will they agree?... no, most likely they will
not.

local definitions != universal agreement.

so, different people will define said term differently.


but, alas, this all amounts more to a philosophical debate, rather than
debating anything which actually exists...


Granted, there are certainly shortcomings with the language. The
typeof, operator parseInt, and the Date object, to name a few.

Host objects are such things as an HTML document, the browser window,
or XMLHttpRequest. These things are not native to the language. The
APIs developed by Netscape, Microsoft, and the w3c have affected how we
code our scripts. Many of the w3c standards were copied from vendor
APIs, such as microsoft's DOM. Sometimes the standard was specified in
ways that are incompatible with the original.
I agree that the infrastructure vendors have not helped and, in fact,
have often discouraged good OOA/D practice. That's because they were
largely designed to support the CRUD/USER layered models and the RAD
form/table paradigm.

But, as you point out, that just leads to a chicken & egg problem. Did
the infrastructures build around JavaScript or did JavaScript build
around the infrastructures?


a similar issue can be raised about Python...


'Python considered harmful'... or at least, as can be noted by the
prevalence of nearly every Python based app I have seen to crash randomly
(typically with "unhandled exception" errors, or typically "parse error"
errors).

Maybe; I don't use Python so I have no personal experience. I do know of
one large MMORPG that is coded in Python that cashes maybe once a month in
23x7 operation with an average of about 30K players at any given time.
OTOH, Python is a member of the family of OOPLs that was derived in large
part from scripting languages. So maybe there is a correlation. B-)


it is not that people can't make stable code in Python, it is just that
probably Python is really good at allowing users to make really crappy code
and not detecting errors until runtime...

if Python had a compiler with a lot more compile-time checking, likely the
situation could be improved considerably (or, at least, after people fixed
their code of a probably huge number of errors which will magically appear
upon use of such a compiler...).




--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.lahman@xxxxxxxxxxx
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html


.

Quantcast