Re: OOP slow -- am I an idiot?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, October 11, 2006 3:28 pm, Stut wrote:
> Richard Lynch wrote:
>> On Tue, October 10, 2006 6:14 pm, Chris de Vidal wrote:
>>> I want to create a "customer" class which fetches its attributes
>>> from
>>> a MySQL database.
>>
>> No, you don't. :-)
>>
>> This is a classic example of the "obvious" OOP solution being wildly
>> inappropriate.
>
> Ok, so I now find myself in the unusual position of disagreeing with
> the
> Lynchmeister. Why is this wildly inappropriate? IMHO this is what OOP
> is
> all about.
>
> You can encapsulate everything to do with a customer in an object.
> This
> ensures that you don't duplicate any code that works on customer data.
> You avoid duplication of code. As a result you can ensure data
> integrity
> because there is only one route to read and write it.
>
> If this is not what you think OOP is all about, do please enlighten us
> as to the error of our ways.

Doing this without some kind of cache or some kind of "bulk load" of
multiple customer data is inevitably going to lead to having a zillion
"customer" instances floating around in one script to calculate
something not readily expressed in an SQL aggregate.

See other thread regarding 100 orders with all related uploaded files
for an example.

It's not so much that having a "customer" object is wrong, as that
having ONLY a "customer" object to deal with an application that deals
with MUCH MORE than a single customer at a time is wrong.

You're going to end up having a TON of duplicate code for a single
customer and multiple customers, or you're going to swamp your machine
with way too many instances of a do-nothing object for the sake of
being "OOP"

And, in point of fact, unless you spend the majority of your
time/energy in your application dealing with one customer at a time,
it's quite likely that your one customer at a time can be encapsulated
in a much more re-usable generalized notion of a "set" of customers --
albeit a set with only one element, and with a few specialized
functions for certain operations with only work for one-element sets.

Objectifying "customer" is the immediate, obvious, and totally
inappropriate solution to needing to deal with not just one customer,
but with sets of customers, some of which may, or may not, need
special handling for a set with one element.

This is merely the most obvious example of what is *probably* the
needs of the original poster.

One problem with OOP is that you really do need to understand very
very very well the full scale and scope of your application before you
can architect the appropriate OOP model.

Its entirely possible that he does not need sets of customers, but
needs some OTHER OOP model -- And there's no way to know without
knowing the full scope of the project.

You can do a bunch of simple object stuff in an iterative design,
scale, scope interaction for rapid prototyping, but you have to be
prepared to scrap all that code once you figure out what you REALLY
wanted to do for your application, and you build the REAL application
with the correct OOP model.

Some Free Advice for a beginning OOP scripter.

#1. Play around a lot with OOP on some non-mission-critical toy
projects to get the feel of it.  Build the smallest silliest OOP thing
you can think of, and push the limits of class inheritence and how the
pieces can be fit together in unusual ways.

#2. Don't use a 'class' in a real project until you find yourself
typing code that does almost the same thing as code you typed before,
only it's just enough different to make an include or function
unwieldy.  At that juncture in time, figure out how you could relate
the code you are typing NOW to the old code, and what common
components you can abstract out to a "base class" and which parts are
"specializations" of the "base class".  Re-code both chunks of code as
OOP.  *THAT* is the real power of OOP.

Don't get me wrong:  There are some other other uses of OOP, such as a
substitute for namespaces for code for public release.  But the
"obvious" one-to-one mapping of real-world things to OOP classes
seldom works out very well, unless your whole application is all about
exploring/defining the relationships among those objects, rather than
doing something complex with those objects.

I *still* don't see OOP as a Right Answer for spitting out HTML web
pages in optimized minimalist time frames...

Maybe my brain just got warped by all that AI/Lisp work I did for a
couple decades, but it feels to me like a bad selection of weapons for
the task at hand, most times I see it in PHP. [shrug]

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux