Tuukka,
> Well designed C code has many object-oriented features. In fact, object
> orientedness is a design style for which some languages (C++) may give more
> help than other languages (C), and not any programming language.
I agree. Object-oriented programming is nothing more than the
application of the interchangeable parts concept to software. It is a design
strategy applicable to any language.
Interchangeability requires that interaction be limited to
replicated interfaces. Mechanical part interchangeability is achieved
by building parts according to a template that holds the shape where they
mesh. Building according to a template requires meticulous repitition.
Without automation, the chance of meticulous repitition shrinks rapidly
with size. Many well designed C projects use custom automation (usually
by use of macros). Languages like lisp and C++ standardize and automate
this meticulous repitition.
I responded fervently, because I have too often seen C++ sold as
a "superset of C that provides the order-of-magnitued benefits of
object-oriented programming without the need to retrain engineers".
Porting to C++ won't automatically make a design object-oriented, but it
will tell you the first time you break the object-oriented paradigm
IF YOU LISTEN. It may not be able to tell you the next time you break
the paradigm.
>> ignoring C warnings, DO NOT IGNORE C++ WARNINGS. Object-oriented
>> programming lets you write code 10x faster, if you KEEP THE BLACKBOXES
>> BLACK. The first
> I hardly believe the difference is that big except for special cases.
Unfortunately, I have found that the difference really is that big.
Assume r of your gears in stock have even one bad tooth. Consider the chances
that your n-gear box is going to work (without redundancy). Consider the
rework time if you have to replace f of the gears to find the bad one.
chance
it expected
r f n works rework build time
0% 0% n 100% 1 n
1% 10% 10 90% 1.01 10
1% 100% 10 90% 1.11 11
10% 10% 10 35% 1.19 12
10% 100% 10 35% 2.86 29
1% 10% 100 37% 1.17 117
1% 100% 100 37% 2.70 270
10% 10% 100 .003% 3334.23 333423
10% 100% 100 .003% 33333.33 3333333
1% 10% 1000 .43% 24.16 24160
1% 100% 1000 .43% 232.56 232560
10% 10% 1000 10^-26% 10^25 10^28
10% 100% 1000 10^-26% 10^26 10^29
r f n (1-r)^n 1+f(1-(1-r)^n)/((1-r)^n)
The chance it works drops exponentially as the number of components
rises. The expected rework rises faster than exponential with replication
unreliablity and becomes proportional to the portion of failure candidates.
Any benefit derived from gear replication (code reuse) is lost rapidly.
Warnings are not proof of failure, but each usually represents
a 1-10% (r) chance of mismatch.
A 100-line program is not likely to benefit much from reusable
code, nor suffer much if an interface is broken. A 10 Kline program is
likely to benefit from reusable code, and suffer significantly if an
interface is broken. A 1 Mline program is virtually impossible without
object-oriented design (or a handful of other strategies). Modularity is
required for object-oriented programming, but is not sufficient.
Large scale programming requires reliable (to reduce r) replication,
redundancy (to scale down the exponent n), and fine-grained (to reduce f)
modularity. The automation of object-oriented languages (if used) provides
reliable replication. Good algorithm choice provides redundancy. Good
problem division yields fine-grained modularity.
> [The] opinions are my own. Feel free to correct me if I'm wrong :)
Please consider the above my opinion, and I invite your comments.
If lengthy, please respond direct (lest we trigger a design philosophy war
on this list) and we might generate a joint summary.
Thank you,
--
Dr. Robert J. Meier
1-248-650-9488
[EMAIL PROTECTED]
