in reply to Still not getting it: hashref OO class variables

Referencing class data in an object method directly makes it hard to cleanly override the object method in a sub-class. How would you write an overridden wear_out_sole()? You'd have to access $num_holey, but can't because it's in a separate package scope. You solved this already in your class with incr_num_holey(), which is what the Fine Manual is trying to suggest.

All that aside, I think you'll find that it's pretty unusual to use class data in a real OO system. In cases where you've really got some kind of class-wide data I'd rather see that data modeled as an object of its own and give each object that needs it a reference to the object. This is a common pattern for configuration data, for example, which is also a common (poor) use of class data.

Another example: I've created in-memory caches in some of my modules using class data. These days I'd use something like CHI instead and give each object a cache handle, defaulting to a memory caching driver that behaves like a class data hash.

-sam

  • Comment on Re: Still not getting it: hashref OO class variables

Replies are listed 'Best First'.
Re^2: Still not getting it: hashref OO class variables
by bramble (Beadle) on Feb 15, 2008 at 00:52 UTC
    Referencing class data in an object method directly makes it hard to cleanly override the object method in a sub-class. How would you write an overridden wear_out_sole()?

    But it wasn't hard, and seems to work fine, as shown above in the original post (you might not've noticed that it was indeed overridden in the Boot class). Is there anything wrong with Boot::wear_out_sole in the OP?

    I think there's something I'm missing here. In your comment, are you implying that a subclass should be able to access class data (since a Boot *is*, after all, a Shoe)?

    All that aside, I think you'll find that it's pretty unusual to use class data in a real OO system.

    Yes, I think I'm noticing that. Thank you. The only example I ever see is when a class wants to keep a total of objects. And for something that simple, there are other ways of doing it (like just incrementing a global every time you instantiate an object, or counting rows in a db table, or keeping the objects in question in a list (then you know the length of the list)).

[reply]
      In your comment, are you implying that a subclass should be able to access class data (since a Boot *is*, after all, a Shoe)?

      Maybe not class data, but definitely class behavior -- and tracking the number of shoes in the system is behavior.

[reply]
        In your comment, are you implying that a subclass should be able to access class data (since a Boot *is*, after all, a Shoe)?
        Maybe not class data, but definitely class behavior -- and tracking the number of shoes in the system is behavior.

        Ah, ok. Then here is the crux of the matter: Should the subclass be able to access class behaviour as if that behaviour were a part of the subclass itself (since a Boot *is* a Shoe)? Or should the subclass simply access class behaviour via the superclass?

[reply]

In Section Seekers of Perl Wisdom