Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
It sounds like you have a reasonably good grasp of how objects can be used, but I think you are missing some of the finer points of using objects.

I recently used objects to much success in a math API. The use of objects allowed me to create "super data types" which both needed to be opaque to the user and also required complex operations which weren't usually available from the standard datatype.

I'll illustrate a couple cases.

First, let's describe the project as abstracting lots of math operations on lists of time-aligned numbers. Sure, this could be done with an array of hashes like:

my $series = [ { $timestamp => $value } # ... ];
But you still need to be able to provide operations on those values. The example being when I want to pull "all the values" or "all the timestamps" out of the object. You could use map here pretty easily, but you'd have to replicate that code every time.

When the code gets more complex, like "how do I add all the values from stamps X, Y, ... from two sets of values?", you quickly start needing to come up with componentized code.

How about the actual data in the objects? Another benefit of having objects is you ensure everyone is using the API the same way. You provide "gettrs" and "settrs" for your API, so hopefully your users are not manually pulling data out of the objects (see Ovid's "thou shalt not covet thy objects internals"), and if you change the methods behind the magic, the users won't notice.

Additionally, by abstracting away the guts of the object, you get niceties like immutable values:

my $obj_template = { values => [ sub { 0 }, sub { 3.14 }, sub { 5 }, ], # ... }
In this case, even if the user dumper()'s our values, they can't see what they are, and you force them to actually use your methods (go on, give it a try).

Furthermore, by using objects, you can change the way math actually works. Lets say you want to have a switch that adds .0000092 on particular platforms because of a bug you know in that platform. When you have methods that do the work for you, you can have intelligence in the methods that the user doesn't have to know about, or might not understand. For them, they still have $obj->series_add( $another_obj ). They don't know what's going on, and that's generally what people who write robust API's hope for.

The last thing that I want to hit on is the fact that you can use a module like Params::Validate to incorporate testing into each and every operation your code uses. Cases you never expected to occur can and will occur in the code that uses your code, and your tests will spit out what went wrong, and give you a very good idea of where the bug is. (this of course doesn't take into account that having P::V in your objects will allow you to autogenerate documentation from the validate() and validate_with() calls, and make your code oh so much nicer to work with)

OOP is usually a little more of a headache (I'd estimate it takes me another 15-20% more coding time up front), but the payoff is huge in the end. Users aren't mucking about with your datatypes, fixes to code are visible in all code which uses your API, and it lets you really set a "substrate" for which others will develop their applications upon. I personally always take that performance hit up front just so I have a better environment to work with down the road.

zomg, deprecated

--
Tilly is my hero.


In reply to Re: The Power of Objects by deprecated
in thread The Power of Objects by Mutant

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • 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.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2024-04-19 22:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found