Object Construction

[bubblenut]

I was just wondering how people like to create their domain objects. I personally provide everything on the constructor but it get's quite unweildy for larger classes.

Options so far...

$obj = new myObject($resource1, $resource2, $data1, $data2, $data3);

$obj = new myObject($resource1, $resource2);
// or $obj->setData1($data1); if you don't like __set
$obj->data1 = $data1;
$obj->data2 = $data2;
$obj->data3 = $data3;

$params = array(
    'data1' => $data1,
    'data2' => $data2,
    'data3' => $data3
);
$obj = new myObject($resource1, $resource2, $params);

[Weedpacket]

When things start getting unwieldy I start supplying factory methods. Of course, this applies more when the object comes in a certain range of stereotyped styles.

[Shrike]

I've used something like perl bless for mapping an array to domain object, although it just maps keys to properties (the perl function does more I think). My domain objects are basically table data gateways, with some active record magic in a super class, so to have 1-1 relationship between table column and object property, and the bless() method seems to make sense.

If a domain object has a constructor it is used for general initialisation, those things required by empty (new) domain objects and ones loaded from the database.

Weedpacket wrote:

When things start getting unwieldy I start supplying factory methods.

Do you mean a factory method for creating the class, or for populating it with data?

[bubblenut]

Weedpacked:
Ah yes, when my domain objects are pulled from the database they're created in the same place (per domain object), I hadn't thought that this could be done for creating new objects as well. Something like this?

// Active Record stylee ..
$object = myObject::get(1);
$object = myObject::create();
// .. or with a Data Mapper
$object = $myObject_mapper->get(1);
$object = $myObject_mapper->create();

Shrike:
So, things which are required for an object to be valid (generally resources) go in on the constructor and then the object is 'blessed' with it's data afterwards? That sounds very nice, something like the following?

$object = new myObject($resource1, $resource2);
$props = array(
  'data1' => $data1,
  'data2' => $data2,
  'data3' => $data3
);
$object->bless($props);

I can see that working very well with domain objects where you often get an associative array back from the database or you need a completely fresh object.

[Shrike]

Bubblenut wrote:

So, things which are required for an object to be valid (generally resources) go in on the constructor and then the object is 'blessed' with it's data afterwards? That sounds very nice, something like the following?

$object = new myObject($resource1, $resource2);
$props = array(
  'data1' => $data1,
  'data2' => $data2,
  'data3' => $data3
);
$object->bless($props);

I can see that working very well with domain objects where you often get an associative array back from the database or you need a completely fresh object.

Yes that's right. Works really well for simple objects, but not so well for complex ones. I should really look at Rail's active record sometimes for some inspiration.

[vaaaska]

I love it when you guys have threads like this. I'm looking for someplace where I can get information like this all the time...books are fine but not fine enough...the web...it's hard to come across this kind of stuff very often (and when you need it).

Lately, I've been thinking that PHPBuilder needs an experts corner.

[rvdavid]

bubblenut wrote:

Weedpacked:
Ah yes, when my domain objects are pulled from the database they're created in the same place (per domain object), I hadn't thought that this could be done for creating new objects as well. Something like this?

// Active Record stylee ..
$object = myObject::get(1);
$object = myObject::create();
// .. or with a Data Mapper
$object = $myObject_mapper->get(1);
$object = $myObject_mapper->create();

Shrike:
So, things which are required for an object to be valid (generally resources) go in on the constructor and then the object is 'blessed' with it's data afterwards? That sounds very nice, something like the following?

$object = new myObject($resource1, $resource2);
$props = array(
  'data1' => $data1,
  'data2' => $data2,
  'data3' => $data3
);
$object->bless($props);

I can see that working very well with domain objects where you often get an associative array back from the database or you need a completely fresh object.

If you were going to generate an associative array to feed to the "myObject" object, you could create it inside a dataspace object (hash + accessors/mutators). and just pass it in.

It's neater this way, you have an api for your array and you won't have to remember the data structure of the array because it's all abstracted by the dta space object's API.

class Data_Space
{
    private $_hash;

function __construct($data = array())
{
       $this->_hash = $data;
}

protected function _set($property, $value)
{
      $this->_hash[$property] = $value;
}

protected function _get($property)
{
       return (array_key_exists($property, $this->_hash)) ? $this->_hash[$property] : null;
}
}

You could stop there, but you've just created a dynamic type, you'd still be guessing as to what key value pairs to put in. I usually superclass it with named accessors/mutators like so:

class Props
    extends Data_Space
{
    public function set_some_prop($value)
    {
          $this->_set('some_prop',$value);
    }

public function get_some_prop()
{
      return $this->_get('some_prop');
}

public function set_another_prop($value) 
{
       //...
}

public function get_another_prop()
{
       //...
}
}

This relays the intent of the code through the API instead of documentation (comments) or guesses your own memory.

