Re: Comparison and criteria of design quality

From: Dagfinn Reiersol (reiersol_at_online.no)
Date: 09/08/04

  • Next message: Universe: "Re: graph of behavior - was Re: State vs. Data (was Re: Fans of Template Method with protected variable?)" 
    Date: Wed, 08 Sep 2004 09:28:42 +0200

    H. S. Lahman wrote:
    > Responding to Reiersol...
    >
    >> I started thinking about this when watching relative beginners trying
    >> to do OO design. I'm trying to sort the various levels and types of
    >> critera.
    >>
    >> It seems to me that the single best way to learn design is to compare
    >> different designs that are intended to solve the same problem. At
    >> least that's my personal experience. One of the benefits of
    >> refactoring is that you naturally get a chance to do this kind of
    >> comparison, and that's a great learning experience.
    >>
    >> But in order to compare meaningfully, you have to know what to look
    >> for. How do you know that one design is better than the other? You
    >> obviously need some criteria. Oddly, none of the OO books in my
    >> bookshelf has a chapter or section on such criteria. But let's explore
    >> a little further.
    >
    >
    > The problem is that any criteria one comes up with, including all those
    > you cited, require that somebody make value judgments.

    You're right, that is the problem. And I'm trying to (begin to) tackle
    that problem by making it less of a value judgment. You believe
    that's...impossible? ...extremely difficult?

    >If the person
    > making the value judgment lacks experience and depth, the judgment will
    > have little value and won't help the learning process.

    To different degrees, though. Readability and simplicity are somewhat
    subjective but anyone can make the judgment. And your judgment will
    improve with practice. Spotting duplication is also extremely easy in
    many cases. So I think these criteria, which are the ones Fowler focuses
    on in his Refactoring book, are a good start for a (relative) beginner.

    Anyway, making the difference between criteria and the techniques used
    to satisfy them is important, or inexperienced programmers will think
    they will achieve bliss by implementing as many design pattern as possible.

    >
    > IMO the best learning process is mentoring and review by someone
    > competent. [They used to call such people teachers, I think. Maybe
    > consultants. B-)] If they can convince the author of a design that
    > there is a better way to do it, then <hopefully> the author has learned
    > something. The key is explaining /why/ the alternative is superior to
    > the author's satisfaction.

    There is also the issue of the author deliberately keeping an open mind
    about it. I think this is a somewhat overlooked issue in software
    engineering. In books about problem solving in general, you'll find the
    advice to avoid choosing an alternative too early. It's a bad idea to
    fall in love with a design before you've considered alternatives (and I
    would say to the point where you can list the pros and cons explicitly).

    >
    > [BTW, I happen to be a fan of refactoring dating from the late '70s when
    > it wasn't at all fashionable -- but for entirely different reasons. The
    > question I would ask in this context is: If refactoring really improved
    > the design (as opposed to simply converting the code into a DAG), why
    > wasn't it designed that way in the first place? That is, if one
    > couldn't recognize the superiority of the design initially, how can one
    > expect to recognize why it is superior after refactoring?]

    The answer that seems obvious to me is that superiority is relative.
    Superior to what? You can't tell whether something is superior or
    inferior without comparing it to something.

    >
    >
    > *************
    > There is nothing wrong with me that could
    > not be cured by a capful of Drano.
    >
    > H. S. Lahman
    > hsl@pathfindermda.com
    > Pathfinder Solutions -- Put MDA to Work
    > http://www.pathfindermda.com
    > blog (under constr): http://pathfinderpeople.blogs.com/hslahman
    > (888)-OOA-PATH
    >
    >
    >
    >

  • Next message: Universe: "Re: graph of behavior - was Re: State vs. Data (was Re: Fans of Template Method with protected variable?)"

    Relevant Pages

    • Re: Comparison and criteria of design quality
      ... > that problem by making it less of a value judgment. ... today one is dependent on applying the methodology de jour correctly. ... than it is to evaluate whether a particular design is good. ... >> superior to the author's satisfaction. ...
      (comp.object)
    • Re: Filter Sort Annoyance
      ... If your selection criteria change, ... use the same query and modify it by changing the selection criterion. ... I'll suggest that further normalization may be needed. ... In a well-normalized data design, ...
      (microsoft.public.access.tablesdbdesign)
    • Re: List Box Search
      ... When in query design view, get the original table, add the fields required ... The other thing you need is some way to have the listbox retrieve a new set ... of records everytime you change your criteria. ... > I have a form with a list box on that lists specific ...
      (microsoft.public.access.forms)
    • Re: C#Builder Or Delphi 8?
      ... design which basically *defeats* the advantages of that design. ... The trick is to *require* them to enter reasonable search critieria, ... incremental searching. ... They need to enter criteria and hit a Search button. ...
      (borland.public.delphi.non-technical)
    • Re: Normalizing Tree Data
      ... I'm more interested in simplicity vs speed. ... edit/delete any of the nodes in the tree. ... I'll again reiterate that there are a number of design criteria (some ...
      (comp.databases.theory)