Re: Eliminating special cases - a case study

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 12/06/03

  • Next message: Phlip: "Re: Eliminating special cases - a case study" 
    Date: Sat, 06 Dec 2003 20:16:04 GMT

    Responding to Phlip...

    >>True, which is why this solution is not a good OO solution...
    >
    >
    > When judging two designs you cannot claim one's better because it more
    > closely models the real world in objects.

    For OO development one can and should. OO is based upon abstracting the
    problem space and OOA is /exclusively/ based on doing that...

    >
    > I suspect your design is better, anyway.
    >
    >
    >>The problem arises when one models the tableau in terms of a "deck of
    >>cards" having suits and ranks. Try separating the tableau structure
    >>from the deck of cards and model the Tableau in terms of slots rather
    >>than Cards. Now Slot.value can have the data domain of {0, card value)
    >>and Slot.color can have the data domain of {Red, Black, Background}
    >>while Card.value has the data domain of {card value} and Card.color has
    >>the data domain of {Red, Black}.
    >
    >
    > However, this design also does not more closely model the real world.

    It models the real world of the solitaire problem space. Where does the
    notion of 'tableau' come from, if not that real world? I could have
    used Layout, but that would not have been so well tied to the specific
    problem space.

    Remember, real world == problem space in OO development. The computing
    space is also real world from an OO viewpoint when abstracting something
    like a GUI paradigm into Window/Control. Similarly, mathematics is real
    world if one is abstracting computational methods. And hardware is a
    real world if one is abstracting for device drivers.

    >
    >
    >>Now the rules for validating playing a Card to a Slot (i.e.,
    >>instantiating the relationship) are exactly the same for all situations
    >>of current Slot occupancy, just like the Naught/Emerald approach.
    >
    >
    > While modeling the cards as values instead of objects would of course have
    > occurred to me, I don't know if this solution isn't just isomorphic to the
    > other one, with similar behavior applied to different structure.

    But I wasn't modeling cards as values; I modeled them as Cards, which is
    pretty straight forward. The real abstraction lay in abstracting --
    separately -- the structure of the layout. A Card is something with a
    value and color that gets assigned to a Slot, which also happens to have
      a value and color.

    It isn't isomorphic because the data domains of 'value' and 'color' are
    different for Card and Slot in my version so they are asymmetric.

    >
    > But one should credit a design for how well it works and - to a much lesser
    > extent - how well its programmers understand it. Not whether it avoids hokey
    > objects not found in the real world, or whether the design supports
    > potential re-use into features not yet requested.

    My counter is that the closer one maps the software to the problem
    space, the more understandable it will be. (More precisely, the more
    communicable it will be.) That's because the lingua franca among
    developers has to be their domain expertise. As developers come and go
    over the software life cycle the one invariant is a common perception of
    the problem space. So any deviation that represents a particular
    developer's unique vision or interpretation introduces long-term risk,
    no matter how elegant and sound it may seem at the time.

    >
    > I understand perfectly well you are more capable of holding an object model
    > in your head than most. So could _your_ design become even simpler, for
    > Solitaire alone, if you added to your values the Naught rank and Emerald
    > suit?

    If you want to do simple, elegant, and intuitive, then do functional
    programming. If you want to do robustness in face of volatile
    requirements over time, then do OO programming. Simplicity is not a
    virtue in itself and when one counts the LOC in an OO application versus
    the LOC in an FP application, it becomes painfully obvious that OO is
    not the simplest way to implement software solutions.

    I have no problem with XP's simplest-possible-thing mantra /provided/ it
    is qualified with being sound OOA/D practice. Properly abstracting the
    problem space with separation of concerns, etc. is part of good OOA/D
    practice and, IMO, takes precedence over simplicity.

    For example, I routinely introduce classes and is-a relationships for
    the sole purpose of eliminating conditional relationships. That's
    because navigating conditional relationships requires additional
    /executable/ code in every navigation context and I am quite happy to
    pay the price of dozens of extra /declarative/ lines for defining a
    class to eliminate those executable lines. Why? Because it makes the
    program more robust (relationship management is always done in one
    place) and reliable (defects are directly proportional to executable
    LOC). [No, I don't eliminate /all/ conditionals. B-)]

    Note that XP doesn't really believe simplicity is a virtue in itself
    either. When one refactors to get a nice DAG, one routinely adds
    classes, relationships, and code to support them. So one doesn't end up
    with the simplest possible implementation. All XP is doing is using
    disciplined refactoring to add complexity that makes the code more
    maintainable. I submit that good OOA/D abstraction does the same thing;
    it adds complexity within the discipline of problem space abstraction.
    I further submit that when you do your CRCs you should be doing them in
    a classic OOA/D fashion.

    *************
    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.pathfindersol.com
    (888)-OOA-PATH

  • Next message: Phlip: "Re: Eliminating special cases - a case study"

    Relevant Pages

    • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
      ... In practice the problem space entities that are being abstracted are usually conceptual. ... Objects are really quite limited in abstracting the problem space because they are limited to knowledge and behavior properties. ... but, alas, prior to some of the design changes made in Java 2, it was not so ... If one encounters a new problem domain, it is easy to add a subsystem for that subject matter. ...
      (comp.object)
    • Re: Is a credit card needed to become a seller?
      ... the countertops screws up the magnetic strips on the cards, ... It's bad design and bad customer service to blame a problem like this ... which discusses bad computer system design, ... a place to set cards. ...
      (alt.marketing.online.ebay)
    • 1100d Size Error: Common Problem?
      ... old Canon BJC-4300. ... If you design ... Exporting it as a TIFF to Photoshop 6 wound up with the same ... card, thus after the first two rows of cards, it would be severely out ...
      (comp.periphs.printers)
    • Re: WMATA crash & track circuits
      ... Then how on earth did you get away with 10 years service life designs? ... You can not design for a single source ... quite likely that such cards will not be in production after a few ...
      (sci.electronics.design)
    • Re: Switching alarm system - can I convert my database?
      ... belongs to you. ... you copy his design and market it. ... and sort cards using metal rods. ... the property of Cardex. ...
      (alt.security.alarms)