OOP leads to lousy websites?

[Chung Leong]

There has been a number of threads in this newsgroup concerning OOP and PHP.
Usually people just debate on which language is more (or less) OOP than
others. The merit of OOP in the web-programming context is rarely addressed.
So let me pose this question: Are websites built based on OOP principles
inherently less stable than those built "procedural ly?" By "less stable" I
mean stability for the same amount of programming effort.

I'm incline to think it's true. Take string-handling. To get the length of a
string procedurally, you do strlen($s), while in OOP you would do
$s->Length() where $s is an instance of a string class. Now, if $s is null,
in the first case the function just returns zero, whereas in the second case
your page fails catastrophicall y.

[Tom Thackrey]

Re: OOP leads to lousy websites?


On 18-Feb-2004, "Chung Leong" <chernyshevsky@ hotmail.com> wrote:
[color=blue]
> There has been a number of threads in this newsgroup concerning OOP and
> PHP.
> Usually people just debate on which language is more (or less) OOP than
> others. The merit of OOP in the web-programming context is rarely
> addressed.
> So let me pose this question: Are websites built based on OOP principles
> inherently less stable than those built "procedural ly?" By "less stable" I
> mean stability for the same amount of programming effort.
>
> I'm incline to think it's true. Take string-handling. To get the length of
> a
> string procedurally, you do strlen($s), while in OOP you would do
> $s->Length() where $s is an instance of a string class. Now, if $s is
> null,
> in the first case the function just returns zero, whereas in the second
> case
> your page fails catastrophicall y.[/color]

Actually, to take the length of a string in OOP you would use strlen(), to
get the length of a String object you would use $s->length() or whatever.

OOP is a way of thinking about problems. Programmers were using OO
principles long before the first OO language. (C++ started as a pre-compiler
for C.)

The quality of the product is directly related to the quality of the design
and implementation. The language choice and even the methodology are
secondary. I've seen extraordinary programs written in assembler, Fortran,
and COBOL as well as crap written in Java, C++ etc.

Worry more about design and less about what language.



--
Tom Thackrey

https://www.creative-light.com