If you had an application with complex relationships, you'd either have to do a lot of guess work or repeatedly have to go back and refer to the API documentation.

There are cases where this approach is overkill 🙂 but you'll know when that is.

Regards,

[rvdavid]

vaaaska wrote:

I love it when you guys have threads like this. I'm looking for someplace where I can get information like this all the time...books are fine but not fine enough...the web...it's hard to come across this kind of stuff very often (and when you need it).

Lately, I've been thinking that PHPBuilder needs an experts corner.

An experts section would be great 🙂

Not necessarilly an "experts" corner per seh, but a place where developers could discuss application design and development for both the procedural and object oriented paradigms... Things that transcend syntax.

I'll be 100% behind this.

[vaaaska]

rvdavid wrote:

An experts section would be great 🙂

Not necessarilly an "experts" corner per seh, but a place where developers could discuss application design and development for both the procedural and object oriented paradigms... Things that transcend syntax.

I'll be 100% behind this.

Exactly! Sitepoint has one...I've been spending a little more time over there trying things out. Are there any other good forums that have something like this?

[bubblenut]

If I'm going to use setter methods for every property, then I may as well use the ones on the object itself rather than creating a whole other object just to pass them in surely.

$my_obj = new myObject();
$my_obj->setPropOne('blahblah');
$my_obj->setPropTwo('blahblah');

// rather than

$my_props_obj = new myPropsObject();
$my_props_obj->setPropOne('blahblah');
$my_props_obj->setPropTwo('blahblah');
$my_obj = new myObject($my_props_obj);

I really don't see the need for the myPropsObject class. When using an array to pass in these properties we have the advantage that it's simple and non type specific so we can abstract the property construction away from the actual object instantiation (see example below). I may well be missing the point though.

Below we're generating an array (or an abstract data object) in the magic datasource which we have no control over (maybe a DB object, or a web service). And then instantiating the objects in the concrete implementations. I may be looking at this whole subject with a bit of a narrow view but as I see it, the magority of domain object construction at some point comes back to something similar to this. A situation where you have, in one hand a need to create an object of type X and in the other a dataset passed back from some external API.

<?php

interface MyFactory {
    public function get($key);
}

abstract class SuperFactory implements MyFactory {
    protected $datasource;

public function __construct( MyMagicDataSource $datasource ) {
    $this->datasource = $datasource;
}

public abstract function get($key) {
    return $this->datasource->magicGet($magic_key);
}
}

class MyObjectFactory extends SuperFactory {
    public function get($key) {
        if($data = parent::get($key)) {
            $obj = new MyObject();
            $obj->bless($data);
        }
    }
}

class MyOtherObjectFactory extends SuperFactory {
    public function get($key) {
        if($data = parent::get($key)) {
            $obj = new MyOtherObject($data);
            $obj->bless($data);
        }
    }
}

[rvdavid]

Hi there,

bubblenut wrote:

If I'm going to use setter methods for every property, then I may as well use the ones on the object itself rather than creating a whole other object just to pass them in surely.

$my_obj = new myObject();
$my_obj->setPropOne('blahblah');
$my_obj->setPropTwo('blahblah');

// rather than

$my_props_obj = new myPropsObject();
$my_props_obj->setPropOne('blahblah');
$my_props_obj->setPropTwo('blahblah');
$my_obj = new myObject($my_props_obj);

I really don't see the need for the myPropsObject class.

Well if you look at it in this context. Putting your parameters inside atype will no doubt be overkill.

I mean hey, you've got two parameters. Why not just pass them in the constructor? 🙂

$myObject = new MyObject('someprop', 'blah blah');

You won't need them for two anonymous properties/params. But if you had pieces of data that are specific you'd want to have the specifications highlighted by type.

$rule['type'] = 'string';
$rule['code'] = 2;
$rule['maxlength'] = 20;
$rule['minlength'] = 6;
$rule['required'] = true;
$rule['special_characters'] = true;

$myObject = new Validator($rule);

So we'll need to memorise that the validator constructor will require an array with the specific structure/keys.

Sure we can document this in the constructor, we can put it in the api, but why not let our code express our intent instead? put it in a type.

Class Rule 
{
 //... too lazy to demonstrate
}

The class documents itself.

This approach is of course not applicable to all cases as you have demonstrated, but it does have its place. 🙂

When using an array to pass in these properties we have the advantage that it's simple and non type specific so we can abstract the property construction away from the actual object instantiation (see example below). I may well be missing the point though.

Using arrays to pass properties also have their place, but there are also cases when you'd want type specific data. I've worked with developers who cry about PHPs flexibility because it requires developers to be disciplined and determined on not writing dirty code.

I appreciate the point you made regarding abstraction however, this is also achieved by passing a type as a parameter.

