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

[extremeprogramming] Methods should be public (Test First Design)

Expand Messages
  • Frank Westphal
    ... Michael, just curious: What s your most recent view on your (former) perception that MethodsShouldBePublic? Do you refactor? Or do you mark as private?
    Message 1 of 2 , Jan 6, 2000
    • 0 Attachment
      "Michael C. Feathers" wrote:
      >
      > ----- Original Message -----
      > From: Frank Westphal <westphal@...>
      > >
      > > Not a fundamental design concept, but my classes got smaller.
      > > Here's why: If you want to test your classes ruthlessly, and
      > > you can't get at the private parts of a class, you refactor
      > > and extract a class with the former private methods to be
      > > publicly accessible. You end up with lots of little pieces,
      > > the benefits thereof are manyfold.
      >
      > Yeah, I have that happen too. This is one of the things
      > which makes me cringe when I hear people talking
      > about XP testing vs. every other testing scheme out
      > there; the fact that the tests themselves are only
      > part of what injects quality. [...]

      Michael, just curious:

      What's your most recent view on your (former) perception that
      MethodsShouldBePublic? Do you refactor? Or do you "mark" as
      private? I kind of HaveThisPattern more and more.

      Frank
    • Michael C. Feathers
      ... From: Frank Westphal ... Package scope solves the problem for me in Java. In C++, I ve been pragmatic. Here is my heuristic: *
      Message 2 of 2 , Jan 6, 2000
      • 0 Attachment
        ----- Original Message -----
        From: Frank Westphal <westphal@...>
        > Michael, just curious:
        >
        > What's your most recent view on your (former) perception that
        > MethodsShouldBePublic? Do you refactor? Or do you "mark" as
        > private? I kind of HaveThisPattern more and more.

        Package scope solves the problem for
        me in Java.

        In C++, I've been pragmatic. Here is my heuristic:

        * Since I write test-first, member functions
        usually start public.
        * If I break down a member function into
        sub-functions, I'll often make them private
        if I feel that the cases for the original function
        suffice.
        * If I notice, as I often do, that a function should
        be private, I'll make the test class a friend.
        * I'll admit that I do leave some functions public
        because I never get around to adding the friend.

        I think that if I were diligent about making
        everything not used private or protected, I'd
        notice a smell like "too much implementation"
        and refactor. But, I think that smell is pretty
        much subsumed by "too many methods and
        too much data." Kent talks about keeping
        classes and methods small and I like to
        see this as maintaining a high ratio of interface
        to implementation. It is hard to convince
        yourself that a large implementation is
        correct either by test or inspection.

        Re: MethodsShouldBePublic. Most of that
        was motivated by run-ins with
        OtherPeoplesFrameworks where privacy
        and non-virtual functions often limit reuse.

        On top of that peeve, I maintain that
        no one can tell me that use of some
        language features is absolutely necessary
        when they do not exist in some other
        commonly used languages. You can say
        the uses are good, but you can't say that
        they are necessary. The trade-off between
        problems avoided and refactorability
        probably has to be made on a feature
        by feature basis. In the case of access
        specifiers, the cost of change is pretty
        low, so I have the lazy-use policy above.
        I only say private or protected when
        I'm sure I mean it.

        I'd really like to see more discussion
        on those tradeoffs. Frankly, I think that
        many people are scared of questioning
        some of these language canons openly
        but we've already opened the door with
        the process canons.

        You know, it was very hard to write
        about privates in this post and keep
        it clean. Alas, some of my best
        writing fell into the gutter.


        Michael

        ---------------------------------------------------
        Michael Feathers mfeathers@...
        Object Mentor Inc. www.objectmentor.com
        Training/Mentoring/Development
        -----------------------------------------------------
        "You think you know when you can learn, are more sure when
        you can write, even more when you can teach, but certain when
        you can program. " - Alan Perlis
      Your message has been successfully submitted and would be delivered to recipients shortly.