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

Testing -> More procedural code? (Re: binary search, test first, by intention)

Expand Messages
  • J. B. Rainsberger
    ... ... I have that pattern. What I notice, though, is that if multiple methods have common parameter, then what I *really* want is a collaborating
    Message 1 of 2 , May 31, 2002
      > From: Mike Clark <mike@...>
      > Subject: Re: binary search, test first, by intention

      <snip />
      > It's interesting (to me, at least) that had tests for rangeNotEmpty
      > and midrange been written first, they may have taken the low and
      > high values as parameters, rather than using instance variables.
      > The use of parameters may have made these methods more testable, at
      > the cost of making them more procedural in nature. By starting with
      > a coarser-grained test for binsrch the object took on more state.
      >
      > I find that if I start off with finer-grained tests, my classes look
      > more procedural and there's little encapsulation. Starting with
      > coarser-grained tests generally leads me toward objects with more
      > encapsulated state.
      >
      > How does this compare with the experience of others?

      I have that pattern. What I notice, though, is that if multiple methods have
      common parameter, then what I *really* want is a collaborating object. In
      other words, if three methods add take a 'foo' as a parameter, then my object
      *really* wants a 'foo' in its constructor as a collaborator. The more methods
      that want to talk to a 'foo' (and almost always the same 'foo'), the stronger
      the desire to collaborate with that 'foo', rather than accept it as a method
      parameter.

      How might this apply to the binary search example? I'm not sure. I'd have to
      try it first-hand to see. I've never seen binary search implemented with
      instance variables; always with method-locals, so sadly it never occurred to
      me to write it as Ron did. :)

      Perhaps one would end up using a Range object for the "not empty" part,
      instead of instance variables representing the range's endpoints. Then
      there's no need for the test -- we already have a Range object in Ruby!
      --
      J. B. Rainsberger,
      President, Diaspar Software Services
      Let's write software that people understand.
      http://www.diasparsoftware.com/
      telephone: +1 416 791-8603
    • Ron Jeffries
      ... Yes. I actually decided /not/ to go there, because it was assuming more than I was pretending to know about binary search. The /real/ answer to binary
      Message 2 of 2 , Jun 1, 2002
        Around Friday, May 31, 2002, 11:25:59 AM, J. B. Rainsberger wrote:

        > Perhaps one would end up using a Range object for the "not empty" part,
        > instead of instance variables representing the range's endpoints. Then
        > there's no need for the test -- we already have a Range object in Ruby!

        Yes. I actually decided /not/ to go there, because it was assuming
        more than I was pretending to know about binary search. The /real/
        answer to binary search of an array in Ruby might be recursion and
        array slices, doncha think?

        Ron Jeffries
        www.XProgramming.com
        The Great and Powerful Oz has spoken.
      Your message has been successfully submitted and would be delivered to recipients shortly.