OO in PHP

[Mudge]

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

[Marcus Baker]

Hi...

Tony Marston wrote:

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.
Having learned the basic syntax of OO you didn't find out about the very
large subject of enterprise patterns then? Plenty of examples there.
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?
Both. Because I can do both.
Working with non-OO languages has given me the following experiences:
These are all lifelong skills, not boxes that you tick. Guess what? I
could tick all of those as well. Meaningless.
- How to tell when something does not work as it should.
Er...nevermind.

Is there anything I have missed out?
How to learn from others.
How to resolve an argument to a conclusion.
(a) follows the principles of OOP.
Only at the most superficial level and then only occasionally.
(b) follows the KISS principle.
200K+ sample application that displays the results of four database
tables is not KISS.
(c) works rather effectively.
Not if you are the only ones that understands it.
(d) makes it easy to build new components.
Your idea of a componnet is everybody else's idea of a simple cut and
paste script. You need 11 such cut and paste operations just to handle
one table.
(e) is easy to maintain.
Only if cut and paste hell counts as easy to maintain. This is it's
biggest weakness.
It is also rare for people to recognise that they have been
taught badly and seek guidance from someone who is actually competent.
Which you avoid by being taught by nobody. Hm...interestin g.
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.
You can achieve polymorphism in a functional language. Why? because it
is built in. As I don't know anything of UNIFACE I don't know what
features were used. I therefore cannot validate your claim of
polymorphism. Thus in this context it is irrelevant. You could have
posted a PHP snippet for example instead.
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.
You can achieve polymorphism in a lot of langauges, even XSLT. The fact
that you have to jump through hoops to do it would suggest changing to a
language that supports it would be better. Haskell and Scheme for
example. The counter case is that the skills may be sufficiently rare
that mangling XSLT may be the better, but stillpainful, option.
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.
But I have just said that bending the language is undesirable. If the
developers were not familiar with the language and it was forced on them
then that's a management issue.
The language was not object oriented,
therefore trying to force it to begave in an OO fashion was a disaster
waiting to happen.
Trying to say OO is wrong because someone once tried to do OO in the
wrong language is a straw man argument. That is not a fair comparison
between OO and non-OO techniques.
I agree that some things can be achieved better using OO, but I also know
that some things are best left as procedural.
Like? In the field of enterprise web apps, a target audience for PHP
right now, yes I do say it's superior. I believe that this is a good
career path for developers who want to stick with PHP and web
development. It's worth the effort to learn.
If your programmers
cannot tell the difference between rubbish and righteous then you have a
problem but are unable (or unwilling) to see it.
We hire people who manage that just fine thanks. And we go a lot quicker
than six cut and paste scripts an hour.
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.
Well I am rejecting your library for a start.
Then you haven't lived. Either that or you don't have the ability to
recognise rubbish when you see it.
I have seen bad OO along with bad programming. We fix it and train
people to get better. Mentoring is a wonderful thing. I certainly
haven't encountered a shop where the whole organisation is drowning in
the mess you described. As I say, I think there is a sickness in that
organisation. That's the kind of organisation I avoid.
Exactly. There was nothing wrong with the language, it was the people were
incompetent.
If the skills were not there and this was not remedied then that is a
management problem. If the developers misrepresented themselves in their
skills or claims then that is a more serious issue of professional
misconduct. I find nothing specific to OO in your claims.
You seem to dislike the fact that I have the
audacity to challenge the statement that everything OO is perfect.
As I have never claimed OO is "perfect" your statement has no basis. I
am quite willing to thrash out the arguments until something emerges.
Blind contradiction has no interest for me.
Then take a look at
http://www.marston-home.demon.co.uk/...disasters.html
Ok, that is actually a useful run down. One sided, but that's
inevitable. Still that is a piece of excellent work. Well done.
I am not ranting, I am simply disagreeing with you. I will keep disagreeing
with you until hell freezes over.

Which is why I am so bored with you. I don't have an obligation to help
you improve. You can stay at this stage forever for all I care.

I am sure you will be relieved to hear that this will be my last
communication with you.

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:

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.
Having learned the basic syntax of OO you didn't find out about the very
large subject of enterprise patterns then? Plenty of examples there.

I looked at articles about design patterns on the web. I even bought 2
books. That was of little use as most of the examples given were (a) in a
language other than PHP, and (b) unsuitable for a web environment. The
significant point to note about design patterns is that they are merely
outlines of solutions with no particular implementation, there is no single
implementation which is all things to all men.

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?

