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') { ...
[download]

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) { ...
[download]

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).

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.