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

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.
>
>

One other thing - the class members shouldn't be static. Static members
are shared by all objects of the class. So if you have two objects of
this class and change it in one, both will change.

Non-static data members are unique to each instantiation of the class.

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

[Back to original message]