Both. Because I can do both.

Good for you. But how many others out there who keep shouting "OOP is best,
procedural is worst!" can say the same thing?

Working with non-OO languages has given me the following experiences:

These are all lifelong skills, not boxes that you tick. Guess what? I
could tick all of those as well. Meaningless.

I disagree. It means that I have learned skills which are still relevant in
the world of OOP.

- How to tell when something does not work as it should.

Er...nevermind.

Have you ever been given a program to test that was written by someone who
thought he knew all the right buzzwords, all the 'cool' design patterns? In
his mind it must be perfect because he did it the *right* way, but when you
get to look at it you can see immediately that it sticks out like a sore
thumb when compared to the rest of the system. The interface may be too
clunky, the performance may be too slow, whatever. In theory it should be
perfect, but in practice it is not. You can only tell that it is not "good
enough" when you have solid experience and can make comparisons with other
pieces of successful software.

Is there anything I have missed out?

How to learn from others.

I can only "learn" from others when they have something usefull to "teach".
Just voicing the opinion that their style is superior to mine is just not
good enough. I want proof, I want concrete evidence, and so far no such
evidence has been forthcoming.
How to resolve an argument to a conclusion.
An argument cannot be concluded until unsubstantiated opinions can be backed
up with conclusive proof. You and your colleagues have provided no such
proof.

(a) follows the principles of OOP.

Only at the most superficial level and then only occasionally.

I follow the basic principes of OOP which are (a) encapsulation, (b)
inheritance and (c) polymorphism. That is enough. Everything else is just a
later addition that individuals are free to adopt or ignore at their own
discretion.

(b) follows the KISS principle.

200K+ sample application that displays the results of four database tables
is not KISS.

If you look at the database schema you will see that there are seven tables,
not four, and they are all connected via various relations. There is
one-to-many, many-to-many, and even a table that is related to itself.

(c) works rather effectively.

Not if you are the only ones that understands it.

Say that to the peolpe who email me to say that they find my arcticles and
my sample code both refreshingly different and easy to understand, unlike
most of the stuff they find on the web.

(d) makes it easy to build new components.

Your idea of a componnet is everybody else's idea of a simple cut and
paste script.

And what's wrong with cut and paste? This has been a recognised technique
since before I started programming in the mid 1970s. There is a saying in
the COBOL world that nobody ever writes more than one program from scratch.
All the others are simply copies which are then amended until the desired
result is achieved.
You need 11 such cut and paste operations just to handle one table.
Wrong. Those 11 components actually maintain 3 tables which are used to
contain the flexible tree structure described in
http://www.tonymarston.co.uk/php-mys...structure.html

(e) is easy to maintain.

Only if cut and paste hell counts as easy to maintain. This is it's
biggest weakness.

Or its biggest strength. The only alternative to cut and paste is to rewrite
everything from scratch each time. If that is your preferred methodology
then go ahead, I'm not stopping you.

It is also rare for people to recognise that they have been taught badly
and seek guidance from someone who is actually competent.

Which you avoid by being taught by nobody. Hm...interestin g.

