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

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

Expand Messages
  • 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 1 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
      * 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 Feathers mfeathers@...
      Object Mentor Inc. www.objectmentor.com
      "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.