tom (at) creative (dash) light (dot) com
do NOT send email to jamesbutler@wil lglen.net (it's reserved for spammers)

[CountScubula]

Re: OOP leads to lousy websites?

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:WMKdnUm1CZ FbjqndRVn-gg@comcast.com. ..[color=blue]
> There has been a number of threads in this newsgroup concerning OOP and[/color]
PHP.[color=blue]
> Usually people just debate on which language is more (or less) OOP than
> others. The merit of OOP in the web-programming context is rarely[/color]
addressed.[color=blue]
> So let me pose this question: Are websites built based on OOP principles
> inherently less stable than those built "procedural ly?" By "less stable" I
> mean stability for the same amount of programming effort.
>
> I'm incline to think it's true. Take string-handling. To get the length of[/color]
a[color=blue]
> string procedurally, you do strlen($s), while in OOP you would do
> $s->Length() where $s is an instance of a string class. Now, if $s is[/color]
null,[color=blue]
> in the first case the function just returns zero, whereas in the second[/color]
case[color=blue]
> your page fails catastrophicall y.
>
>[/color]

Personaly, and this is just me, and I not trying to convince anyone.

I feel oop programming in web scripting, should not be done, unless needed,
ie,redistributi ng, collabtitave works, etc..

scripting to me, is a bare stripped down enviroment, and the overhead due to
OOP, does not belong there.

IE:

$len = strlen($myStrin g)

is same as defining an object, and in that object calling the same function
strlen to get the length of the string, too much overhead, again, just my
opinion.

I like OOP programming when I do certain compiled languages, but there when
I create an object, it is used for the life of the application, where as
scripting, it is read, built/interpeted/complied, then ran, then killed. and
this happens over and over for every web request.

Now on simple little sites, fewer than 1000 visitors a day, who cares, but
when you have 10,000 visitors a day, and the over head of OOP leads to only
a .01 second over head, no big deal right? wrong, total that up and you get
100 seconds of delay with 10,000 users. (flammers hold on, I now there is
more involved, but i am simplfying it)

I rarely use OOP in scripting, becouse I like to keep scripts simple, top
down, small, and fast.

Now OOP in PHP can be very usefull for building say images, graphs, zips,
etc. makes it easier for one to distrubute thier piece of code.

Ok, I am done rambling,

--
Mike Bradley
http://www.gzentools.com -- free online php tools

[rush]

Re: OOP leads to lousy websites?

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:WMKdnUm1CZ FbjqndRVn-gg@comcast.com. ..[color=blue]
> There has been a number of threads in this newsgroup concerning OOP and[/color]
PHP.[color=blue]
> Usually people just debate on which language is more (or less) OOP than
> others. The merit of OOP in the web-programming context is rarely[/color]
addressed.[color=blue]
> So let me pose this question: Are websites built based on OOP principles
> inherently less stable than those built "procedural ly?" By "less stable" I
> mean stability for the same amount of programming effort.
>
> I'm incline to think it's true. Take string-handling. To get the length of[/color]
a[color=blue]
> string procedurally, you do strlen($s), while in OOP you would do
> $s->Length() where $s is an instance of a string class. Now, if $s is[/color]
null,[color=blue]
> in the first case the function just returns zero, whereas in the second[/color]
case[color=blue]
> your page fails catastrophicall y.[/color]

I do not think website app programming is very different from any other kind
of programming, so if you find OO a good way to program in general, you
would also find it to be a good way to develop web apps. And other way
around, if have never felt comfortable with OO, you will also probably
incline to use procedural programming for web sites.

as for reliability, for me OO makes it easier to make code of better quality
and more robust. But that's just my experience. With OO, as with any other
programming approach you need to have a good measure for it and approach.
But if you use it just because you have to, you usually get very bad
results.

rush
--

http://www.templatetamer.com/

[Berislav Lopac]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
> There has been a number of threads in this newsgroup concerning OOP
> and PHP. Usually people just debate on which language is more (or
> less) OOP than others. The merit of OOP in the web-programming
> context is rarely addressed. So let me pose this question: Are
> websites built based on OOP principles inherently less stable than
> those built "procedural ly?" By "less stable" I mean stability for the
> same amount of programming effort.
>
> I'm incline to think it's true. Take string-handling. To get the
> length of a string procedurally, you do strlen($s), while in OOP you
> would do $s->Length() where $s is an instance of a string class. Now,
> if $s is null, in the first case the function just returns zero,
> whereas in the second case your page fails catastrophicall y.[/color]

OOP is really (in any language, although some give you no alternatives) just
a way to organize your code, and nothing more.

When you think of it, the actual programming is done with only a very small
subset of actual commands in any (high-level) programming languages: not
much more than numerical operators, assignments, if-switches and for loops.
Everything else, from simple ++ and ternary operators, switch statements and
while and other loops, to functions and eventually to objects and methods,
is just tools that make programmer's job easier by helping him reuse the
code and reduce the number of possible problems.

In the end, it all comes down to how good you are in organizing your code.
In the example above, there is no reason why would $s->Length() make the
page fail catastrophicall y -- you can write it so that the Length() method
also returns a zero. Also, if the strlen is called from another custom which
fails to return zero when strlen returns one to it, the page can fail
catastrophicall y just the same.

Imagine that there is *no* functions in PHP. No strlen, no in_array,
nothing. Would we be able to program with it just as we do now? Of course,
except that all those useful functions that are precompiled into it will
have to be re-written from scratch using simple operators and if-statements.
In any language, its strength comes primarily in the scope of the code
library which comes with it, and this is especially true of PHP. And this is
true not only for functions, but also for objects, except that here the
library we get with the language is not nearly that extensive. Some
languages, like Java, provide you with a myriad of prepared classes and
objects and interfaces and methods which you can use in your program out of
the box; if they were not there, you would have to write them yourself.

And when you write your own library -- either procedural (functions) or OO
(objects, methods...) -- it is exclusively up to the programmer to cover all
possible incomes and returns to prevent the library from acting
unpredictably. You need to know what objects there might exist in your
application and what functions they might perform, just as you need to know
which chunk of procedural code could become a good function, or whether
there are several functions hiding one inside another.

Some people find it easier to think procedurally, and others find it more
productive to use object-oriented approach; it all comes down to the code
organization.

Berislav

--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.

[Andy Jeffries]

Re: OOP leads to lousy websites?

CountScubula wrote:[color=blue]
> Personaly, and this is just me, and I not trying to convince anyone.
>
> I feel oop programming in web scripting, should not be done, unless needed,
> ie,redistributi ng, collabtitave works, etc..[/color]

Or large projects...
[color=blue]
> I like OOP programming when I do certain compiled languages, but there when
> I create an object, it is used for the life of the application, where as
> scripting, it is read, built/interpeted/complied, then ran, then killed. and
> this happens over and over for every web request.[/color]

But it can be stored across page accessing in $_SESSION.
[color=blue]
> Now on simple little sites, fewer than 1000 visitors a day, who cares, but
> when you have 10,000 visitors a day, and the over head of OOP leads to only
> a .01 second over head, no big deal right? wrong, total that up and you get
> 100 seconds of delay with 10,000 users. (flammers hold on, I now there is
> more involved, but i am simplfying it)[/color]

BUt that's 100 seconds of delay spread over 10,000 users or still .01
second over head per user. That's not a flame, it's just your point is
either wrong or incorrectly stated.
[color=blue]
> I rarely use OOP in scripting, becouse I like to keep scripts simple, top
> down, small, and fast.[/color]

For small sites I agree. For large sites, they can be easier to
maintain using classes.
[color=blue]
> Now OOP in PHP can be very usefull for building say images, graphs, zips,
> etc. makes it easier for one to distrubute thier piece of code.
>
> Ok, I am done rambling,[/color]

And why, not it's good fun to have rambling conversations.. .

Cheers,


Andy

[CountScubula]

Re: OOP leads to lousy websites?

Perhaps I did mistate the whole 100 seconds via 10,000 visits/.01sec delay.

More of the effect if you tend to have a lot of hits at one time (generaly
if you have 10,000 visits in a day, that well over 50,000 hits).

So if you have many hits at same time, then the .01 delay becomes slightly
more becouse durring this time, cpu cycles is limited, and then spread
across more proccess, also, if you have lots of visits, your server might
delay a connection here or there becouse it reaches its max
threads/children, the faster a script can be built up / torn down, then the
more free the server will be.

Again, I ramble, it is 3:00am for me, and I have a plane to catch at 6:00am,
and If I go to sleep, there will be no chance of waking up.


--
Mike Bradley
http://www.gzentools.com -- free online php tools
"Andy Jeffries" <newnews@seirff ej.reverse.prev ious.word.co.uk > wrote in
message news:1077187585 .26010.0@ersa.u k.clara.net...[color=blue]
> CountScubula wrote:[color=green]
> > Personaly, and this is just me, and I not trying to convince anyone.
> >
> > I feel oop programming in web scripting, should not be done, unless[/color][/color]
needed,[color=blue][color=green]
> > ie,redistributi ng, collabtitave works, etc..[/color]
>
> Or large projects...
>[color=green]
> > I like OOP programming when I do certain compiled languages, but there[/color][/color]
when[color=blue][color=green]
> > I create an object, it is used for the life of the application, where as
> > scripting, it is read, built/interpeted/complied, then ran, then killed.[/color][/color]
and[color=blue][color=green]
> > this happens over and over for every web request.[/color]
>
> But it can be stored across page accessing in $_SESSION.
>[color=green]
> > Now on simple little sites, fewer than 1000 visitors a day, who cares,[/color][/color]
but[color=blue][color=green]
> > when you have 10,000 visitors a day, and the over head of OOP leads to[/color][/color]
only[color=blue][color=green]
> > a .01 second over head, no big deal right? wrong, total that up and you[/color][/color]
get[color=blue][color=green]
> > 100 seconds of delay with 10,000 users. (flammers hold on, I now there[/color][/color]
is[color=blue][color=green]
> > more involved, but i am simplfying it)[/color]
>
> BUt that's 100 seconds of delay spread over 10,000 users or still .01
> second over head per user. That's not a flame, it's just your point is
> either wrong or incorrectly stated.
>[color=green]
> > I rarely use OOP in scripting, becouse I like to keep scripts simple,[/color][/color]
top[color=blue][color=green]
> > down, small, and fast.[/color]
>
> For small sites I agree. For large sites, they can be easier to
> maintain using classes.
>[color=green]
> > Now OOP in PHP can be very usefull for building say images, graphs,[/color][/color]
zips,[color=blue][color=green]
> > etc. makes it easier for one to distrubute thier piece of code.
> >
> > Ok, I am done rambling,[/color]
>
> And why, not it's good fun to have rambling conversations.. .
>
> Cheers,
>
>
> Andy[/color]

[Tim Tyler]

Re: OOP leads to lousy websites?

Chung Leong <chernyshevsky@ hotmail.com> wrote or quoted:
[color=blue]
> Are websites built based on OOP principles inherently less stable than
> those built "procedural ly?" By "less stable" I mean stability for the
> same amount of programming effort.
>
> I'm incline to think it's true. Take string-handling. To get the length of a
> string procedurally, you do strlen($s), while in OOP you would do
> $s->Length() where $s is an instance of a string class. Now, if $s is null,
> in the first case the function just returns zero, whereas in the second case
> your page fails catastrophicall y.[/color]

....making it much easier to identify the presence of the problem and
to locate the source of it during testing - thus saving on debugging time.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

[Andy Jeffries]

Re: OOP leads to lousy websites?

CountScubula wrote:[color=blue]
> Perhaps I did mistate the whole 100 seconds via 10,000 visits/.01sec delay.
>
> More of the effect if you tend to have a lot of hits at one time (generaly
> if you have 10,000 visits in a day, that well over 50,000 hits).[/color]

I agree with what you are saying.
[color=blue]
> So if you have many hits at same time, then the .01 delay becomes slightly
> more becouse durring this time, cpu cycles is limited, and then spread
> across more proccess, also, if you have lots of visits, your server might
> delay a connection here or there becouse it reaches its max
> threads/children, the faster a script can be built up / torn down, then the
> more free the server will be.[/color]

I'm working on a site that currently does 40,000-90,000 page impressions
per day and there are quite a few objects on the site and it responds
very quickly (even though it's hosted in the states and it links to
various Ad providers).

What I would say is : Objects obviously have their place in speed of
development/ease of maintenance for large sites. If your site is slow,
look at optimising it - but do it sensibly. Measure how long your
queries take, measure how long your slowest pages are and where it
spends most of the execution time.

I bet object construction/usage are no-where near the top of the
optimisation pile....
[color=blue]
> Again, I ramble, it is 3:00am for me, and I have a plane to catch at 6:00am,
> and If I go to sleep, there will be no chance of waking up.[/color]

Hey man, I'll help you stay awake with this rambling conversation if it
helps....

Cheers,


Andy

[Andy Jeffries]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
> So let me pose this question: Are websites built based on OOP principles
> inherently less stable than those built "procedural ly?" By "less stable" I
> mean stability for the same amount of programming effort.[/color]

I'll shove in my 2p-worth. I think the answer is no and generally the
opposite is true. By following good OO design principles (objects do
one thing and do it well) you can build a more robust system as each
object is developed, tested then can be forgotten about.
[color=blue]
> I'm incline to think it's true. Take string-handling. To get the length of a
> string procedurally, you do strlen($s), while in OOP you would do
> $s->Length() where $s is an instance of a string class. Now, if $s is null,
> in the first case the function just returns zero, whereas in the second case
> your page fails catastrophicall y.[/color]

I'm not an OO purist, but I do think for relatively large sites OO can
help keep the system clean and easy to maintain.

I don't think you need a string object any more than you need an integer
object.

I think PHP achieves a mix of structured and OO programming with
unparalled excellence....

Cheers,


Andy

[Bruno Desthuilliers]

Re: OOP leads to lousy websites?

Andy Jeffries wrote:
(snip the rest, on which I globally agree !-)
[color=blue]
> I think PHP achieves a mix of structured and OO programming with
> unparalled excellence....[/color]

<not-trolling>
Err... The lack of support for modularity (except when using OO) and
exception handling is IMHO not a sign of 'unparalled excellence'. I
think that this qualification would be better applied to Python (then
you could even add functional programming to the mix).
</not-trolling>

Just my 2 cents...
Bruno

[Andy Jeffries]

Re: OOP leads to lousy websites?

Bruno Desthuilliers wrote:[color=blue]
> (snip the rest, on which I globally agree !-)[/color]

Jolly good... :-)
[color=blue][color=green]
>> I think PHP achieves a mix of structured and OO programming with
>> unparalled excellence....[/color]
>
> <not-trolling>
> Err... The lack of support for modularity (except when using OO) and
> exception handling is IMHO not a sign of 'unparalled excellence'. I
> think that this qualification would be better applied to Python (then
> you could even add functional programming to the mix).
> </not-trolling>[/color]