I have bought nearly a dozen different books on PHP hoping to learn from the
sample code they contain. I have downloaded various bits and pieces from the
internet so that I can run it, examine it and see how it works. I have taken
all this external knowledge, mixed it with my own experiences, and built
myself a web application the cornerstone of which is a core infrastructure
which contains a large amount of reusable code. A small sample applicaton is
availoable on my website, but my larger application is built around a
sophiscated Role Based Access Control (RBAC) system (refer to
http://www.tonymarston.co.uk/php-mys...-control.html), an
Audit Logging system with an online viewing facility (refer to
http://www.tonymarston.co.uk/php-mysql/auditlog.html) and an activity based
Workflow Engine (refer to
http://www.tonymarston.co.uk/php-mysql/workflow.html).

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.

You can achieve polymorphism in a functional language. Why? because it is
built in. As I don't know anything of UNIFACE I don't know what features
were used. I therefore cannot validate your claim of polymorphism. Thus in
this context it is irrelevant. You could have posted a PHP snippet for
example instead.

There are working examples in that sample application of mine, but for the
benefit of other readers of this post I shall give an explanation.

I have objects for entities called Person, Option and Tree-Type. In order to
provide methods to read, insert, update and delete from these entities there
are two basic approaches:
(1) Have methods which include the entity name, as in
- getPerson(), insertPerson(), updatePerson(), deletePerson()
- getOption(), insertOption(), updateOption(), deleteOption()
- getTreeType(), insertTreeType( ), updateTreeType( ), deleteTreeType( )
(2) Have methods which exclude the entity name, as in
- getData(), insertRecord(), updateRecord(), deleteRecord()

Option (1) does not demonstrate polymorphism as the getPerson() method
cannot be used on the Option obect or the Tree-Type object, r any object
other tha Person.

Option (2) demonstrates methods which can be used on any object. The
advantage of this is that the controller - the component which communicates
with these various objects - does not need to know which object it is
dealing with as the methods (functions) it uses will work on any object.
This in turn means that I do not have to have a separate controller for each
object as a generic controller is able to work with any object.

Is that explanation good enough? Or are you going to find a reason why that
is wrong too?

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.

But I have just said that bending the language is undesirable. If the
developers were not familiar with the language and it was forced on them
then that's a management issue.

The situation was worse than you think. Two of the team had experience with
version 6 of the language, not version 7. Two of the team were consultants
from the company which owned the language, therefore they were supposed to
be experts. The remaining two were fresh out of university, therefore knew
nothing about anything.

The two with experience of version 6 had no idea about the capabilities of
the significant changes with version 7 other than what they had read. The
two consultants who were supposed to be experts had not actually used the
language much to write end-user applications, they had simply worked on the
internals which were written entirely in C. This meant that they were
experts in C programming, not UNIFACE programming. Together they designed an
infrastructure which may have worked with the C language but which was
totally inappropriate with the UNIFACE language.

The language was not object oriented, therefore trying to force it to
begave in an OO fashion was a disaster waiting to happen.

Trying to say OO is wrong because someone once tried to do OO in the wrong
language is a straw man argument. That is not a fair comparison between OO
and non-OO techniques.

I am not saying that all OOP is bad because that attempt at OOP was a
disaster. I am saying that trying to force any language to work in an
unatural way is a recipe for disaster. If I took an OO language and tried to
get it to work in a procedural way and it failed, would that mean that the
whole procedural paradigm was a disater? Or that particular language was a
disaster because it could not cope? No I am not. Simple commonsense says
that if you want to use OOP then yoiu use a language that supports OOP. If
you want to write procedural then use a language that supports procedural.
If you want to write around events then use an event-driven language.

That is one of the benefits of PHP - you can use a mixture of procedural and
OOP because the language supports both.

I agree that some things can be achieved better using OO, but I also know
that some things are best left as procedural.

Like? In the field of enterprise web apps, a target audience for PHP right
now, yes I do say it's superior. I believe that this is a good career path
for developers who want to stick with PHP and web development. It's worth
the effort to learn.

Taking a single stand-alone function and wrapping it with class functionX
(...) is not some people's idea of "proper" OO.

If your programmers cannot tell the difference between rubbish and
righteous then you have a problem but are unable (or unwilling) to see
it.

We hire people who manage that just fine thanks. And we go a lot quicker
than six cut and paste scripts an hour.

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.

Well I am rejecting your library for a start.

Fine. You obviously don't like my style of development, which is your right.
I am not saying that my style is the best, just that it is different. I am
not saying that your style is crap, just that it is different. I am sure
that other programmers out there have developed even more styles which suit
their particular way of working. That is their right. So we all have
different styles? So what? There is no rule that says we must all follow the
same style whether we like it or not, which is why I object to your tone
which seems to be saying "What you have done is different, and we - the OO
police- do not like it. You must either conform to our way, the one true
way, or forever be branded as a heretic and be cast into purgatory".

<snip>

You seem to dislike the fact that I have the audacity to challenge the
statement that everything OO is perfect.

As I have never claimed OO is "perfect" your statement has no basis. I am
quite willing to thrash out the arguments until something emerges. Blind
contradiction has no interest for me.

Then take a look at
http://www.marston-home.demon.co.uk/...disasters.html

Ok, that is actually a useful run down. One sided, but that's inevitable.
Still that is a piece of excellent work. Well done.

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

Which is why I am so bored with you. I don't have an obligation to help
you improve. You can stay at this stage forever for all I care.

I am willing to learn if you are able to teach. So far you have done nothing
but dictate.
I am sure you will be relieved to hear that this will be my last
communication with you.

I am so pleased.

--
Tony Marston

http://www.tonymarston.net