OO in PHP

[Mudge]

Please, someone, tell me why OO in PHP is better than procedural.

[Manuel Lemos]

Hello,

Oh, I thought this thread was over! ;-)

On 10/21/2004 01:17 AM, Marcus Baker wrote:

More features usually means more code.

Funnily enough I don't find that to be true anymore. My experience has
been that the core code gets more highly factored and it shrinks as more
features are added. The incoming code about balances the core shrinkage.

The result of this is that about a third of the way through a project
you tend to hit a maximum code size. My experience of this effect has
been on three largish OO projects all with a refactoring culture.

In the real world you only refactor code when you do not have nothing
better to do. If your code already works well and you are busy, usually
you just don't give priority fixing what isn't broken unless you are a
"prima donna" (ego motivation, not logic reasons) and have plenty of
free time to refactor code that already works well.

Often, refactoring code for no really important reason is
counterproducti ve because developers are humans and make mistakes, so
the chances are that new bugs will be added where none existed.

I am not saying that refactoring is bad, I am just saying that it should
only be done when it is absolutely necessary and more important than
other project tasks.

Anyway, this thread was about the misunderstandin g of the benefits of
AOP and then how code generation can improve the overall software
quality and help implementing AOP in languages that do not support it
natively. Refactoring was only brought up because it seems that AOP and
code generation techniques are not yet well understood approaches, just
like OOP used to be in the past (for some people the benefits of OOP
continue to be misunderstood).

BTW, regarding code generation and AOP, the next version of Metastorage
will also feature the automatic generation of classes to generate
reports from an high level definition.

This is one very important feature that complements well the
capabilities of Metastorage to generate Data Access Object (DAO) classes
to do the object relational mapping.

DAO classes are not appropriate to generate reports because the design
pattern that they employ is not meant to retrieve data from arbitrary
combinations of objects.

The new report class generation support of Metastorage permits
generating reports in much less time using an object query language with
capabilities similar to SQL but using an object notation. This way
nobody has to write SQL by hand but can still benefit of its power.

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

[Marcus Baker]

Hi...

Sorry for restarting this old thread. I don't touch NNTP much these days
and forgot my news reader defaults to oldest first :/.

Manuel Lemos wrote:

