What is/is not considered to be good OO programming

[Tony Marston]

Several months ago I started a thread with the title "What is/is not
considered to be good OO programming" which started a long and
interesting discussion.

I have condensed the arguments into a single article which can be
viewed at
http://www.tonymarston.net/php-mysql/good-bad-oop.html

I fully expect this to be the start of another flame war, so sharpen
your knives and get stuck in!

Tony (you do it your way and I'll do it better) Marston
http://www.tonymarston.net/

[Tony Marston]

Jochen Buennagel <za*********@buennagel.com> wrote in message news:<br*************@news.t-online.com>...

Tony Marston wrote:

Isaac Newton did not have to rediscover for himself a
thousand years of Science. He stood on the shoulders of giants.

He had giants, I have pygmies.

...he said, offhandedly dismissing 40 years of advancement in software
development...

Somebody out there may be making advancements, but not every "change"
is an "advancement". Some people think OOP is the best thing since
sliced bread while others think it as a pile of pooh. So who is right?

If you are just creating a few big classes that match each part of the
system, then you are right. All you have done is used the flexibility of
OO to recreate a paradigm you are familiar with. You could just as
easily have written it in Modula 2 or used structs and pointers in C.

Probably, but I chose to write it in PHP.

Whatever language you use: Using classes and objects doesn't make a
program object oriented.

OH YES IT DOES. If I utilise the OOP capabilities of a language to
create classes/objects which demonstrate encapsulation, inheritance
and polymorhism then that is all I need to claim that the program is
object oriented. The fact that my method of doing so is different from
your method is totally irrelevant.

As an example take Dick Fosbury who invented the "Fosbury Flop". Until
he came along all high jumpers used the same technique, which was one
leg first. He devised his own technique which was to jump backwards
over the bar. Did that make him any less of a high jumper just because
his technique was different?

He jumped over the bar, therefore he was a high jumper. My software
uses objects, therefore it is object oriented. Ipso Facto. Quad Erat
Demonstrandum. Quid Pro Quo. Et Cetera.

I like to take things easy as well, which is why I create development
environments which enable me to create working components in hours or
minutes instead of days or even weeks.

Anyone can create "working" components very quickly. That says nothing
about wether they can be easily maintained and adapted to changing
requirements, which is what most development time is spent doing.

If you have to rewrite half your system for every change, I'd rather
spend more time on the initial creation. Shortcuts make long delays...

Jochen

My software is designed for both ease of initial development and ease
of maintenance. After all, I have had 25+ years of practice.

Tony Marston
http://www.tonymarston.net/

[André Næss]

Tony Marston:

What this means in practice is that if you by have this piece of software
which takes 1 week to develop, and 3 weeks to maintain, you're better off
if you can spend 2 weeks developing and only 1 week maintaining.

If you can write something from scratch in 1 week but take 3 weeks to
maintain it then you are doing something wrong. If the scale of
changes were that huge I would scrap the original program and rewrite
it.

I realize that maintenance probably isn't a fitting word. Evolution is.
Software systems tend to evolve, and most of the time will be spent
evolving the software. If the system is badly written from the start this
may become a painful process, and this very process will probably cause
more bugs to appear. In extreme case you may even have the situation where
minor changes to the system's behaviour requires massive changes to the
code. My main point is, in short, that I disagree when you say that "the
aim of the software developer is to produce software as quickly as
possible.". It's obviously desirable, but one should always focus on making
the system evolable.

André Næss

[Tony Marston]

André Næss <an*********************@ifi.uio.no> wrote in message news:<br**********@maud.ifi.uio.no>...

Tony Marston:

What this means in practice is that if you by have this piece of software
which takes 1 week to develop, and 3 weeks to maintain, you're better off
if you can spend 2 weeks developing and only 1 week maintaining.

If you can write something from scratch in 1 week but take 3 weeks to
maintain it then you are doing something wrong. If the scale of
changes were that huge I would scrap the original program and rewrite
it.

I realize that maintenance probably isn't a fitting word. Evolution is.
Software systems tend to evolve, and most of the time will be spent
evolving the software. If the system is badly written from the start this
may become a painful process, and this very process will probably cause
more bugs to appear. In extreme case you may even have the situation where
minor changes to the system's behaviour requires massive changes to the
code. My main point is, in short, that I disagree when you say that "the
aim of the software developer is to produce software as quickly as
possible.". It's obviously desirable, but one should always focus on making
the system evolable.

André Næss

If a development environment is constructed properly then it should
make it easy to both create new components and maintain existing ones.
You have to create a reasonable balance between the two and not
concentrate too much on one aspect to the detriment of the other. I
have been creating development environments for 20+ years with both
these aims in mind, and I have succeeded. I have done it in COBOL,
UNIFACE and now PHP.

Making a system evolvable is not something you can guarantee as you do
not know what form this evolution will take. Simple changes such as
adding or removing fields, adding or removing tables, or modifying
business rules here and there is one thing, but if the nature of the
business changes in a drastic way then evolution is not possible - you
have to rewrite from scratch.

Take for example the steam engine. You cannot modify one piece at a
time and turn it into an internal combustion engine - you have to
throw the whole thing away and start from scratch.

But after you have built your internal combustion engine some smart
ass comes along and invents the gas turbine - so what then? It is
impossible to plan for the future as no-one knows what the future will
bring. It is only possible to plan for reasonable changes based on
past experience.

Tony Marston
http://www.tonymarston.net/