On Thu, 22 Feb 2007 17:44:47 +0100, Andrew <Taylorwrote:
Quote:
Hi,
>
I've been using PHP for a long time, I have designed and developed a
number of mid-range systems. I've always used a procedural approach. I
fully understand the concept of OO, I know all the basics and I know how
to code OO. What I'm having problems with is understanding how to
design/architect projects using OO.
>
Can anyone reccomend any good online tutorials / online learning / video
tutorials which deal with these subjects specifically in PHP. I have a
number of the class OO books which help me understand the principals,
but, not how to leverage those principals in to system design.
>
Also, I am trying to learn how to do this myself, this is not just a
lazy call for the answer, perhaps somebody could answer this which might
help me on my way as well as the above request for further information..
>
One thing which confuses me is how to use databases in the OO approach..
Imagine we have a system which deals with music CDs:
>
class MusicCD {
>
private $title;
private $artist;
>
function __constructor($title, $artist) {
>
$this->title = $title;
$this->artist = $artist;
}
>
function displayCD() {
>
echo $this->title.' '.$this->artist;
}
}
>
Now, we want to save this information in to a database, what is the
correct way (best practice) for doing this; is it to create a saveCD
method in my musicCD class? Should this method expect a database object
to be passed in, or, should it call static methods of another class?
>
function saveCD(Database $databaseObject) {
>
$databaseObject->query('INSERT INTO...
}
>
function saveCD() {
>
mysql_connect(...)
}
>
Surely in the OO concept the MusicCD class doesn't need to know about my
table structure etc, would this be a case for a MusicCDDatabase class
which knows about MusicCD and DB?
>
Just to re-itterate, I know how to code in PHP, I know how to use OO
syntax, I'm just having problems designing my system.
>
Thanks for reading a long post, and thanks in advance for any help.
>
Andrew
>
Interesting question, Andrew! (And I'm not just saying that because we're
name-sakes ;) )
I was discussing a similar topic with one of my colleagues at work:
where does the user interface come in?
And we found two approaches:
1) The interface is defined separately, either using O.O. techniques or
not, and gets told about the O.O. system in design time. Then the user
chooses some functionality, which in turn invokes the O.O. instances.
2) The O.O. system is told that for some methods it needs a user
interface, thus the instance constructors accept parameters that indicate
which parts of an existing user interface belongs to which method. Then
when the user chooses some functionality, it's the O.O. instance that
invokes the user interface.
Something similar can be conceived with database access:
The class needs to know when it needs to save anything... but not
necessarily where or how. So you could design a helper class and offload
the actual database interaction to an instance thereof, or you could have
your MusicCD class inherit and extend a database-capable class. That way
you could derive a MusicCD class from an OracleSQL class, or from a MySQL
class, or from a Text class... or all of them combined, choosing which to
use during run-time, based on some configuration.
--
Using Opera's revolutionary e-mail client:
http://www.opera.com/mail/