in reply to Re: Re-blessing || Re-constructing objects
in thread Re-blessing || Re-constructing objects

I can't see why this facade aproach is a better solution other than because it doesn't rebless objects.

In Perl 5, blessing is just a way to attach a dispatch table to some data structure. If I want my data structure to behave differently at different points in time the obvious solution is to change its dispatch table accordingly, so reblessing it.

  • Comment on Re^2: Re-blessing || Re-constructing objects

Replies are listed 'Best First'.
Re^3: Re-blessing || Re-constructing objects
by perrin (Chancellor) on Apr 18, 2006 at 11:16 UTC
    I suppose you could say that all OO is just a way to attach a dispatch table to some data structure. However, the other classes are not supposed to need to know what the actual data structure is, since they access it through methods. If you re-bless an object, your code (the part that does the re-blessing and the class you re-bless it into) will now break if the internals of the original class break, even if the API doesn't change.
      no, please, don't misunderstand me, I am not advocating into reblessing objects wildly from one class into another. I am just saying that doing it in a controlled manner is an useful mechanism and it can be used without breaking encapsulation or any other OOP property.

      Those controlled manners are at least two:

      • Reblessing an object into a descendant class of its current class. For instance, when you get new information about the object (BTW, in C++ this is done all the time under the hood at object construction time).
      • using several packages to implement a unique class that can change its behaviour dynamically, for instance:
        class TheHulk; sub new { bless $self, $class; $self->go_normal; $self; } sub go_normal { bless $self, TheHulk::_normal; } sub go_green { bless $self, TheHulk::_green; } sub relax {} sub make_angry {} package TheHulk::_normal; sub run { ... } sub make_angry { $self->go_green; } package TheHulk::_green; sub run { ... } sub relax { $self->go_normal; }
        three packages are used, but conceptually is just one class, so there is no messing with the internals of one class from another and the reblessing is always done from inside the class not from the outside.
      • any other?

        I am just saying that doing it in a controlled manner is an useful mechanism and it can be used without breaking encapsulation or any other OOP property.

        Well said. Just because something is dangerous doesn't mean it can't be used in a positive way.

        ---
        $world=~s/war/peace/g

        It can't be done without breaking encapsulation. All of your examples require a class to know all about the internals of some other class. You may decide that's okay in your case, but it still loses the abstraction.
Re^3: Re-blessing || Re-constructing objects
by dragonchild (Archbishop) on Apr 18, 2006 at 11:59 UTC
    To paraphrase perrin, all I have to do is depend on the public (i.e., documented) API. I don't have to depend on how the object is implemented.

    I think the disconnect between how you're looking at things and how I am looking at things is I see OO as a set of behaviors that, when necessary, has some data to support those behaviors. You're looking at it as a data structure that may or may not have some behaviors associated with it. That's a pretty big disconnect.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?