[thelist] Classes, methods, return values and best practice

[Jackson Yee]

"Andy Warwick" <mailing.lists at creed.co.uk> wrote in message
news:B989D97B.318C%mailing.lists at creed.co.uk...
> I'm fairly new to OOP (in PHP here, but I'm sure concepts apply equally to
> other languages) but am making headway into the concept; however, I could
do
> with a few insights into best practice - and reasons why - for the
> following:
>
> So far, I've gleaned that all variables within the class are best being
> 'private', and only accessed through 'get' and 'set' methods, thus:

[snipped code]

What you're describing is part of the concept of encapsulation and data
hiding within OOP.  Although this has its uses in C++ or Java where the
class acts as a proxy for storing and returning data outside of the normal
application (disk file, registry, remote SOAP object, etc...), for a
scripting language such as PHP, I would just go ahead and access the class
members directly as in

$foo = new bar();
echo $foo->id;

unless you believe the stored variables could be stored in something other
than PHP's execution memory.  Unlike C++ or Java, PHP does not include
public, protected, or private access control (well, not without a hack
anyway...), so it's of little use to include get/set methods which return
only a reference to a member variables, as programmers could simply access
the variable directly whether you include the get/set methods or not.  The
extra get/set methods will increase the size of your file, make the parser
do extra work, and confuse other people as to why you have those methods in
the first place.

If you indeed design a class to be a proxy and data members are not stored
as part of the class but as something external to the class, then the
get/set methods would be appropiate.  Otherwise, I would leave them out.
Even within my C++ code, I still use publically accessible members when
appropiate and proxy functions when appropiate.  It's a matter of balancing
design and efficiency for me.

> Is it also considered good practice to 'mistrust' passed in values and
check
> them, and if so what kind of checks are considered sufficient or ?
>
>     function SetId ( $value ) {
>         if ( $value = '' OR ! isset ( $value ) ) 'pseudo code chuck error'
>         $this->id = $value ;
>     }

This is always a good idea for large functions unless you're writing code
that needs to execute extremely fast, but as I haven't seen anyone attempt
to write a kernel or a device driver using PHP, I think you're safe on that
account.  ;-)  For smaller functions, the issue is debatable, as if you will
be calling a small function a few dozen times within a script or have it
inside a while/for/foreach loop, not having the extra check could make your
script run faster without the O(n) time taken up by the check.

For example, the iterators within the C++ STL do not check to see if they
point to a valid object when they're dereferences because that would be a
significant overhead in many algorithms when iterators are repeatedly
dereferenced.  It is up to the user to ensure that the iterators are valid,
otherwise, you'll likely end up in a SEGFAULT or GPF.

However, operations that are done only seldomly, such as opening a file for
reading or creating a window in a GUI, are almost always extensively
checked, mainly because efficiency is of little concern compared to the
security of having the operation succeed.  A program might only open a file
once or twice, but when it does, it *needs* to know that the file was
successfully opened for the rest of its operations to succeed, and it also
needs to know *what* exactly caused the opening process to fail if it does
fail.  In that case, error checking and output is not only expected, but
required.

So once again, it comes down to a design decision of how safe you want your
code to be versus how fast your code needs to be.  I know it sounds like a
political statement saying "Well, I support this group's view, but I can
also see how this other group wants something else," but the sense of when
error checking is really necessary versus when it's simply convenient is
something that you'll develop intuitively as you write more code.  Just take
the time to think about what you're doing and why you're doing it, and
you'll be fine.  Don't do something simply because other people think it's
right or because they told you so - understand the reasons behind their
arguments, and make your own conclusions.

Realizing that he's beginning to sound like an old man although he's only
21,
Jackson Yee
jyee at vt.edu
http://www.jacksonyee.com/