In the real world you only refactor code when you do not have nothing
better to do. If your code already works well and you are busy, usually
you just don't give priority fixing what isn't broken unless you are a
"prima donna" (ego motivation, not logic reasons) and have plenty of
free time to refactor code that already works well.
That used to be the case, but my current project and my Sourceforge
projects have completely changed my view. We are now much more
aggressive in our refactoring and actually schedule some time for it.
Now the amount of refactoring we do can in no way be called gold plating
and there is still much that could be done, but the earlier pre-emptive
refactoring that has been done has had a real positive practical
business impact. This has absolutely nothing to do with "ego" thanks
very much (we just aren't that kind of team), we started doing it
because we were fed up with running into issues that we had already half
predicted at the time we first wrote the code. When you just run into
them later at a time when you are less familiar with that code section,
it's just so much less efficient.

So we all have background refactoring tasks. Tasks to be getting on with
when no one is around to pair or you are stuck waiting for something
else to be completed. This frees up a good 10-15% of time just for
making the code better.

Even this amount of time has really improved things. What has happened
is that the refactorings themselves point out new opportunities. It also
allows us to more accurately gauge adding new features, as we don't have
to fix anything before putting the new code in. Sometimes the most
useful thing we do is just to deprecate old junk. When someone new joins
the project there is an enormous cost getting them up to speed. At that
point extra code costs real money (pounds sterling in our case).

Often, refactoring code for no really important reason is
counterproducti ve because developers are humans and make mistakes, so
the chances are that new bugs will be added where none existed.
We don't get those kind of bugs anymore. Regression testing and
pairing/review pretty have pretty much eliminated them. What bugs are
left are design issues and requirements mismatch. If you are refactoring
you aren't changing much in the way of interfaces, so requirements
problems are unlikely. As for the design, well you are usually reducing
excess code and simplfying the design or sometimes just making it easier
to understand or you wouldn't be refactoring in the first place.

I have never found the introduction of new bugs an issue when refactoring.

I am not saying that refactoring is bad, I am just saying that it should
only be done when it is absolutely necessary and more important than
other project tasks.

What is "absolutely necessary"? What is important to us is easier
development day to day. Refactoring lightens the load for everybody.
Your opinion is way off here (as mine was). Allocate a refactoring time
percentage and see what happens over a longish period. It's surprisingly
beneficial.

yours, marcus
--
Marcus Baker, ma****@lastcraf t.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

[Marcus Baker]

Hi...

Tony Marston wrote:

You are missing my point. It is possible to use non-OOP and produce
something that shines just as it is possible to use OOP and produce someting
that stinks. It is not what you use but how you use it that counts.
Everything is possible with a computer. It is easier to do some things
one way instead of another. It is easier to build enterprise apps. with
OO than without once the skills have been learned. Simply stating that
the most incompetent OOer will be worse than the best procedural coder
only says that the bell curves overlap. We are interested in where the
mean of those bell curves are, not the end points. The OO mean is in a
more favourable position in both my experience and that of just about
every developer I know.
That's your opinion. I disagree.
Frankly I find your attitude tiresome. Just because you may post based
on opinion does not mean that everybody else does. There are plenty of
texts explaining what functional and OO languages are. Look up how both
are built from "closures" for example.
Polymorphism is not a code reduction tool, inheritance is.
I now see the reason for your thinking that OO and procedural are of
equal value. Sadly you seem to have little real world experience of OO.

By making the parameters of an operation take a wide range of types, you
save having to recode that operation. That in itself is a slight code
reduction tool. It works fully in OO because the subject of the
operation can expose methods that take on the burden of the code
variation. It works in functional languages too because in those
languages you can pass sub functions themselves around polymorphically .
It's the code variations that must be polymorhic in an extensible way.

Inheritance buys you far less code reduction by affecting only code
within a type. It also has the additional problem that it can get you
into a design mess. Inheritance hiearchies tend to be shallow precisely
because they are less necessary for factoring.
and you do not have to use OOP to achieve polymorphism.
Code example?

Even in a procedural only language you can use functional techniques too
(say by passing function names). You could use OO techniques by placing
function names inside data structures without using any OO keywords of
the language. Only, if you have to bend a procedural language that much
you are probably using the wrong language.
Changes in requirements are down to the client, not the developer.
Changes are inevitable with even the most skilled client in the world
because of market changes during the project. Coping with those changes
is very much the task of the development team. The full spec. up front
way of doing things is rightly disappearing fast.
It is just as possible to have an OO design that is difficult to change just
as it is a non-OO design that is easy to change.
It is easier to build a design robust in the face of change if it is
built in the language of a domain. The changes are localised that way.
You missed the point (again). A non-OO solution will result in shotgun
surgery exactly because the business data will be scattered into
multiple functions.
It is not the right tool for every job. A good procedural programmer can
beat the pants off a bad OO programmer every time.
Which is not the point (yet again). A good OO developer will beat the
good procedural developer over the long run and so end up pursuading the
procedural person to switch. I see that a lot and I don't see anyone
going back the other way.

It is not what you use but how you use it that counts.

Well, just because I can eventually cut wood with a spoon does not mean
I won't go faster with the band saw.

yours, Marcus
--
Marcus Baker, ma****@lastcraf t.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

[Tony Marston]

"Marcus Baker" <ma****@lastcra ft.com> wrote in message
news:41******** ******@lastcraf t.com...

Hi...

Tony Marston wrote:

You are missing my point. It is possible to use non-OOP and produce
something that shines just as it is possible to use OOP and produce
someting that stinks. It is not what you use but how you use it that
counts.
Everything is possible with a computer. It is easier to do some things one
way instead of another. It is easier to build enterprise apps. with OO
than without once the skills have been learned.

Unfortunately too many people who teach these skills are nothing more than
cowboys and charlatans, so many end up by being taught badly.
Simply stating that the most incompetent OOer will be worse than the best
procedural coder only says that the bell curves overlap. We are interested
in where the mean of those bell curves are, not the end points. The OO
mean is in a more favourable position in both my experience and that of
just about every developer I know.

That's your opinion. I disagree.
Frankly I find your attitude tiresome. Just because you may post based on
opinion does not mean that everybody else does. There are plenty of texts
explaining what functional and OO languages are. Look up how both are
built from "closures" for example.

Polymorphism is not a code reduction tool, inheritance is.

I now see the reason for your thinking that OO and procedural are of equal
value. Sadly you seem to have little real world experience of OO.

Wrong again. My years as a procedural programmer have taught me to tell the
difference between good and bad programming. When I see some of the stuff
that OO people produce I have to reach for a sick bag. Too many of the new
programmers are taught nothing but OO, so they don't know how to tell the
difference.
By making the parameters of an operation take a wide range of types, you
save having to recode that operation. That in itself is a slight code
reduction tool. It works fully in OO because the subject of the operation
can expose methods that take on the burden of the code variation. It works
in functional languages too because in those languages you can pass sub
functions themselves around polymorphically . It's the code variations that
must be polymorhic in an extensible way.

Inheritance buys you far less code reduction by affecting only code within
a type. It also has the additional problem that it can get you into a
design mess. Inheritance hiearchies tend to be shallow precisely because
they are less necessary for factoring.
Exactly. Class hierachies which are too deep can cause problems. Procedural
languages don't have class hierachies, therefore they don't have those
problems.

and you do not have to use OOP to achieve polymorphism.

Code example?

When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure
where the business layer was comprised of service components, one for each
business entity. Each service component had two operations, getData() and
putData(), therefore I could communicate with any business entity using just
those two operations without knowing what the actual entity was.
Even in a procedural only language you can use functional techniques too
(say by passing function names). You could use OO techniques by placing
function names inside data structures without using any OO keywords of the
language. Only, if you have to bend a procedural language that much you
are probably using the wrong language.

Then don't bend the language. Use it as it was designed to be used. If you
try to bend it and you fail, then the fault lies with you, not the language.

Changes in requirements are down to the client, not the developer.

Changes are inevitable with even the most skilled client in the world
because of market changes during the project. Coping with those changes is
very much the task of the development team. The full spec. up front way of
doing things is rightly disappearing fast.

It is just as possible to have an OO design that is difficult to change
just as it is a non-OO design that is easy to change.

It is easier to build a design robust in the face of change if it is built
in the language of a domain. The changes are localised that way. You
missed the point (again). A non-OO solution will result in shotgun surgery
exactly because the business data will be scattered into multiple
functions.

A solution is not necessarily bad because it is procedural. A solution is
not necesarily good because it is OO.

It is not the right tool for every job. A good procedural programmer can
beat the pants off a bad OO programmer every time.

Which is not the point (yet again). A good OO developer will beat the good
procedural developer over the long run and so end up pursuading the
procedural person to switch. I see that a lot and I don't see anyone going
back the other way.

If you know how to apply the principles of OO properly then you can achieve
better results and would not want to go back to procedural methods. But the
key word is "properly". If the principles of OO are applied improperly then
the result will be a right royal cock up.

It is not what you use but how you use it that counts.

Well, just because I can eventually cut wood with a spoon does not mean I
won't go faster with the band saw.

If you ask two people to design an implement to cut wood the one with a
procedural background will design a saw. The one with the OO background will
spend so much time abstracting down to the nth degree, designing class
hierarchies, deciding between inheritance and object composition that he
will come up with something that does more than is required and which cuts
wood badly.

You will never convince me that OO is the holy grail, so don't waste your
time trying.

--
Tony Marston

http://www.tonymarston.net

[2metre]

Tony Marston wrote:

When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure where the business layer was comprised of service components, one for each business entity. Each service component had two operations, getData() and putData(), therefore I could communicate with any business entity using just those two operations without knowing what the actual entity was.

What you have just descibed *IS* Object Orientated programming!
Seems you appreciate OOP more than you realise! Your 'Service'
components are objects, you 'operations' are methods of those objects!

[Tony Marston]

"2metre" <2m****@xxxhers ham.net> wrote in message
news:cl******** **@titan.btinte rnet.com...

Tony Marston wrote:

When using a non-OO 4GL called UNIFACE I designed a 3 tier

infrastructure

where the business layer was comprised of service components, one for

each

business entity. Each service component had two operations, getData()

and

putData(), therefore I could communicate with any business entity

using just

those two operations without knowing what the actual entity was.

What you have just descibed *IS* Object Orientated programming!
Seems you appreciate OOP more than you realise! Your 'Service' components
are objects, you 'operations' are methods of those objects!

It is very similar, I agree, but the language is not Object Oriented as it
does not permit the instantiation of objects from classes. It does however
permit the creation of component instances from components. As for
inheritance, this is only one level deep - from a component template to a
component - and is not as flexible as multi-level inheritance that I use
with PHP. It also does not allow the accessing of component variables
through anything other than a parameter on an operation (function).

For a detailed comparison take a look at
http://www.tonymarston.co.uk/php-mys...jects.html#a4a.

I have to say that using that language made it easier to step into the world
of OO, but there are SOME people out there who think that my approach is
unacceptable. The arguments for and against can be found in
http://www.tonymarston.co.uk/php-mys...d-bad-oop.html

--
Tony Marston

http://www.tonymarston.net

[Marcus Baker]

Hi...

Tony Marston wrote:

Unfortunately too many people who teach these skills are nothing more than
cowboys and charlatans, so many end up by being taught badly.
Perhaps you could name names here? Can you give an example of a book or
reference by one of these "cowboys"? Can you point us to the correct
texts that are not cowboys?
Wrong again. My years as a procedural programmer have taught me to tell the
difference between good and bad programming. When I see some of the stuff
that OO people produce I have to reach for a sick bag. Too many of the new
programmers are taught nothing but OO, so they don't know how to tell the
difference.
And had they been taught procedural they would would all be perfect?
Exactly. Class hierachies which are too deep can cause problems. Procedural
languages don't have class hierachies, therefore they don't have those
problems.
Well I can crash my own car at high speed, but that's a testament to the
power of the car. I am not going to walk everywhere because I am too
scared to drive.
When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure
where the business layer was comprised of service components, one for each
business entity. Each service component had two operations, getData() and
putData(), therefore I could communicate with any business entity using just
those two operations without knowing what the actual entity was.
A totally incomplete verbal description of two method names. How about a
code example?
Then don't bend the language. Use it as it was designed to be used. If you
try to bend it and you fail, then the fault lies with you, not the language.
I don't, I use a language that has those features. I don't think you are
listening.
A solution is not necessarily bad because it is procedural. A solution is
not necesarily good because it is OO.
You are not looking beyond these black and white end points.
If you know how to apply the principles of OO properly then you can achieve
better results and would not want to go back to procedural methods. But the
key word is "properly". If the principles of OO are applied improperly then
the result will be a right royal cock up.
OO has a steep learning curve and that is very much the downside. It
certainly does take a year, more like two, to become fluent. If the
skills are not available, doing a mission critical project in OO is a
very bad idea and it will flounder. I would not recommend it in this case.

In the other hand, if the skills are available, or appropriate mentors
can be hired, then the OO path will win especially over the long term.
If you ask two people to design an implement to cut wood the one with a
procedural background will design a saw. The one with the OO background will
spend so much time abstracting down to the nth degree, designing class
hierarchies, deciding between inheritance and object composition that he
will come up with something that does more than is required and which cuts
wood badly.
Nope. Just because you yourself have that trouble, or because you have
hired the wrong people, does not make the technology bad. Most OO
developers that I know would very much start with the simplest code and
add flex points only as needed. There is a "drunk on power" stage people
go through in the early stages, that's true. You get through it though.

I am a little worried about your organisation that you cannot find a
single skilled OO developer. There seems to be a sickness around, of the
"only hire juniors because they do what they are told" syndrome.

You will never convince me that OO is the holy grail, so don't waste your
time trying.

I doubt I could teach you anything, but that's not why I am posting. I
would hate to see someone reading this newsgroup and be put off learning
by someone who happens to have had bad experiences.

yours, Marcus
--
Marcus Baker, ma****@lastcraf t.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

[Tony Marston]

"Marcus Baker" <ma****@lastcra ft.com> wrote in message
news:41******** ******@lastcraf t.com...

Hi...

Tony Marston wrote:

Unfortunately too many people who teach these skills are nothing more
than cowboys and charlatans, so many end up by being taught badly.

Perhaps you could name names here? Can you give an example of a book or
reference by one of these "cowboys"? Can you point us to the correct texts
that are not cowboys?

http://www.tonymarston.co.uk/php-mys...d-bad-oop.html

Wrong again. My years as a procedural programmer have taught me to tell
the difference between good and bad programming. When I see some of the
stuff that OO people produce I have to reach for a sick bag. Too many of
the new programmers are taught nothing but OO, so they don't know how to
tell the difference.

And had they been taught procedural they would would all be perfect?

No, but they would have experience of other paradigms to draw upon. Those
who nothing but OOP are very blinkered in their approach. I have used a
variety of 2nd, 3rd and 4th generation languages, and each one has had
techniques that can be carried forward into the next one as well as new and
sometimes better ways of tackling similar problems. It is because of my
non-OO background that I can recognise where and when an OO approach may
bring benefits.

Exactly. Class hierachies which are too deep can cause problems.
Procedural languages don't have class hierachies, therefore they don't
have those problems.

Well I can crash my own car at high speed, but that's a testament to the
power of the car. I am not going to walk everywhere because I am too
scared to drive.

A high-speed car in the hands of someone who is competent is perfectly safe,
while one that is in the hands of someone who is one sandwich short of a
picnic is a distaster waiting to happen. As I keep saying, it is not the
tool but the way that you use it that counts.

When using a non-OO 4GL called UNIFACE I designed a 3 tier infrastructure
where the business layer was comprised of service components, one for
each business entity. Each service component had two operations,
getData() and putData(), therefore I could communicate with any business
entity using just those two operations without knowing what the actual
entity was.

A totally incomplete verbal description of two method names. How about a
code example?

It describes the aplication of polymorphism perfectly. A code example in
UNIFACE would be totally meaningless to a non-UNIFACE programmer.

Then don't bend the language. Use it as it was designed to be used. If
you try to bend it and you fail, then the fault lies with you, not the
language.

I don't, I use a language that has those features. I don't think you are
listening.

You are not listening either. Once a language has been chosen for a project
then it would be totally stupid to try to write code that does not fit in
with the way that language is designed to work. So trying to get a non-OO
language to work in an OO way is a disater waitng to happen. I know because
I've seen it done - take a look at
http://www.marston-home.demon.co.uk/...html#disaster3

A solution is not necessarily bad because it is procedural. A solution is
not necesarily good because it is OO.

You are not looking beyond these black and white end points.

I am being realistic. It is you who are insisting that everything OO is good
(white) while everything that is not OO is bad (black). I am simply pointing
out shades of grey.

If you know how to apply the principles of OO properly then you can
achieve better results and would not want to go back to procedural
methods. But the key word is "properly". If the principles of OO are
applied improperly then the result will be a right royal cock up.

OO has a steep learning curve and that is very much the downside. It
certainly does take a year, more like two, to become fluent. If the skills
are not available, doing a mission critical project in OO is a very bad
idea and it will flounder. I would not recommend it in this case.

In the other hand, if the skills are available, or appropriate mentors can
be hired, then the OO path will win especially over the long term.

Unfortunately this steep learning curve is too much of an investment for
some companies. And who do you decide is an appropriate mentor? If you get
taught the wrong ideas by the wrong people then all that investment in
switching to OO will take a very, very long time to bear fruit.

If you ask two people to design an implement to cut wood the one with a
procedural background will design a saw. The one with the OO background
will spend so much time abstracting down to the nth degree, designing
class hierarchies, deciding between inheritance and object composition
that he will come up with something that does more than is required and
which cuts wood badly.

Nope. Just because you yourself have that trouble, or because you have
hired the wrong people, does not make the technology bad. Most OO
developers that I know would very much start with the simplest code and
add flex points only as needed. There is a "drunk on power" stage people
go through in the early stages, that's true. You get through it though.

I am a little worried about your organisation that you cannot find a
single skilled OO developer. There seems to be a sickness around, of the
"only hire juniors because they do what they are told" syndrome.

The problem still exists that too many programmers out there think they are
OO experts when all they can really achieve is to over complicate the issue
and produce bloated and expensive software.

You will never convince me that OO is the holy grail, so don't waste your
time trying.

I doubt I could teach you anything, but that's not why I am posting. I
would hate to see someone reading this newsgroup and be put off learning
by someone who happens to have had bad experiences.

But there are plenty of other people out there who have had similar
experiences. I am simply trying to balance the argument.

--
Tony Marston

http://www.tonymarston.net

[Marcus Baker]

Hi...

Tony Marston wrote:

http://www.tonymarston.co.uk/php-mys...d-bad-oop.html
The part I bothered reading was a bit shallow and I don't find that tone
of article useful or worth bothering with. How about you just name a
single name and save us going around in circles again. Your fuming about
the shape example is frankly a bit silly.
No, but they would have experience of other paradigms to draw upon.
So now you have shifted the ground to people who only have one paradigm?
Hm, a slippery customer indeed. Not the argument.
It is because of my
non-OO background that I can recognise where and when an OO approach may
bring benefits.
Well apparently not if you are using a more limited procedural paradigm
in the very field OO excels. Also since when is knowledge of non-OO
sufficient to recognise anything at all. You need non-OO and OO
knowledge and a lot more besides, such as a good deal of case studies or
experience in both.

In fact most of this knowledge already exists, but we have a lot of
developers who have been promoted to the level of project managers
without training or homework in the field. Oh great, now I'm ranting...

From your article and the thread you pointed at it seems that you were
just about to learn the very OO skills I am talking about. If you had
given it a little longer you would have got it. A shame.
A high-speed car in the hands of someone who is competent is perfectly safe,
while one that is in the hands of someone who is one sandwich short of a
picnic is a distaster waiting to happen. As I keep saying, it is not the
tool but the way that you use it that counts.
You seem to get confused easily. Once you learn to drive you get around
faster. Once you learn the basic OO skills you can more accurately map
business requirements to code. That's the point. You suffer the learning
process to progress long term.
It describes the aplication of polymorphism perfectly. A code example in
UNIFACE would be totally meaningless to a non-UNIFACE programmer.
Pretty pointless example then. How about a PHP one given you are in a
PHP forum? Or were you just trying to confuse the issue by choosing just
about the most obscure example possible.

I don't, I use a language that has those features. I don't think you are
listening.

Once a language has been chosen for a project
then it would be totally stupid to try to write code that does not fit in
with the way that language is designed to work.
I thought you you weren't listening. If I have to bend the language,
that langauge is inadequate. If I have to bend procedural into OO or
functional, then that paradigm is inadequate. Now do you see the point?
So trying to get a non-OO
language to work in an OO way is a disater waitng to happen.
Which is not the point (yet again). If you are trying to bolt OO
features onto an OO language then you should change language. If the
legacy code is too expensive to replace then you have to live with the
limitations of procedural. Hardly desirable.
I am being realistic. It is you who are insisting that everything OO is good
(white) while everything that is not OO is bad (black). I am simply pointing
out shades of grey.
Nope. You can solve problems with procedural if you except that you are
working under limitations. If you have fast changing requirements the
cost to the business of procedural developers will be much higher than
simply spending on those developers with OO skills. You won't lose
anything by doing tasks in OO instead of procedural fashion though,
mostly you gain (at least in the field of e-commerce). Procedural is
just a step in the learning process.

BTW we don't emply people "one sandwich short of a picnic". Instead we
hire people who already have appropriate skills for the task or we get
people who are willing to learn. It would take a dysfunctional
organisation to do otherwise. Resorting to silly examples is rather
desperate.
Unfortunately this steep learning curve is too much of an investment for
some companies. And who do you decide is an appropriate mentor? If you get
taught the wrong ideas by the wrong people then all that investment in
switching to OO will take a very, very long time to bear fruit.
It bears fruit within a year, 3 months or less with pair programming and
the like if the skills are already in house. It's quite remarkable that
you manage to find the "wrong people" with such regularity. We have had
no such problems. I haven't seen the problems you describe in any of the
last six companies I have been involved with. More importantly I hardly
hear about it at all. I think your situation is unfortunate and
exceptional if it was so disastrous. Yes, I have see people go through a
drunk on patterns stage, but it usually only lasts a few weeks.

You are either exaggerating or the projects that have scarred you have
had many more problems than merely being OO. From your link it seems you
had a design imposed on the developers without buy in. Either the skills
were not there, the design was inappropriate or personal factors got in
the way. I don't see an OO problem in there, I see a people problem.
The problem still exists that too many programmers out there think they are
OO experts when all they can really achieve is to over complicate the issue
and produce bloated and expensive software.
As I say, the minority in my experience. If you hire a shop of all
juniors, so there are no skills to go around, then you have a disaster
waiting for happen. That is true of any paradigm or any other skill.
That's true of programming in general. The only time you can get away
with this is to have a trial project which is not mission critical and
willingness by the team to learn from their mistakes. Management don't
see it that way, so that such pilot projects are a rarity in practice.
Whatever project your on, someone in that project should have experience
of all the technical and domain skills needed.
But there are plenty of other people out there who have had similar
experiences. I am simply trying to balance the argument.

You are doing nothing of the sort, you are ranting. You could balance
the argument by saying when OO is good and when OO is bad. You could
compare it with other paradigms to show where they are more appropriate
in certain situations (functional for language processing, logic
programming for rules engines, etc, etc). You haven't.

I am quite happy to argue the pros and cons of different systems of
development. I know nothing of Uniface for instance and it would be nice
to know how that works out in practice. I would also like to know more
about your failed projects as case studies are always useful. This
industry doesn't make the efforts it should to learn from each other.

Unfortunately such one sided rants mean that I cannot trust any
information you now actually put out. You tarnish your own reputation
with polemics.

yours, Marcus
--
Marcus Baker, ma****@lastcraf t.com - http://www.lastcraft.com/
PHP London every first Thursday - http://www.phplondon.org/

[Tony Marston]

"Marcus Baker" <ma****@lastcra ft.com> wrote in message
news:41******** ******@lastcraf t.com...

Hi...

Tony Marston wrote:

http://www.tonymarston.co.uk/php-mys...d-bad-oop.html
The part I bothered reading was a bit shallow and I don't find that tone
of article useful or worth bothering with. How about you just name a
single name and save us going around in circles again.

Just step through items 1 to 17 to see people's arguments with my replies.
Your fuming about the shape example is frankly a bit silly.
No it is not. When I wanted to find out how to use OOP to build applications
to deal with common-or-garden business entities such as CUSTOMER, PRODUCT
and INVOICE I bought some books and searched the internet. What did I find?
Nothing except how to write classes dealing with shapes and producing
subclasses for 'square', 'circle' etc. There were no examples at all on how
to deal with non-graphical objects, so I had to start from a blank sheet of
paper.

No, but they would have experience of other paradigms to draw upon.

So now you have shifted the ground to people who only have one paradigm?
Hm, a slippery customer indeed. Not the argument.

When somebody makes the statement that "OOP is better than Procedural" that
begs the question - are you talking from personal experience or merely
echoing what you have been told? I have programmed in non-OO languages for
over 20 years so I have a considerable anount of personal experience - both
good and bad - to draw upon.

It is because of my
non-OO background that I can recognise where and when an OO approach may
bring benefits.

Well apparently not if you are using a more limited procedural paradigm in
the very field OO excels. Also since when is knowledge of non-OO
sufficient to recognise anything at all.

Working with non-OO languages has given me the following experiences:
- How to gather user requirements.
- How to analyse user requirements and design a solution.
- How to design the application database required for that solution.
- How to write program specifications.
- How to lead a team of programmers to implement that solution.
- How to prepare test plans.
- How to write documentation.
- How to handle unit testing, system testing, and user acceptance testing.
- How to train users in the use of the application.
- How to tell when something does not work as it should.

Is there anything I have missed out?
You need non-OO and OO knowledge and a lot more besides, such as a good
deal of case studies or experience in both.

In fact most of this knowledge already exists, but we have a lot of
developers who have been promoted to the level of project managers without
training or homework in the field. Oh great, now I'm ranting...

From your article and the thread you pointed at it seems that you were
just about to learn the very OO skills I am talking about. If you had
given it a little longer you would have got it. A shame.
I don't need to learn any skills from people like you. I have taught myself
and succeeded in producing something which:
(a) follows the principles of OOP.
(b) follows the KISS principle.
(c) works rather effectively.
(d) makes it easy to build new components.
(e) is easy to maintain.

A high-speed car in the hands of someone who is competent is perfectly
safe, while one that is in the hands of someone who is one sandwich short
of a picnic is a distaster waiting to happen. As I keep saying, it is not
the tool but the way that you use it that counts.

You seem to get confused easily. Once you learn to drive you get around
faster. Once you learn the basic OO skills you can more accurately map
business requirements to code. That's the point. You suffer the learning
process to progress long term.

Unfortunately if you are taught badly you start off with an immediate
disadvantage. It is also rare for people to recognise that they have been
taught badly and seek guidance from someone who is actually competent.

It describes the aplication of polymorphism perfectly. A code example in
UNIFACE would be totally meaningless to a non-UNIFACE programmer.

Pretty pointless example then. How about a PHP one given you are in a PHP
forum?

It is a valid example of how I achieved polymorphism in a non-OO language. I
cannot give an example in PHP for the simple reason that I achieved it using
OO techniques.
Or were you just trying to confuse the issue by choosing just about the
most obscure example possible.
I was just pointing out how polymorphism can be achieved in a non-OO
language. At least one other contributor to this thread had the ability to
recognise that.

I don't, I use a language that has those features. I don't think you are
listening.

Once a language has been chosen for a project
then it would be totally stupid to try to write code that does not fit in
with the way that language is designed to work.

I thought you you weren't listening. If I have to bend the language, that
langauge is inadequate. If I have to bend procedural into OO or
functional, then that paradigm is inadequate. Now do you see the point?

You fail to see the point. The language was chosen by the client before the
project started, yet some of the project team tried to bend that language to
make it work like a different language. They failed.

So trying to get a non-OO
language to work in an OO way is a disater waitng to happen.

Which is not the point (yet again). If you are trying to bolt OO features
onto an OO language then you should change language. If the legacy code is
too expensive to replace then you have to live with the limitations of
procedural. Hardly desirable.

It is PRECISELY the point. Once the language for the project has been chosen
you should use that language in the way it was designed to be used and not
try to force it to behave differently. The language was not object oriented,
therefore trying to force it to begave in an OO fashion was a disaster
waiting to happen. And it did.

I am being realistic. It is you who are insisting that everything OO is
good (white) while everything that is not OO is bad (black). I am simply
pointing out shades of grey.

Nope. You can solve problems with procedural if you except that you are
working under limitations.

I agree that some things can be achieved better using OO, but I also know
that some things are best left as procedural.
If you have fast changing requirements the cost to the business of
procedural developers will be much higher than simply spending on those
developers with OO skills. You won't lose anything by doing tasks in OO
instead of procedural fashion though, mostly you gain (at least in the
field of e-commerce). Procedural is just a step in the learning process.

BTW we don't emply people "one sandwich short of a picnic". Instead we
hire people who already have appropriate skills for the task or we get
people who are willing to learn. It would take a dysfunctional
organisation to do otherwise. Resorting to silly examples is rather
desperate.
Judging by the 17 criticisms contained in my article
http://www.tonymarston.co.uk/php-mys...d-bad-oop.html there are plenty of
people out there who are being taught a load of rubbish. If your programmers
cannot tell the difference between rubbish and righteous then you have a
problem but are unable (or unwilling) to see it.

Unfortunately this steep learning curve is too much of an investment for
some companies. And who do you decide is an appropriate mentor? If you
get taught the wrong ideas by the wrong people then all that investment
in switching to OO will take a very, very long time to bear fruit.

It bears fruit within a year, 3 months or less with pair programming and
the like if the skills are already in house. It's quite remarkable that
you manage to find the "wrong people" with such regularity. We have had no
such problems.

That is probably because you do not think there is such a thing as "bad"
OOP, therefore you are willing to accept any old rubbish.
I haven't seen the problems you describe in any of the last six companies
I have been involved with
Then you haven't lived. Either that or you don't have the ability to
recognise rubbish when you see it.
. More importantly I hardly hear about it at all. I think your situation is
unfortunate and exceptional if it was so disastrous. Yes, I have see people
go through a drunk on patterns stage, but it usually only lasts a few
weeks.

You are either exaggerating or the projects that have scarred you have had
many more problems than merely being OO. From your link it seems you had a
design imposed on the developers without buy in.
No. Only the language was fixed from the start. All the application
designers had to do was come up with something which could be implememnted
in that language. They failed disastrously for reasons already mentioned.
Either the skills were not there, the design was inappropriate or personal
factors got in the way. I don't see an OO problem in there, I see a people
problem.
Exactly. There was nothing wrong with the language, it was the people were
incompetent.

The problem still exists that too many programmers out there think they
are OO experts when all they can really achieve is to over complicate the
issue and produce bloated and expensive software.

As I say, the minority in my experience. If you hire a shop of all
juniors, so there are no skills to go around, then you have a disaster
waiting for happen. That is true of any paradigm or any other skill.
That's true of programming in general. The only time you can get away with
this is to have a trial project which is not mission critical and
willingness by the team to learn from their mistakes. Management don't see
it that way, so that such pilot projects are a rarity in practice.
Whatever project your on, someone in that project should have experience
of all the technical and domain skills needed.

At last there is something we agree on.

But there are plenty of other people out there who have had similar
experiences. I am simply trying to balance the argument.

You are doing nothing of the sort, you are ranting.

I am not ranting, I am simply coming up with arguments which counter the
statements you are making. You seem to dislike the fact that I have the
audacity to challenge the statement that everything OO is perfect.
You could balance the argument by saying when OO is good and when OO is
bad. You could compare it with other paradigms to show where they are more
appropriate in certain situations (functional for language processing,
logic programming for rules engines, etc, etc). You haven't.
If you want a comparison between OO and procedural then take a look at
http://www.geocities.com/tablizer/oopbad.htm
I am quite happy to argue the pros and cons of different systems of
development. I know nothing of Uniface for instance and it would be nice
to know how that works out in practice. I would also like to know more
about your failed projects as case studies are always useful.
Then take a look at
http://www.marston-home.demon.co.uk/...disasters.html
This industry doesn't make the efforts it should to learn from each other.

Unfortunately such one sided rants mean that I cannot trust any
information you now actually put out. You tarnish your own reputation with
polemics.

I am not ranting, I am simply disagreeing with you. I will keep disagreeing
with you until hell freezes over.

--
Tony Marston

http://www.tonymarston.net