Apr 13 at 2:24am, Andy B wrote:
> instead of making one super huge class..
> turn that class into a bunch of mini classes.
> DbConnect, DbError, DbQuery, DbResult and so on...
Right; chances are if you had all the functionality in one class, it's
going to be pretty identical to writing it without using a class.
Above you've listed several logical classes you might use with databases.
They make perfect sense because they represent tangible "objects" as you
might think of the process in an abstract sense. I think breaking down the
parts of the real-world process is a great start to approach OO design.
> i can see writing different classes for different sections of db use but
> unless my mind is super limmited right now that isnt really 100%
> possible or reasonable considering that some of those classes might only
> have 1 or 2 different functions in it... but then again i guess super
> small exact easy to figure out classes are the best??
First, there is nothing unreasonable or impossible about a class with one
or two methods. If it's a logical delineation, that seems perfectly fine.
In most cases, you might rough it out like that in your mind, but as you
are writing the code (or next week), new methods will occur to you.
Since you have created an object that makes sense, you've got an inherent
place to put that newly conceived code. Better to realize your DBQuery
object could use a method to write a SELECT query than to realize your
DBConnection object has a bunch of methods that actually should become a
DBQuery object that you didn't create because it seemed too lean.
To be more specific, breaking these methods into logically grouped classes
enables you to structure your code in a way that leverages OO. Rather than
manually handling a query result value, you can encapsulate a query result
into an object and have your DBQuery object return DBResult objects.
Imagine a function that returns an array. To make use of that array
result, the coder you must know what the array result means and write code
that incorporates that logic, every time it's used. Your code needs to,
for example, pull out a certain key to find a value within the result
data. If that key changes, then so too must all that code.
Compare this with returning an object--now your code does not need to work
with the structural nature of the result, it must only operate the
object's interface to fetch the value. This 'encapsulation' allows you to
freely alter the inner workings of an object without having to alter any
of the code that uses the object (provided you don't break the interface).
Illustratively, compare these arbitrary (and utterly generic) examples:
$x = $result['fields']['display']; // OR
$x = $result->getField('display');
The skeptic may not see a difference, however, suppose your results become
more complex and now you'd like to change the structure of your result...
$x = $result['mydata']['fields']['display'];
Handling the array yourself now becomes much more overhead, because you've
got to go change all the occurrences. Whereas, encapsulated in an object,
the code would not need to change assuming you preserved the interface.
In many ways, returning an array is not much different from returning an
object, except the object has functionalities (methods) that operate on
the data, rather than relying on your knowledge of the data returned.
Now the coder needs only use the object's interface. So you see, an
object is merely a complex data structure that 'does stuff'.
The point being, objects can interact in a way that more closely
represents the actual concept rather than arbitrary code required to
interpret the data in a way that relies on the coder's knowledge of the
structural content. Furthermore, the object's data structure can now be
changed centrally, with no ill effects on the rest of your code.
As for a strategy to approach the design, just begin thinking of the
problem in the abstract. How do you represent the process in more human
terms? What would the data do, if it had a brain? Model your objects
against that paradigm, and the code will begin to write itself. Okay,
maybe not quite, but it's much easier than it seems because the code flows
from real-world logic processes rather than being dictated by programmatic
issues you may need to address without OO.
Try it out, think conceptually. Get crazy: the more creative you get with
these ideas, the more neat things you'll find to do with OO. Often this
design process may require multiple revisions until you hit the right
balance. Like any design effort, it's worth the time--and gets easier.
--Kelly
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
