use Perl

• Chaining vs. Cascading (Score:2, Insightful)

  by dws (341)

  As I said last week on Perlmonks when this came up there, "chaining" is a poor substitute for "cascading". In a cascade, a designated object reference is guaranteed to be the recipient for all messages (invocations of member functions). Smalltalk syntax supports cascading. Perl syntax doesn't.

  Without first-class support for cascading, a simulated cascade (i.e., a chain) is hard to distinguish from a gross violation of the Law of Demeter.
  • Re:Chaining vs. Cascading (Score:2)

    by Ovid (2709)

    I don't really want to try and describe this in Smalltalk terms. This isn't Smalltalk and shouldn't be viewed as such. Even though the idea appears to come from Smalltalk, it's simply not the same thing as a cascade. That seems like saying for (@array) shouldn't be used in Perl because it's not an OO iterator. In this case, it would not be helpful to insist on a full implementation of the GoF Iterator pattern. It's certainly an iterator, but it's implemented in a Perlish way. The case of the chained
    • Re:Chaining vs. Cascading (Score:1)

      by dws (341) on 2003.06.20 15:19 (#21301) Homepage Journal

      Put simply, the Law of Demeter (LoD) says "You should only talk directly to your friends, and not to their friends." This reduces coupling, and simplifies testing. To test your code, the most you have to do is provide mock objects for your code's direct collaborators.

      Violations of the Law of Demeter are characterized by chains of method calls, where the target object changes along the way as the code reaches through its friends and into their friends (and perhaps into their friend's friends). Lots of coupling, and hard to unit test.

      Since chained mutators don't inherently rely on any other class, they don't violate said law.

      But can a reader tell that there's no violation without reading each and every method invoked in the chain to make sure that each method really is a mutator? No. When I encounter one of these constructs, I'm forced to do a lot of extra reading, just to make sure that somewhere in the middle some other object isn't injected into the chain.

      With first-class support for cascades, this isn't an issue. But by trying to fake a cascade (and that really is what you're trying to do), you're saying "trust me" to the code's readers, forcing those who don't trust you into extra work.

      Experience has taught me not to trust chains of method calls.

      Reply to This

      Parent