Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Circle/Ellipse dilemma

Expand Messages
  • J. B. Rainsberger
    ... I didn t know that you were /not/ a fan of the pattern. I have just applied it in my current project and I m unhappy with the results. I have a DataStore.
    Message 1 of 120 , Dec 1, 2003
      Michael Feathers wrote:

      >>>I guess having more than one definition for a method is a kind of
      >>>duplication, eh?
      >
      > JBR> Yes, but it blows the Decorator pattern out of the water.
      >
      > I'm not advocating that but when you are driving it is nice to
      > know where the the pavement is slick.
      >
      > BTW, don't tease me with the chance to get rid of decorator again :-)

      I didn't know that you were /not/ a fan of the pattern. I have just
      applied it in my current project and I'm unhappy with the results.

      I have a DataStore. Now I want to audit what people do to the DataStore:
      when they perform CRUD operations. My first thought? An
      ActivityEvent-generating DataStore! Decorator!

      So I applied it. I TDDd the decorator and started using it, then
      something annoying happened: in all my EasyMock tests, there was this
      new method invocation: DataStore.addActivityEventListener(). This made
      10% of my voluminous test suite fail. Very annoying.

      Now the good news is that 90% of the failed tests used the same
      DataStore declaration, so my hack was to add the extra expected
      invocation in one place to fix those tests. I ended up having to do this
      in one place....

      ...but the problem is as you say: now the interactions are different,
      and the majority of tests -- the ones that don't care about listening
      for ActivityEvents -- were affected by a change when Decorator says "pay
      as you go and hardly anyone has to know that you're using one."
      Obviously, I have a design problem.

      So a question: is a Decorator not good here because it caused a problem?
      or is it good here because it exposed another design problem?
      --
      J. B. Rainsberger,
      Diaspar Software Services
      http://www.diasparsoftware.com :: +1 416 791-8603
      Let's write software that people understand
    • Keith Ray
      ... example of bad OO: class point { float x, y (and methods...) }; class circle extends point { float radius; (methods treat inherited x,y as center) };
      Message 120 of 120 , Dec 2, 2003
        On Tuesday, December 2, 2003, at 05:08 PM, Amir Kolsky wrote:

        >> Indeed, the data structure that represents an ellipse has too many
        > variables to efficiently represent a circle.
        >
        > Yup, and by virtue of the bad smell, we should know that there's
        > something immutably wrong with even trying to get to a circle by
        > subclassing ellipse...

        example of "bad" OO:

        class point { float x, y (and methods...) };

        class circle extends point { float radius; (methods treat inherited x,y
        as center) };

        class ellipse extends circle { point secondLocus; (methods treat
        inherited x,y as first locus) };

        class square extends point { float sidelength; (methods treat inherited
        x,y as top-left of square) };

        class rectangle extends square { float otherSideLength; (ad nauseum) };

        --
        C. Keith Ray
        <http://homepage.mac.com/keithray/blog/index.html>
        <http://homepage.mac.com/keithray/xpminifaq.html>
        <http://homepage.mac.com/keithray/resume2.html>
      Your message has been successfully submitted and would be delivered to recipients shortly.