NYCPHP Meetup

[Tim Gales]

Daniel Convissor wrote:
[...]
> 
>> Regarding the number of returns, it's better to minimize the number of
>> exit points because it simplifies the function contract. If you have
>> to modify the code later, there are fewer exit points to consider.
> 
> Yeah, I've heard that point of view before.  Sure, you can design only 
> one exit point but then you have to use more time considering more code 
> and ensuring all your code doesn't inadvertently change the result before 
> returning.
> 
> Guess our minds work differently. :)
> 
Yeah, and from that code fragment it looks like
the work of two different people with different
mindsets.

Programmer A wrote a SomeObject class
with a loadObjectByRecordId($record_id) method.

Now we don't see the definition of the class.
But there might be an isValid member.

If there isn't, there probably should be one --
you could just extend the class and add it.

Programmer B comes along and want to reuse
the class, but with a procedural mindset.
So he uses the $result variable to decide
which path to take in his procedural code.

Testing ($result === true) before calling
$yourObj->getUnrestictedItems() should be
totally unnecessary -- the class should be
designed to report back an error if you try
try a 'getUnrestictedItems' when 'isValid'
is false.

Without considering adding another method
to the class to take advantage of an isValid
member (whether preexisting or extended) Progammer B
merrily continues along his procedural path.

The result is a 'reverse data abstraction', which
takes the innards of an object and brings them
up where they don't belong -- rather messy.

To me, discussing where to test the validation
variable in order to make the resultant proceural
code cleaner is moot.

-- 

T. Gales & Associates
'Helping People Connect with Technology'

http://www.tgaconnect.com