|
|
Posted by Jerry Stuckle on 04/13/07 04:25
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?
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.
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.
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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|