Feed on
Posts
Comments

In this latest in the DoubleDawg series, we see that GeePaw is basically just never satisfied.  It’s always pick pick pick with him!

The After Code for Step 4 (1290)

Get the Flash Player to see this content.

The After Code for Step 5 (1211)

Previous DoubleDawgDare

Next DoubleDawgDare

10 Responses to “DoubleDawgDare 5: Pick, Pick, Pick”

  1. EricSchaefer says:

    The result of this session looks very much like the text book case of a Visitor, doesn’t it?

    • GeePawHill says:

      The double-dispatch provided by Visitor would be nice, though we can’t really add methods to the annotation-derived class, and we’d need a ‘VisitMe’ method. I think of Visitor as being always applied to tree-like structures, but of course it can operate on any heterogeneous collection.
      What if we had an adapter around the annotation and *it* had the VisitMe call? That would feel good if we didn’t have to write an adapter for every annotation. Will think on it.

      • Jeff Grigg says:

        Looking through the class, I too have a very strong feeling that I would create a wrapper class for each annotation class, give them a common abstract base class, and then use reflection to find and create them and dispatch to them.

        [Sorry; replied to wrong thread with previous post.]

  2. Keep them coming… Faster. Faster

    Question: How long does it take you to produce the cast?

    • GeePawHill says:

      Altogether it takes around six or seven hours. The first hour is usually all I need to decide where the refactorings are headed. Then I make the video. Oddly, I can’t seem to rehearse: if the camera isn’t rolling I don’t have the tingle of fear that gives me energy! I usually shoot about three times before I have something I like. Editing the video takes about two hours. That’s just editing for sound, I don’t re-organize the content or change what I’m doing. Friends at IL are happier with a “shoot-a-llitle-edit-a-little” approach, but I can’t seem to make that work for me.

      It’s fun to do. This one’s hard because of the damned annotation stuff: we could trivially move the handlers onto a tree of handlers if we could just control how the annotation is derived. A little extra challenge. :)

      • Jeff Grigg says:

        Looking through the class, I too have a very strong feeling that I would create a wrapper class for each annotation class, give them a common abstract base class, and then use reflection to find and create them and dispatch to them.

  3. Jeff Grigg says:

    I notice that…
    Validation -> processValidationPlural
    Validations -> processValidationAnnotationSingular
    (annotation name -> goes to -> method name)

    So “Validation” is Plural, while “ValidationSSS” is Singular?

    To be more consistent with the other methods, I would probably call them “processValidation” and “processValidations”.

    • Jeff Grigg says:

      I noticed that the code in the “processValidationAnnotationSingular” method contains copies of the code in nearly all of the other “process*” methods. (Everything except DoubleRangeFieldValidator.) I would suggest deleting the unnecessary null checks from that code, and then for each “process*Validator” method, extract all the lines except the first into a method of the same name, and then inline the original method (back into the processSingleAnnotation method). I think you’ll like the effect this will have on the processValidationAnnotationSingular/processValidations method.

      • Jeff Grigg says:

        (I see that the code duplication in the “processValidationAnnotationSingular” method was introduced when you did the “process*Annotation” inlines. Darn; I hate it when I do things like that! 😉

Leave a Reply

AWSOM Powered