<joking trolling>
Yeah, but I don't like the idea of programming in languages where
indentation affects how the program runs.
</joking trolling>

In all seriousness, I've tried looking at Python (most recently since
Nokia announced Python would be release for my 3650) but I just can't
seem to get on with it - it looks ugly :-)


Cheers,


Andy

[Chung Leong]

Re: OOP leads to lousy websites?

Uzytkownik "Berislav Lopac" <berislav.lopac @dimedia.hr> napisal w wiadomosci
news:c11t86$8o2 $1@ls219.htnet. hr...[color=blue]
> Chung Leong wrote:
> OOP is really (in any language, although some give you no alternatives)[/color]
just[color=blue]
> a way to organize your code, and nothing more.
>
> ...[/color]

I see my original post didn't make clear what I have in mind. The issue in
question isn't OO programming in general, but OO in the specific context of
web-programming in real-world situations, where applications mainly performs
databases operations and generate HTML, and where projects must be completed
in a given time-frame. Let me thus refine my question:

Is the OOP approach more error-prone and does it requires more coding for
typical web-programming tasks?

Time here is the key. The more time it takes to implement a given set of
functionalities , the less time you have to polish the code and the less time
there is to test. Irregardless of programming technique, an untested
application is a buggy application. It doesn't help, of course, if a
particular technique is more error-prone than others.

