Mail Archives: djgpp/1997/06/02/05:30:06
Mark T Logan wrote:
> Can you tell me where to get sliced bananas?
You need to ask in the correct newsgroup. Try
alt.bananas.sliced.
<g>
>>> You see, when a team of twenty people start to work on a massive
>>> program, a procedure oriented language simply ***will not work***.
>>
>>Oh dear. I guess I'd better resign from all those C projects I've
>>been on, then. Can I have your real name so I can quote you as a
>>reason to abandon the projects?
>
>You probably could have gotten my name from the mail header, but if
>you can't, I'm Mark Logan.
For some reason it seemed to be missed off when I replied.
> Maybe I should have been more specific. Just because
> there's a bunch of people on your team doesn't mean you
> can't use a procedure oriented language. I was a bit
> hasty on that one.
Indeed. But you did say 'twenty' - I've worked on projects with
many more than that, and some using languages even less suited
to OOP than C (ever seen CORAL-66? You don't want to...).
> But software can eventually reach a level of complexity
> where you traditional procedure oriented techniques start
> to show serious flaws.
Certainly. Which is why modular programming became popular
when the average program reached that complexity.
> Of course, if you are writing a program that is meant to
> model a procedure, such as a 3d engine, then procedure
> oriented is your best choice no matter what the size.
> When it comes to modeling object behavior, like weather
> simulators, object oriented design becomes essential.
Not essential, just easier sometimes. But using OO methods
where not appropriate causes even more problems, just as
using data abstraction on simpler programs does. Have a look
at some of the classes MS and Borland come up with in their
libraries, they go through all sorts of convolutions to
do a simple function because the paradigm is wrong.
That's why I describe it as a 'fad' - lots of people just
jump on the term as the solution to everything. Just like
in the 60's it was computers which were going to be the
solution to all the world's problems. OOP is here to stay,
and will always be useful for a certain class of problem,
just as procedural, modular and data abstraction will always
be for the problems they were intended to solve.
For a description and comparison of the various systems, have
a look at Stroustrup's 2nd edition C++ book, he goes through
all four systems near the beginning.
Incidentally, most proponents of OOP forget* that there's
anything between monolithic blocks of procedures and total
object orientation. In fact, modular programming solves
a lot of the problems, and data abstraction many of the rest.
I do use C++ by preference now, even though seldom do I
need to go beyond data abstraction (non-trivial types and
operator overloading). The language is certainly useful,
I never meant to imply otherwise.
* I'm being charitable. Possibly some of them deliberately
confuse the issue. Me, paranoid?
Chris
- Raw text -