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

Re: [XP] Digest Number 1148

Expand Messages
  • C. Keith Ray
    ... Always passing three (or two) arguments around to various functions could be a code smell... should these three (or two) values be an Object? If so, then
    Message 1 of 1 , Jun 7, 2001
      > Subject: Interface
      >
      > Recently we've had a few interface problems. We find that we need to pass
      > two things instead of one, for instance, and this causes a ripple effect
      > that changes a large part of the program. One of the team members, the one
      > who likes XP the least, keeps saying that if we did some BDUF we would have
      > solidified our interfaces and wouldn't be having to fix this stuff. I
      > don't believe that because we wouldn't be any smarter a few months ago and
      > we wouldn't have had the code to tell us we needed to change the interface.
      >
      > But the problem still remains: How can we minimize the change to
      > interfaces? Switching to Smalltalk is not acceptable; we're stuck with
      > C++. Assuming we are using a staticly typed language with constantly
      > changing requirements, what's the best way to keep our interfaces stable?

      Always passing three (or two) arguments around to various functions could be
      a code smell... should these three (or two) values be an Object?

      If so, then do the appropriate refactoring. If another member needs to be
      added to an object, that doesn't require refactoring all those parameter
      lists...

      Those of us who have to do C++ as well as Java, are beginning to get jealous
      of those (free and not-free) refactoring tools that are available for Java,
      but not available for C++. According to product literature I read a few days
      ago, some tool (name escapes me) should reduce the time needed to do a
      refactoring from minutes down to seconds, even if a large amount of code
      needs to be changed.

      Having to a refactoring manually tend to make me want to avoid "small step"
      refactorings and do less frequent "large step" refactorings, which can be
      more error-prone.

      ----

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