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

Then I'd ask why you wrote this code as OO, since you aren't getting a major benefit of OO: abstraction.

Dont you think thats a bit extreme? Simply because you have tight coupling doesnt mean you have sacrificed abstraction. If you can even speak of such a thing in such a way. For instance tight coupling between two classes doesnt mean that you lose any interface abstraction on the objects themselves. If A and B are tightly coupled C need not even know or care about one of them, and treat the other as simply and abstract interface.

I think it really depends on which attributes of OO you think are most important. If you think that inheritance support is the objective then I can see why tight coupling of two classes would bother you. You can't easily subclass[1]. But if you are more concerned with interface abstraction then it makes no difference. And personally ive found that interface abstraction (polymorphism) is much more commonly depended on than inheritance. If you are sane you only subclass things are designed to be subclassable in the first place. Especially in perl.

[1]: This is not strictly true. If both classes defined a sister_class property that returned the other classes name, then the tight coupling could be overriden. If you wanted to subclass either youd have to subclass both. Or you could pass the other classes name back and forth as parameters. This would mean the coupling was a lot weaker. IMO whether it made sense would depend on the circumstances.

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

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

Replies are listed 'Best First'.
Re^7: Re-blessing || Re-constructing objects
by perrin (Chancellor) on Apr 18, 2006 at 11:07 UTC
    How can you have any abstraction between two classes if an existing object of one can be blessed into the other? That isn't using the public API; it's knowing the full gory details of the implementation. Otherwise, how could you know it would work to bless from one to the other?
[reply]

      If they both support the same interface it makes no difference to you. For instance you are told that you can use methods X and Y and both classes support the method.

      Its exactly the same idea when you have something that says "i can use any object that supports a print method to do output". It doesnt care about the class of the object, it cares about the interface of the object.

      As for the two classes knowing about each others internals well, thats just life. Do you think there is something wrong with File::Spec because it is tightly coupled to the File::Spec::OSTYPE modules? And do you think that File::Spec somehow presents a loss of abstraction? IMO thats a good example where a set of tightly coupled modules provides a clean abstraction layer.

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

[reply]
        No, we're not talking about clients of these classes, we're talking about the re-blessed classes themselves. They have no abstraction from each other's internals.

        If I want to make a print_document() method in class Spreadsheet and class WebPage, and sometimes re-bless Spreadsheet into WebPage, that means both classes have to implement print_document() to access the same internal data structures. You can't decide that WebPage would be better off storing things in a tree and Spreadsheet would be better storing them in a HoA, because one might magically become the other at any time, and your methods still have to work.

[reply]

In Section Meditations