On Mon, Oct 05, 2009 at 05:48:32PM -0700, Jim Lucas wrote:
> Here is a problem that I have had for years now. I have been trying to come up
> with the perfect solution for this problem. But, I have come down to two
> different methods for solving it.
>
> Here is the problem...
[...]
>
> Now, we all have a function or method like this floating around somewhere.
>
> My question is, how do YOU go about setting the required entries of the $headers
> array() ?
>
[...]
>
> END of examples...
>
> Now, IMO, the last one is the simplest one and for me, I think it will be the
> new way that I solve this type of problem.
>
> But, my question that I put out to all of you is...
>
> How would you solve this problem?
I have use this array_merge() approach mentioned in other posts for
quite some time but found that it introduced many bugs when fieldnames changed.
Ie. if the defaults come from a database table and I changed the schema it
caused undefined values during the merging and - worse - sometimes messed up the
inner workings of functions...
Then I heard of the "value object" approach somewhere and found that much more
solid. One would basically define a class where default values are represented
by its properties. Ie:
class vo_email extends vo {
public $to = '';
public $from = '';
public $subject = '(no subject)';
public $body = '';
...
}
the constructor can make sure that absolutly necessary values are required and
set properly - and could complain if something is not right. There could be
methods that add() or set() or change() things. These could also be inherited
from a very generic class "vo" so that this stuff is written once and applies
to all sorts of defaults in the program.
In my app the inherited constructor accepts arrays as parameter and assigns
their elements to the object properties and - by that - overwrites the default
settings. If elements do not match with the defined properties it will trigger
a very visible call trace.
A function like sendEmail() would then require a object of type vo_email as
parameter and would work with its properties internally and can rely on it as
the vo's constructor should have catched anything bad.
If additional logic for the input values is required, it can be added easily:
class dao_email extends vo_email {
...
public function encode_body() {
...
}
public function sanitize_mail_address() {
}
...
}
sendEmail() would then require a dao_email object (dao=data access object) as
input.
stephan
>
> TIA
>
> Jim Lucas
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
