Robert,
I looked at your code in InterJinn a couple of times; i havent gone over all
of it mind you but it looks pretty sweet.
have you had a look at any of the other frameworks i mentioned earlier in
this thread?
ez components, onPHP, and now there is a new one ive found (in recent
thread) Radicore. i really like the xsl approach
for templates.
All,
also, more on topic; there are many different ways to use interfaces and
abstract classes in many different design patterns.
they all have purpose, pros and cons. take for instance factory method and
abstract factory; where the former uses inheritance
the later uses composition. the former can produce only a single class of
products, but the abstract base class rarely needs revision;
whereas the later can produce sets of related product classes; yet every
time a new product class is needed or deprecated the
abstract factory [interface] needs revision.
Steve,
you might also check out
http://www.phppatterns.com/docs/start
i dont think its been maintained in a while, but its a great place to start.
also, i think PDO is pretty sweet, but really its only the base of a strong
db abstraction layer, such as what youll find in ez components.
-nathan
ps.
i cant decide if i should build my own db layer around pdo or go for a
pre-built one from an aforementioned framework; only time will tell :>
On 7/11/07, Jochem Maas <jochem@xxxxxxxxxxxxx> wrote:
some ideas about class design:
1. properties should normally (read almost always) be private.
2. the apps interface to the DB [connection] is via the 'generic'
class, the app should have to know nothing about the drive object and
should have no direct access to it.
3. use an interface definition for your drivers (so they all share a
common set of method ... a common interface ;-))
this leaves you with the problem of wanting to write as little boilerplate
code for making the functionality each driver class implements available
via
the 'generic' class.
I would suggest either a few simple functions like so:
class DB {
function query() {
$args = func_get_args();
return call_user_func_array(array($this->driver,
__FUNCTION__), $args);
}
}
which you can simplify into something like:
class DB {
function __call($meth, $args) {
$func = array($this->driver, $meth)
if (!is_callable($func))
throw new Exception('undefined interface:
'.__CLASS__.'::'$meth);
return call_user_func_array($func, $args);
}
}
just an idea :-) ... this seems to me to be something along the decorator
pattern,
you could choose to do something along the lines of the factory pattern,
where by
your factory returns a 'driver' object which your application uses (not
caring what
class of driver it is) ... this would also require that your driver
classes share a
common interface (actually using a interface definition to enforce it is a
seperate issue).
an interface example:
interface DBDriver {
function query($sql, $args);
function commit($id);
function rollback($id);
}
class MySQL_DBDriver implements DBDriver {
function query($sql, $args) { return mysql_query($sql, $args);
}
function commit($id); { return true; }
function rollback($id); { return true; }
}
Steve Perkins wrote:
>
> // but they fail from here
>
> echo $gen->driver->prop1 ;
> echo $gen->driver->function1 ;
what fails exactly? what is the error?
>
> // this works ok though, so everything is created
> // correctly
>
> $gen->authenticate() ;
>
PS. I would hazard a guess and say the generic class is not very generic -
it's quite specifically a 'database' class, it is an 'abstract' class (not
in the
php syntax sense) in that the DBMS specifics are hidden away in
helper/plugin classes.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
