Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Short Refactoring Tip: let the object do it for you

by dws (Chancellor)
on May 19, 2003 at 21:46 UTC ( [id://259310]=note: print w/replies, xml ) Need Help??


in reply to Short Refactoring Tip: let the object do it for you

If we need to change those names, this code will be break pretty quickly.

Not only that, but forcing a client to write

if ($po->status->name eq 'Pending') { ...
requires them to know that a purchase order has a status, and that the status has a name. Both of those details are probably inappropriate for client code that deals with purchase orders to have to know. It also makes purchase orders harder to unit test, since you then have to either unit test a Status at the same time, or rig up mock objects to use in places of a Status. By structuring the API like
if ($po->can_send) { ...
you reduce the complexity of testing.

There's a design principle--whose name I'm blanking on (Demeter's Law -- thanks, lachoy)--that says that if you find yourself writing expressions that navigate more than one level into an object structure, the top-level object needs a different protocol. In the case above, can_send is that new protocol, and status can be made private (e.g., by renaming it to _status).

Replies are listed 'Best First'.
Re: Re: Short Refactoring Tip: let the object do it for you
by lachoy (Parson) on May 19, 2003 at 22:21 UTC

    That's the Law of Demeter, or at least part of it.

    Chris
    M-x auto-bs-mode

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://259310]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-04-18 00:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found