Roman Neuhauser wrote:
# stuttle@xxxxxxxxx / 2006-10-11 21:28:36 +0100:
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.
No, that's what trivial OOP examples applied to the letter where
a different approach is in order are. If you study the GoF book [GoF]
you'll see that the traditional claim "objects model physical
entities from real world (and nothing else)" is very simplistic
and terribly limiting.
[GoF] http://www.amazon.com/dp/0201633612/
If you paint yourself into this corner you'll find your code
grinding the database to death in the OO-relational impedance
mismatch. The OOP ideal of a single source of data is nice,
unfortunately the real world gets in the way.
I never said anything about physical entities. The OOP methodology has
nothing to do with physical entities, but it has everything to do with
entities. The fact that in this example the entity is physical has no
bearing on it whatsoever. Nobody said anything about limiting OOP
entities to physical entities.
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.
Who talks about duplicating business logic? You just need to have
more than one access point for the data.
If you have more than one access point for the data you end up with a
more complicated maintenance situation since you may have several places
that treat the data differently. This is bad m'kay.
When you're talking about something as simple as a customer it's true
that an OOP approach probably doesn't add much to the equation. However,
when you're dealing with complex entities which span several tables and
have data stored in a different format to how it's used (think
serialize) it makes sense to have a single point where you can get that
data so that you don't end up duplicating the code needed to extract and
store it.
If this is not what you think OOP is all about, do please enlighten us
as to the error of our ways.
Imagine deleting many rows in a table one by one (pseudocode):
<snip>
instead of taking them with a single DELETE:
<snip>
Whoa nellie!! This is a question of design, not a question of whether to
use OOP. For example, in several of the sites I maintain I have classes
that inherit from a base class called Table. The base class provides a
lot of the basic methods for working on a table (think ActiveRecord). It
also has static methods for doing things like updates and deletes based
on a where clause. The derived classes can override filter methods
(AfterLoad and BeforeSave) to massage the data after it's loaded and
before it's saved. They also add any methods needed for acting on that
particular entity.
I'm the first to admit that OOP is not always the best methadology to
use - the 'best methadology for all situations' does not exist. However,
the general feeling people will get towards OOP from this list seems to
be 'OOP bad, anything else better'. OOP is great as long as you follow
OOD principles and have a fair amount of common sense. It should not be
used just because it's there, but it should also not be dismissed.
In fact, in writing that I've just realised that OOP is not the key...
OOD is. OOD can be applied (with no syntax or compiler assistance) in a
functional system which will have great benefits, all of which I think
most people are aware of but, for whatever reason, fail to adequately
apply - which is where OOP can be useful since it enforces the structure
and protection through the syntax (PHP4 sucked for this, PHP5 is better).
When you actually think about it, OOP is not a methadology - it's a
syntax. OOD is the methadology. Ramble... ramble... ramble... over!
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
