Posted by Jerry Stuckle on 04/13/07 02:48

amygdala wrote:
> "Toby A Inkster" <usenet200703@tobyinkster.co.uk> schreef in bericht
> news:rrr2f4-4kp.ln1@ophelia.g5n.co.uk...
>> amygdala wrote:
>>
>>> I'm a little confused about the 'factory design pattern' though. Let me
>>> see
>>> if I understand this correctly. Does the factory design pattern in this
>>> case
>>> refer to the fact that you have different interfaces in one Class (in
>>> this
>>> case class User) to create the object, depending on the purpose it
>>> serves.
>> Yep, precisely. You create a static method to produce an object which
>> would normally go further than the plain constructor function in terms of
>> setting object properties.
>>
>> On some occasions you may even want to make the main constructor method
>> for the class private instead of public to force all objects to be created
>> via the factory.
>>
>
> Nice one! That's excellent stuff.
> In the meantime I read a little further on the factory stuff, and indeed saw
> that you could make the constructor method private. Could you by any chance
> provide the simplest example of an occassion where making the constructor
> private makes sense? Cause I can't think of a valuable situation right now.
> But I'm interested in understanding where this would make sense. (That OOP
> stuff is pretty hard to grasp for me)
>
> Another thing I am trying to accomplish is the following: (still the same
> 'framework')
>
> What would be ideal for me is if I had table classes derived from the
> 'template' DB_Table that would only describe table fields and their
> properties. And for the most part let the parent DB_Table handle all the
> generic methods for tweaking fields. Except of course a function such as
> login, as discussed earlier.
>
> What would seem important here also, is to have as little public methods and
> properties as possible. So if you will, consider the following:
>
> class DB_table
> {
> protected static fields;
> protected static fieldSpecs;
>
> // some __constructor etc...
>
> public function getFieldSpecs( $f )
> {
> if( isset( self::fieldSpecs[ $f ] ) )
> {
> return self::fieldSpecs[ $f ];
> }
> else
> {
> return NULL;
> }
> }
> }
>
> class User extends DB_Table
> {
> protected static fieldSpecs = array(
> 'id' => array(
> 'article' => 'a',
> 'screenname' => 'user id',
> 'type' => 'int',
> 'autoinsert' => true,
> 'autoincrement' => true,
> 'static' => true
> ),
> etc...
> );
> }
>
> What I would like to happen is that when I do a:
>
> $u = new User();
> var_dump( $u->getFieldSpecs( 'id' ) );
>
> it would return the 'fieldSpecs' from the 'id' in User. But this doesn't
> seem to work.
>
> parent::$fieldSpecs = array( etc...
>
> doesn't seem to work either.
>
> Is there any way to get this working without having to declare fieldSpecs
> public and/or having to overload (I think it is what it's called) the
> 'getFieldSpecs' function from within User?
>
> In other words, how can I overwrite the 'protected static fieldSpecs' of
> DB_Table from within User so that 'getFieldSpecs' in DB_Table returns its
> values? Or is this against OOP principles?
>
>
> Cheers.
>
>

Definitely properties should be private. They're part of the
implementation.

However, I often have lots of public methods. For instance, I'll have a
getXXX method to fetch 'xxx'. And I may have a setxxx method to set it,
if that makes sense - the latter doing validation on the parameter
passed, if necessary.

So potentially in a table with 25 columns I can have 25 getXXX and 25
setXXX methods (and 25 private variables, one for each column), database
related methods, etc. This can easily come out to 60-70 public methods
- and often I'll have some private ones, also.

But don't try to put all of your variables in one 'fieldspec' array.
While it will work, it will also be almost impossible to understand
later and even worse to maintain.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]