|
|
Posted by amygdala on 04/13/07 04:13
"Jerry Stuckle" <jstucklex@attglobal.net> schreef in bericht
news:UbydnbDR174eZYPbnZ2dnUVZ_tOmnZ2d@comcast.com...
> amygdala wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> schreef in bericht
>> news:_L2dncAv8ZxOfIPbnZ2dnUVZ_sOknZ2d@comcast.com...
>>> amygdala wrote:
>>
>> <snip>
>>
>>
>>> 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.
>>
>> Well, this is just exactly what I am trying to avoid. I have (unfinished)
>> __get and __set methods in the base class DB_Table that should take care
>> of this in one go.
>>
>>> 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.
>>
>> Hmm, you are no doubt much more experienced in this field, but my
>> gutfeeling says I have to disagree on this one. The whole point of
>> creating this framework for me is to avoid the cumbersome task of
>> creating getter and setter functions for each and every table field. Thus
>> I'm declaring one generic fieldSpecs array that provides properties for
>> the fields so that the generic getters and setters as well as the generic
>> Validator will take care of the rest. I don't see the fieldSpecs array
>> becoming to difficult to understand quickly for me in the future.
>>
>> Still, this leaves me wondering: why doesn't a child class just simply
>> inherite the 'getFieldSpecs' function and let self::$fieldSpecs refer to
>> the $fieldSpecs in the child class? Should this not be the basics of OOP?
>> What am I missing here? Or better yet: how can this be achieved?
>>
>> Thanks for your time people. Much appreciated!
>
> OK, now how are you going to validate the entry? For instance - if you
> have a date field, ensure they put a date in there? Or an integer?
Well, I would use a generic Validator class for that. Something along the
lines of:
class Validator
{
public function validateField( $fieldName, $fieldValue, $fieldSpecs )
{
switch( $fieldSpec [ 'type' ] )
{
case 'boolean':
// validate boolean
break;
case 'string':
if( isset( $fieldSpec[ 'subtype' ] ) )
{
switch( $fieldSpec[ 'subtype' ] )
{
case 'email':
// validate email
break;
case 'url':
// validate url
break
etc.. etc...
}
}
case 'int':
etc.. etc...
For dates I _would_ probably use a custom setter which would convert three
form elements (dd, mm, yyyy) to a unix timestamp (I like those better then
SQL dates) first, but then I would validate its outcome with the generic
Validator also. I could even have some minimal and maximal date values in
$fieldSpecs to check that the date doesn't exceed a certain time span.
For integers I would define some minimal and maximal values in the
$fieldSpecs, and check it directly in the generic Validator. Use is_numeric
and the likes.
> Classes also need to be responsible for their own variables. There should
> be no way you can ever set an invalid value in any member.
Of course, I agree with you totally. But I don't see how my approach would
lead to this happening. I would validate each entry just like you do. But
with a generic __set instead of custom setters.
> So you might as well get used to writing the set and get functions. They
> go pretty quickly (unless you have some extensive validation), and in the
> long run it's a much better way to go.
Maybe you're right. I might be stubborn here. ;-) And off course, I have
thought of the fact that exceptional situations _will_ occur. Probably more
often then I'm thinking off right now. But then that leads me to the
somewhat black and white conclusion stated under your following opinions:
> I've been doing OO programming for almost 20 years now, and yes, I've seen
> your way before. It ends up being cumbersome and highly prone to errors.
> It also creates a maintenance nightmare. You *really* don't want to go
> that route.
>
I see where you are coming from Jerry, but this point of view then almost
leads me to believe that there is no point in creating DB table objects
whatsoever. Cause then it pretty much comes down to the same old 'linear'
routines again. What then, in your opinion, is the surplus value of creating
DB table classes?
Navigation:
[Reply to this message]
|