There will be times when you want data to be type specific so that intent is communicated and complicated/flexible data abstracted. You shouldn't use arrays with aims of "abstraction". Arrays are collections, containers and have a type of their own - array.

I agree wholy with your point that domain objects either return objects with factory methods (like a table data gateway returning row data gateway objects) or collections from external/built in PHP constructs (such as an array being the processed product of mysql_query which you could then be passed in to a Row Data Gateway object

Regards,

[bubblenut]

OK, here's my point. Let's take your example.

 $rule['type'] = 'string';
$rule['code'] = 2;
$rule['maxlength'] = 20;
$rule['minlength'] = 6;
$rule['required'] = true;
$rule['special_characters'] = true;

$myObject = new Validator($rule);

To do this with a dataspace object we would end up with something like the following, am I right?

$rule = new Rule();
$rule->setType('string');
$rule->setCode(2);
$rule->setMaxLength(20);
$rule->setMinLength(6);
$rule->setRequired(true);
$rule->setSpecialCharacters(true);
$validator = new Validator($rule);

What I'm missing here is this. What is the advantage of this method over the following.

$validator = new Validator();
$validator->setType('string');
$validator->setCode(2);
$validator->setMaxLength(20);
$validator->setMinLength(6);
$validator->setRequired(true);
$validator->setSpecialCharacters(true);

Actually, I think I understand. Is the reason for this to prevent Validator being in an invalid state? We have mandated that Validator must have the following fields set in order to be valid. Although, one thing which still doesn't sit right with me is the potential for duplication. We now have two sets of setter methods, one in the Rule class and one in the Validator.

I'm slowly coming around to the reasoning for this pattern but I'm still not convinced. If you have the time, please convince me 🙂

[edit]
On the other hand, I can think of a compelling argument against it 😉
[/edit]

[Jason_Batten]

I'm currently reading: The Object Oriented Thought Process 2nd Edition by Matt Weisfeld

Y'all might wanna gander now.

First four chapters can be found here at developer.com

[vaaaska]

Thanks Jason...looks like some worthy reading. 😉

[rvdavid]

Hi,

I know exactly what you're talking about regarding patternitis 🙂
There's also it's not so distant cousin "Analysis Paralysis". Where you sit there designing and redesigning trying to apply new methods you've learnt and not getting anywhere.

To do this with a dataspace object we would end up with something like the following, am I right?

yes you are correct 🙂

$rule = new Rule();
$rule->setType('string');
$rule->setCode(2);
$rule->setMaxLength(20);
$rule->setMinLength(6);
$rule->setRequired(true);
$rule->setSpecialCharacters(true);
$validator = new Validator($rule);

What I'm missing here is this. What is the advantage of this method over the following.

$validator = new Validator();
$validator->setType('string');
$validator->setCode(2);
$validator->setMaxLength(20);
$validator->setMinLength(6);
$validator->setRequired(true);
$validator->setSpecialCharacters(true);

When you need to create different rules for different input.

You could use the Rule object mentioned above as a Concrete class would have been a base object. You could superclass the Rule class with String_Rule(), Password_Rule(), Email_Rule(), Numeric_Rule() or any other rules that your input would need to follow.

Actually, I think I understand. Is the reason for this to prevent Validator being in an invalid state? We have mandated that Validator must have the following fields set in order to be valid. Although, one thing which still doesn't sit right with me is the potential for duplication. We now have two sets of setter methods, one in the Rule class and one in the Validator.

You're looking at the validator differently from how I'm seeing it. I guess my reason main reason is actually going back to the base principle that an object should do one thing and one thing well.

A validator's role is to check if input matches certain criteria/rules. It has one action - validate and returns true or false.

If the validator owns the criteria (whether it be through composition or having rules as its attributes) instead of using it, then it would either be inflexible, or be a god-ish class.

You'd be instantiating a validator with methods to set email, string and numeric rules/criteria you've set when all you wanted to do is validate a password field.

So off the bat let's think about this one, well, let's separate them... A validator for different types with the common functionality in a base validator object.

Base_Validator,
Email_Validator,
Custom_Validator,
Numeric_Validator,
String_Validator

At this stage, it kind of feels better, but still doesn't feel right, we're going to be making a validator for each field, we're going to be setting the criteria for each validator. That's going to be pretty strenuous if we were to validate 4/5 fields.

If we take another look at it, the validator base class would only ever have the 1 public method and a bunch of protected methods for handling criteria checks.

Let's super class the validator and add your accessor and mutator methods for each type of validation you need.

Taking a closer look at it, all we doing here is specifying criteria. We are creating validators so that we can specify criteria for the validator.

You should start sensing that this is the perfect time to quote the words "Composition over Inheritance" ... right... if we apply it to this case, that's going to be a nightmare... How about... "Aggregation over Composition".

Let's make our Base Validator class a generic concrete class. The Validator will only concern itself with Validation and use a private set of methods to make comparisons. Maybe you can decompose this a little further later on if the types you're handling explodes to a bad number.

Now then, onto the rules that the Validator will read. In the previous examples you and I have used, we have to manually set the values for criteria. What if we had default criteria that are mutable for each rule? Like say our string rule can have 20 characters as its default value.

we could have implementations like:

$validator = new Validator();
$validator->validate($this->_request->get('username'), new String_Rule());
$validator->validate($This->_request->get('password'), new Password_rule());

I'm slowly coming around to the reasoning for this pattern but I'm still not convinced. If you have the time, please convince me 🙂

Although I mentioned "DataSpace", my point is actually outside the scope of patterns, my point is geared more toward encapsulation/abstraction of application complexity rather than a "Use this pattern now Now NOW!" recommendation.

Apologies if I came accross like so, and also, I'm not trying to convince you, I made the posts that I have because I enjoy discussing this stuff. So don't feel like I'm bullying you into seeing things the way I do 😉

ps. I'm sorry it's a little vague, it's 4 am here!

regards,

[jazz_snob]

I put it all in the constructor. I don't like ctors w/ lots of args, has the smell of bad design, but just the smell; it might actually be required. There are probably cases where other methods are better. This article covers the 3 techniques used and eventhough its examples are in java, you can extrapolate the idea to OO design in general.

[rvdavid]

jazz_snob wrote:

I don't like ctors w/ lots of args, has the smell of bad design, but just the smell; it might actually be required.

I agree, it's the code smells that you speak of that should also let us know when to declare types etc. 🙂 I gather you've read "Refactoring" by Martin Fowler also? if not, you should pick it up, it's a very good read.

This article covers the 3 techniques used and eventhough its examples are in java, you can extrapolate the idea to OO design in general.

I'm actually looking into dependency injection at this point in time 🙂
there's a package specific to PHP called Phemto created by the auther of Simpletest. It tries to do for PHP, what the Pico Container has done for it's language...

But this is different, before you look at DI solutions though, you should start small and increment as needed.

• Registry (your application's complexity superseeds the registry's capabilities, then try Service Locator)
• Service Locator (your applications complexity superseeds what the service locator offers? then you need DI)
• Dependency Injection

These Enterprise Pattern layer solutions are of course, only applied as required. More exceptions to the rule rather than the rule itself 🙂

Regards,

[jazz_snob]

I think as for depency injection my take was that you give the object what it needs (dependencies) at creation, then you don't have to worry if its in the right state when its called on later. Also, the biggest thing I've learned (although it seems obvious now) is whatever you inject in the ctor should be a literal, or an interface if possible (dependency inversion), and probably from within the same package too. My designs got much better since I started doing that.

[rvdavid]

That sounds intriguing 🙂

How often do you use it?
I'm idly looking into it, so I'm not really that well versed with DI.

Care to post some example code?

Thanks in advance.

Regards,

[jazz_snob]

Its actually very simple. Maybe I made it sound harder than it is. This is manual dependency injection. For the record, I only work in PHP4.

For example, I have a DBWrapper object, does db abstraction. It takes a driver object, a different class for each DB vendor (mysql, mssql). I only have a mysql driver for now. Anyway the DBWrapper basically delegates each call to its driver ( so effectively the driver object is implementing the interface exposed by DBWrapper).

I also have a TableDataGateway that I subclass for many projects which requires such an object at its creation.

class TableDataGateway {

  var $conn;
  var $table;
  /**
   * I inject a DBWrapper object and name of table
   */
  function TableDataGateway( &$conn, $table ) {
    $this->conn =& $conn;
    $this->table = $table;
  }

  /**
   * If this were java this method would be a protected method.
   * Basically only subclass should be calling this method.
   */
  function _insert( $sql, $args) {
    //code...
  }

  function _update($sql, $args) {
    //code...
  }

  /**
   * Simplest subclass will use a single table, so this works
   * for many of them.
   */
  function delete($id) {
    $sql = "delete from $this->table where id=?";
    return $this->conn->execute($sql, $id);
  }

  /**
   * I put a basic finder method in too, but lately I've been writing entirely separate finder classes
   */ 
  function find($id) {
    //returns null or an associative array representing the row
  }


}

Since the injected DBWrapper is an interface I can "inject" a mock object if necessary for testing. Also I don't have to change the gateway class just because the DB vendor changes, i just load a different driver into the DBWrapper.

Maybe I should redesign this, but its easier for now to subclass TableDataGateway each time (example: ProductGateway, SessionGateway, etc) rather than come up w/ a generic gateway...typically just the sql for the insert and update statements are different. My latest project is pretty involved so its really going to test how far I can get w/ this design.

As an aside, I don't see why some folks wants to make a "java equivalent of X" in PHP. Just use java to begin with if that is what you want 🙂