Re: OO-Inquisition
- From: "Phlip" <phlipcpp@xxxxxxxxx>
- Date: Wed, 18 Apr 2007 01:18:58 GMT
coeval wrote:
I am flaggerbasted how Topmind is treated in comp.object newsgroup.
Party with him for 10 years and see how you feel.
Just for saying OO is not the dreamed "silver bullet" that would fix
all issues in software coding.
He doesn't say that. He essentially parrots back legitimate criticisms of
details of OO implementations, then conflates them into grandiose rants
against OO.
OO is a tool. Discard all hammers because you once banged your thumb? I
don't think so...
Many of posts are very blunt, people overacted, like Catholic Church
during The Inquisition.
We do overreact. That's because he has learned how to ellicit these effects,
and his game is to make us overreact. He's not overtly invective, like some
trolls, yet he is indeed one.
People are scared of their IT carreer but less about the ease of
coding and maintaining an application. I work for 20 years of
programming, OO, SQL plus a lot database designs in Relationnal / OO
databases. As a pragmatic developer I made my own opinion about OO
paradigm.
Did you only use virtual methods when they simplify code, decouple systems,
manage dependencies, and make things easier to upgrade?
Basically Topmind is right, for "device code" OO is quite
useful but for large biz application coding by several teams and
numerous programers with different skills under budget/time
constraints, it has some pitfalls.
Let's discuss the two biggest branches of OO - Static and Dynamic. The
closer to the metal you get, the more you need Static Typing OO. The farther
above the metal you go, the more you need Dynamic Typing OO.
It's not as good as it looks like
in in OO-books or in "OO-monks" preaches. begun my IT career as a C++
developer using Zortech and Glockenspiel C++ ersatz compilers coding a
middle size application (80 000 LOC) . All was done using all OO
features; inheritance, avoid if/then/else, switch/case... and so on.
C++ is on the Static side.
How many unit tests did you have?
After a couple of years of maintaining this application I noticed I
was improving/fixing more efficiently this application by
"refactoring" the database, I mean by changing the database and
migrating data rather than changing the OO code.
That sounds to me like the OO code had matured but the database had not. It
sounds like you could change the data without changing the OO code, so it
adapted to the new database contents.
That was a big shock,
what about is the OO "reuse" motto.
Uh, not really. Dependency management can lead to incidental reuse. The best
situation is "Don't Repeat Yourself." You should write DRY code that doesn't
repeat the same concepts everywhere.
In addition when my customer asked
to change some features in the application code, it was tedious to
pinpoint where/how to change the code, some part of the code was under
12 levels of inheritance,
Have you read /Design Patterns/? It never specifies more than 2 layers of
inheritance. Never inherit as a "compilable comment", just to declare two
things to be related. The most practical form of indirection is still simple
delegation.
some functionnalities were spread in many
files, very hard to maintain and hard to read as well. Most of my IT
career I noticed programers writes code but they don't read it after a
while. Now, I push programmers to follow a strong coding guideline and
I review the final code every new build.
There simply no way to underestimate the power of unit tests. They force
code to decouple, and you typically upgrade code by finding the unit test
case closest to your change, cloning it, and modifying it to require the new
behavior. Then when the test fails for the correct reason, you upgrade the
code, and repeat until you have the new feature.
17 years later, I am still fighting with the "OO features" not in C++
but in Java.
There's no way to say this delicately - Java incredibly sucks. It was
invented as a negative - to appeal to bosses of C++ programmers, who are
tired of hearing "oh I have a bug because my array overran" or "my pointer
dangled".
No arrays and no pointers != no bugs.
Java is poorly conceived and excessively verbose. And if it intends to work
far from the metal, it should have used Dynamic Typing, like Python, Ruby,
or Smalltalk.
I am in charge to maintain, deploy, improve a large
application in Java (1.200.000 LOC) written by a 3rd company.
There are languages that could provide the same feature count for <100 000
lines of code.
Formerly, connected to an OO-database and after 2 years re-designed to
use RBDMS database due to performance and database size issues. Same
as 17 years ago, I am still changing the database, as a workaround, to
fix and improve the application. For me and I am not the only person
to think that large, endless changing biz application is very
challenging to code using an OO techniques.
OO should be seen as a tool addressing specific issues in coding and
design, same as backtracking engine for gaming appz or expert system.
Right. When you grow code with unit tests, you can easily change the design,
so it doesn't decay as the program matures. The OO designs in that code once
worked, way back when they were first planned. Adding more and more features
probably filled the original design up with compromises and entanglements.
Your code probably has no unit tests. They are the missing bang for your OO
buck.
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html
.
- Follow-Ups:
- Re: OO-Inquisition
- From: topmind
- Re: OO-Inquisition
- References:
- OO-Inquisition
- From: coeval
- OO-Inquisition
- Prev by Date: Re: Dependency Management (Was: Mixing P/R philosophy with OO)
- Next by Date: Re: OO-Inquisition
- Previous by thread: Scaling Up (was: OO-Inquisition)
- Next by thread: Re: OO-Inquisition
- Index(es):
Relevant Pages
|
