Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
He may reference Design patterns, but I suspect he had experience with flyweight objects before the movement developed. (Why else would he discuss flyweight objects the way he did.) Of course we wont know unless he tells us...

Only TheDamian knows :-)

Also, in case this isn't obvious, none of my comments are intended to be a criticism of the method presented in Object Oriented Perl. It's a fine and useful technique. I've used it myself. The only thing I'm querying is it being an instance of a flyweight pattern.

It seems to me that you are taking a little more prescriptive approach to what a flyweight object is than is perhaps justified.

Possibly. But the use of the term flyweight in Object Oriented Perl is the only one I have ever come across that isn't to do with removing context-dependent information to allow you to perform your task with fewer objects.

From what I can tell the central tennet is to reduce overhead by not duplicating data.

Let's review the definition of the flyweight pattern from Object Oriented Perl:

A less well-known approach to encapsulation uses scalar-based objects to implement a technique known as the flyweight pattern. In the flyweight pattern, objects don’t carry around their own information, so that information can’t be accessed directly via the object. Instead, flyweight objects merely serve as an index into a shared table of values, stored within the class itself. For example, an object may be an integer that indexes into a table of values stored as a class attribute.

So:

  • The number of objects stays the same
  • The state stored by each object stays within it's class
  • The state stored by each object remains the same. It's just stored in the class, rather than within the object.
  • The method is used to implement data-hiding

Note we are not removing any duplicate state. We are moving state from the object to that objects class.

The motivation for doing it is data-hiding, not reducing duplicate state.

From Overview of Design Patterns

If instances of a class that contain the same information can be used interchangeably, the Flyweight pattern allows a program to avoid the expense of multiple instances that contain the same information by sharing one instance.

(I think you do have to read that "allows" as meaning that objects are reused - otherwise it's just a null statement)

From Design Patterns

Using sharing to support large numbers of fine-grained objects efficiently
Some applications could benefit from using objects throughout their design, but a naive implementation would be prohibitively expensive ... A flyweight is a shared object that can be used in multiple contexts simultaneously ... Intrinsic state is stored in the flyweight; it consists of information that's independent of the flyweight's context, thereby making it sharable. Extrinsic state depends on and varies with the flyweight's context and therefore cannot be shared. Client objects are responsible for passing extrinsic state to the flyweight when it needs it.

Here we talk about sharing objects with the same state. The motivation is to reduce the overhead in having a multitude of objects.

So to recap, I personally think that the flyweight pattern as described by TheDamian is the closest published Perl OO model to what the design pattern guys would also call flyweight objects.

To me it is clear that the Object Oriented Perl Flyweight and the Design Pattern Flyweight are completely different beasts. Sorry :-)

They both describe useful things - but they're different.

However it is also my opinion that in Perl it is unusal to need the design patterns concept of a flyweight, and if the model offers other benefits then so be it. (In other words I dont think its that important..)

It no more or less unusal in perl to use flyweights (in the DP sense) than it is in any other language. It depends on what you're developing. It's not a language issue, it's a design issue.

To some extent it's pointless to argue about these definitions now. The particular implementation in TheDamian's book has become the accepted definition of a flyweight pattern in the perl world. I now understand what that definition is - and that's fine.

However, you will find flyweight pattern means something quite different to a big chunk of the rest of the world.

While calling a wrench a hammer doesn't stop it being a wrench, it can make working with others in a machine shop harder than it could be ;-)


In reply to Re^6: Flyweights - different meaning in perl? by adrianh
in thread Yet Another Perl Object Model (Inside Out Objects) by demerphq

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 contemplating the Monastery: (7)
As of 2024-04-19 06:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found