The point of my example is that an OO approach requires additional coding to
keep a catastrophic failture from happening. Length() cannot simply return
0, as you said, because the method never gets called when $s is null. With
strlen(), at least the function gets a chance to handle the erroreous
condition in a reasonable manner.

[Tom Thackrey]

Re: OOP leads to lousy websites?


On 19-Feb-2004, "Chung Leong" <chernyshevsky@ hotmail.com> wrote:
[color=blue]
> Uzytkownik "Berislav Lopac" <berislav.lopac @dimedia.hr> napisal w
> wiadomosci
> news:c11t86$8o2 $1@ls219.htnet. hr...[color=green]
> > Chung Leong wrote:
> > OOP is really (in any language, although some give you no alternatives)[/color]
> just[color=green]
> > a way to organize your code, and nothing more.
> >
> > ...[/color]
>
> I see my original post didn't make clear what I have in mind. The issue in
> question isn't OO programming in general, but OO in the specific context
> of
> web-programming in real-world situations, where applications mainly
> performs
> databases operations and generate HTML, and where projects must be
> completed
> in a given time-frame. Let me thus refine my question:
>
> Is the OOP approach more error-prone and does it requires more coding for
> typical web-programming tasks?
>
> Time here is the key. The more time it takes to implement a given set of
> functionalities , the less time you have to polish the code and the less
> time
> there is to test. Irregardless of programming technique, an untested
> application is a buggy application. It doesn't help, of course, if a
> particular technique is more error-prone than others.
>
> The point of my example is that an OO approach requires additional coding
> to
> keep a catastrophic failture from happening. Length() cannot simply return
> 0, as you said, because the method never gets called when $s is null.
> With
> strlen(), at least the function gets a chance to handle the erroreous
> condition in a reasonable manner.[/color]

