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

[extremeprogramming] Re: Elves in the Night [Stupid XP Question Number 6614]

Expand Messages
  • Robert C. Martin
    Dave Thomas wrote in message news:m2iu1cyluc.fsf@zip.local.thomases.com... ... meta -prefix. I ... have ... for ... In ... Andy ... rather
    Message 1 of 38 , Jan 3, 2000
      Dave Thomas <Dave@...> wrote in message
      > schuerig@... (Michael Schuerig) writes:
      > > I, too, feel a bit uncomfortable with Dave's use of the
      "meta"-prefix. I
      > > don't think it's wrong, but it is different from what people who
      > > read stuff such as "The Art of the Metaobject Protocol" expect. I
      > > one expect something that's not specific to any particular domain.
      > > contrast, my understanding of the approach that Dave (together with
      > > Hunt in "The Pragmatic Programmer") advocates is such that I'd
      > > call it "Separate Mechanism From Policy". Only mechanism, that which
      > > needed by any application in the domain, is hard-coded; the specific
      > > application is a malleable layer on top of that.
      > That's a great characterization. Build nuggets of domain-specific
      > code, and knit them together to build the application you need at the
      > time. The only qualification I'd make is that often the lower level
      > ends up being domain independent. We've been dragging the same trace
      > routines around with us now for 5 years.
      > I guess on reflection it _is_ a kind of YAGNI--we're saying defer the
      > anything application specific as long as possible, and then make it
      > easy to change. So in spirit we're XPers, we just bend the rules...

      Building software in this way is often a good solution. But not always.
      Sometimes, perhaps even often, the best cost/benefit trade off is the
      direct solution. Unfortunately, the problem is not simply a binary
      decision. One cannot simply decide to go meta or not. Rather,
      portions of projects may benefit from a meta approach, while others may

      For example, Twenty years ago I worked on one of the very first voice
      systems. We had to be able to dial phone numbers to deliver voice mail
      messages. Dialling numbers is very tricky. The number you dial depends
      upon a whole set of complex criteria including: Your area code, the
      area code, whether you are behind a PBX, whether the target is an
      of that PBX, whether the target is on a different part of that PBX,
      there are special prefixes for certain exchanges, etc, etc, etc. There
      no way we could hard code all these rules. To make matters worse, the
      were different for every installation. So we created a nice little
      meta-language that let us write scripts for dialling numbers.

      Most complex systems are hybrids of meta and non-meta designs. We go
      when we need the flexibility and can afford the cost of the meta-design.
      avoid meta when the rules don't change often.

      XP is not anti-meta. It just puts a lot of tension in the decision.


      Robert C. Martin | OO Mentoring | Training Courses:
      Object Mentor Inc. | rmartin@... | OOD, Patterns, C++,
      PO Box 85 | Tel: (800) 338-6716 | Extreme Programming.
      Grayslake IL 60030 | Fax: (847) 548-6853 |

      "One of the great commandments of science is:
      'Mistrust arguments from authority.'" -- Carl Sagan
    • Robert C. Martin
      Tom Kreitzberg wrote in message news:387364E4.C0A3E6CC@jhuapl.edu... ... There is no fundamental difference between pre XP Object
      Message 38 of 38 , Jan 5, 2000
        Tom Kreitzberg <Tom.Kreitzberg@...> wrote in message

        > But I think "flexibility" means different things to XP and,
        > shall we say, pre-XP OMA. In XP, doesn't it primarily mean
        > once and only once? In pre-XP OMA, doesn't it primarily mean
        > OCP and low coupling? When I wrote that XP "is structured so
        > that inflexible designs are cheap to change," I meant inflexible
        > in this second sense.

        There is no fundamental difference between pre XP Object Mentor, and
        post XP
        Object Mentor except that we have identified XP as the process we like
        use. Even this is not a big shift for us, since XP is very similar in
        spirit and practice to the unnamed process we have used for years.
        are differences, certainly -- specifically in the areas of pair
        and test first programming; but these are differences in intensity, not
        philosophy. As for the rules governing simplity, the planning game,
        iterations, etc, we were very closely aligned.

        Flexibility means the same to me now as it did five years ago. The
        to add or change significant amounts of functionality while changing a
        minimum of exsiting code -- i.e. the OCP. OnceAndOnlyOnce leads to this
        goal just as the OO design principles do. It is my goal over the next
        several months to integrate the principles and XP.
      Your message has been successfully submitted and would be delivered to recipients shortly.