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

Re: [XP] Changing Interface or Implementation

Expand Messages
  • Ron Jeffries
    ... Yes, thanks. I agree. Would perhaps say that older classes tend to change less than younger, as well. Ronald E Jeffries http://www.XProgramming.com
    Message 1 of 14 , Sep 29, 2000
      At 04:12 PM 9/29/00 -0700, Salvatore Sferrazza wrote:
      > > In what way does refactoring classes avoid the need to change them? I don't
      > > understand.
      >
      >it doesn't avoid the need to change them, but in a well evolved system
      >classes at the top of the hierarchy seldom change, no? i really like
      >the principle that in order to add functionality to an system you don't
      >change code, you extend existing code. if a team has been continuously
      >refactoring, then the classes @ the top of the hierarchy shouldn't be
      >affected by changes in requirements as things on the bottom are.
      >
      >clearer?

      Yes, thanks. I agree. Would perhaps say that "older" classes tend to change
      less than younger, as well.



      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com
    • John D. Mitchell
      ... [...] ... I actually try to judge a class s maturity . In this regard, younger classes do strongly tend to be less mature than older classes. Some loose
      Message 2 of 14 , Sep 29, 2000
        >>>>> "Ron" == Ron Jeffries <ronjeffries@...> writes:
        [...]
        > Yes, thanks. I agree. Would perhaps say that "older" classes tend to
        > change less than younger, as well.

        I actually try to judge a class's "maturity". In this regard, younger
        classes do strongly tend to be less mature than older classes.

        Some loose criteria that I use to judge maturity are how many different
        uses of the class are there, how well is it tested, how many people have
        validated it, how much it's run, etc. and last, but certainly not least,
        how often is it/has been changing. Nothing scientific about this at all.
        Just a bunch of difference perspectives that add to the confidence level of
        that component.

        It's a nice, fast way to think about existing code and the general level of
        effort needed to be able to apply to different types of solutions. I.e., I
        might have whipped up a quick and dirty class as an example for an article
        so I know that a lot more work/examination/etc. needs to be applied to that
        class to even consider using it in e.g., a production environment.

        To use a biological analogy, I (loosely) subscribe to the notion that these
        changes are like the notion of punctuated equilibrium in evolution. But
        then again, I'm also big on interfaces as contracts.

        Take care,
        John

        --
        John D. Mitchell
        jGuru.com -- Today is a Great Day to Code!
        NoWebPatents.org -- Stop Patent Stupidity!
      • Michael C. Feathers
        ... Yes, this is a statement of the open-closed principle (OCP). We have papers about it on our website. The interesting thing to notice is that you don t have
        Message 3 of 14 , Sep 29, 2000
          > At 04:12 PM 9/29/00 -0700, Salvatore Sferrazza wrote:
          > it doesn't avoid the need to change them, but in a well evolved system
          > classes at the top of the hierarchy seldom change, no? i really like
          > the principle that in order to add functionality to an system you don't
          > change code, you extend existing code. if a team has been continuously
          > refactoring, then the classes @ the top of the hierarchy shouldn't be
          > affected by changes in requirements as things on the bottom are.

          Yes, this is a statement of the open-closed principle (OCP).
          We have papers about it on our website.

          The interesting thing to notice is that you don't have to explicitly
          strive for that sort of closure. If you separate responsibilities
          well, and continually remove duplication, you end up with areas
          of code which don't change as much.

          I think that the most important thing, for people who
          are used to thinking in terms of OCP, is not to rush it.
          If you start to think that you are a bad designer whenever
          you have to modify a superclass, you'll go nowhere fast.
          Many refactorings break down old interfaces into parts
          and create new ones. This is natural. As your code
          breaks into smaller pieces, you'll have to modify fewer of
          them.

          Michael

          ---------------------------------------------------
          Michael Feathers mfeathers@...
          Object Mentor Inc. www.objectmentor.com
          XP & OO Training/Mentoring/Development
          www.xprogramming.com / www.junit.org
          ---------------------------------------------------
          "You just keep going all the way, as deep as
          you can. You keep trying to get right down
          to the crux." -- John Coltrane
        Your message has been successfully submitted and would be delivered to recipients shortly.