Your example is too trivial. Plus the error you avoid is essentially using
an undeclared variable. I'd rather have it fail catastrophicall y than
subtly.

In general, OOP offers the opportunity to build tested, reusable 'modules'
which can be used to simplify DB access, HTML generation, etc. For anything
but the most trivial application, OOP should be an advantage.


--
Tom Thackrey

https://www.creative-light.com

tom (at) creative (dash) light (dot) com
do NOT send email to jamesbutler@wil lglen.net (it's reserved for spammers)

[Henk Verhoeven]

Re: OOP leads to lousy websites?

Chung Leong wrote:[color=blue]
>(..)
>
> I'm incline to think it's true. Take string-handling. To get the length of a
> string procedurally, you do strlen($s), while in OOP you would do
> $s->Length() where $s is an instance of a string class. Now, if $s is null,
> in the first case the function just returns zero, whereas in the second case
> your page fails catastrophicall y.[/color]

That depends on the exception handling. With try catch like in Java, C++
and php5, you can handle the the error and continue after the error
handler.

BTW, without implicit type conversion strlen(null) would have failed
too, or maybe caused a warning and returned null instead of null, which
without implicit type conversion will probably cause more problems later
on. I don't see why implicit type conversion would not be possible with
objects. In case of null->length() null could be converted to a String,
assuming the length method is only defined on String. But of course
defining length on the class of null would be more OOP ;-)

Henk Verhoeven.