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

RE: [XP] Re: Interface

Expand Messages
  • Tom_Copeland@realeum.com
    Hey, that s pretty cool! I definitely agree about the constructor thing - I ve been able to sort of migrate people away from old code by putting in a new
    Message 1 of 5 , Jun 7, 2001
    • 0 Attachment
      Hey, that's pretty cool! I definitely agree about the constructor thing -
      I've been able to sort of migrate people away from old code by putting in a
      new constructor, leaving it alone for a week, letting everyone start to use
      it, and then deleting the old one. Usually there are only a couple of
      leftover client classes to fix. Which is nice.


      Tom Copeland

      "Arrizza, John"
      <john.arrizza@ma To: "'extremeprogramming@yahoogroups.com'" <extremeprogramming@yahoogroups.com>
      rconi.com> cc:
      Subject: RE: [XP] Re: Interface
      06/06/2001 04:32
      Please respond

      > -----Original Message-----
      > From: Tom_Copeland@... [mailto:Tom_Copeland@...]
      > That sounds kind of global-variable-ish, but er, well, it
      > seems to work fine for us....
      IMO it's only global-variable-ish if the member variables of the class are
      unrelated to each other. If they have some sort of conceptual cohesion,
      a correctly designed class.

      For example:

      old: void f1(int x, int y)
      int z = x * x + y * y;
      class myclass
      int func()
      return x * x + y * y;
      int x;
      int y;
      } ;
      void f1(myclass& obj)
      int z = obj.func();

      only makes sense if x and y in the original signature are related in a
      stronger way than the vacuous "x and y are parameters to f1()".

      I've used this fairly successfully when refactoring legacy code. I look for
      common signatures or parts of signatures, in a class's methods. I refactor
      the private methods first because it's safe and I can ignore the rest of
      code base while I concentrate on one class. A nice side benefit is the
      original class serves as a UnitTest as well as the UnitTest I write for the
      new class.

      Then I go through the public/protected signatures. This does cause a ripple
      effect but usually in a good way because it simplies a lot of the caller's
      code. For example, I tend to find that the caller's code also passes the
      same parameters around. I make those parameters a member variable of the
      class and a lot of the caller's code simplifies.

      The nice thing about the new class as well is I can control the ripple
      effect by having appropriate constructors on the new class. For example,

      class myclass
      myclass(int _x, int _y)
      : x(_x), y(_y)
      int x;
      int y;
      } ;

      When I want to stop the ripple, I just continue using the old signatures.


      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:

      Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
      see www.xpuniverse.com for details and registration.

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


      This email may contain confidential and proprietary information which is
      for the sole use of the intended recipient. If you received this email in
      error, please notify the sender and delete this email from your computer.
      Any review, distribution or retransmission of or reliance on this email by
      anyone other than the intended recipient is forbidden.
    Your message has been successfully submitted and would be delivered to recipients shortly.