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

Re: [XP] Pattern Encoded Suffix

Expand Messages
  • Chet Hendrickson
    Hello MarvinToll.com, It is interesting that this discussion began with a reference to Beck s Implementation Patterns. While my copy does not fall immediately
    Message 1 of 191 , Aug 9, 2012
    • 0 Attachment
      Hello MarvinToll.com,

      It is interesting that this discussion began with a reference to Beck's Implementation Patterns. While my copy does not fall immediately to hand, I have had the great fortune to code with Kent over an extended period of time. One naming rule that came up time after time was the avoidance of abbreviations and contractions. If you were to look at the C3 smalltalk source code, you would see 'socialSecurityNumber' and not 'ssn' or 'socSecNum". Even in the days before code completion, we found that the effort to type the unambiguous and complete name was overwhelmed by the multitude of mental transformations abbreviations require.

      So let us dispense with BookingBO.

      Another important rule is that objects should be named for how they are used and not how they are implemented. Your article seeks to encode into the class name information about what was in your mind when you wrote the class. This is a good thing to do. However, as authors we want to provide information only if it will effect how the receiver is likely to act. I noticed in your quotation from Implementation Patterns, you did not include the line in which Kent said he used the name of the pattern we wrote on his card as the root of his class's name. My guess is that if that line existed you would have.

      My experience tells me that if I need to know that if the object instance I am collaborating with implements the BusinessFacade pattern there is a very good chance that something as gone horribly wrong.

      I seem to recall another thread on naming classes using pattern names earlier this year that came to sort of the same conclusion.

      chet

      Thursday, August 9, 2012, 4:21:43 PM, you wrote:



      Charlie,

      Presuming a Pattern Palette is for a single team... (let's not get side-tracked with the enterprises are evil stuff)

      And the Palette as it stands today has 21 patterns... are you comfortable with:

      BookingBusinessObject
      ManageBookingBusinessFacade
      PersistenceResourceFacade
      ParsingStatefulException

      vs.

      BookingBO
      ManageBookingBF
      PersistenceRF
      ParsingSE

      ???

      Said another way... I find it easier to read the class name when the Patterns are distinct but available. That is, I only "decipher" the pattern when needed.

      The good news, from my perspective, is that we agree on having a suffix. And, I happen to be open to multiple styles of selection and encoding.

      The bad news, from my perspective, is that some in our profession don't agree class pattern suffixes are useful for an author or a reader.

      _Marvin
      http://PatternEnabled.com

      --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@...> wrote:
      >
      > My guidance (to myself and my teams) for this sort of thing is...
      > 1) Pick a suffix that makes sense to you and everyone else on the team
      > 2) Don't use an abbreviation
      > 3) Don't make it a "standard" or "requirement"
      >
      > Charlie
      >






      --
      Best regards,
      Chet Hendrickson mailto:lists@...
      Check out our upcoming CSM Plus courses @
      http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28

      [Non-text portions of this message have been removed]
    • MarvinToll.com
      Jeff, Thanks for your feedback. The notion that a a Java author precisely considers whether they are using one of the two exception mechanisms to indicate a
      Message 191 of 191 , Sep 23, 2012
      • 0 Attachment
        Jeff,

        Thanks for your feedback.

        The notion that a a Java author precisely considers whether they are using one of the two exception mechanisms to indicate a true unanticipated exceptional break-down, or as an indication of alternate path processing (e.g. instead of return codes), is the thought-path I'm suggesting for consideration.

        As you mentioned (twice), there are contexts where the author could be wrong... and the code catching can respond as required.

        Said another way, I'm suggesting that authors throwing exceptions clarify the intended usage... even though a client's corner-case might warrant a different course than the author anticipated.

        _Marvin
        PatternEnabled.com

        --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
        >
        > The code that throws an exception should not (and cannot reasonably) know how the code that catches it will handle it. It's the responsibility of the code that catches the exception to do the right thing.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.