I just read the following article by Allen Holub, Building user interfaces for object-oriented systems, Part 1 where he talks about designing an OOUI: object oriented user interface. In it he espouses the idea that the MVC paradigm is fundamentally broken, atleast in an OO manner, because the view needs tight coupling to the model. ( Forgive me if I have these terms backwards, I'm not all that sure which part is which ).

Basically he argues that if the view needs to get say, the 'name' attribute from the object, it knows to much about the object. Instead you should have all the display details hidden with in the object and simply ask the object to do things for you, in other words, instead of saying 'give me the name, salary and age so I can display them' you just say 'display the name salaray and age'.

While this idea sounds nice and encapuslated to my mind, after reading it I was immeadiately struck with the problem "What about multiple views"? What if your object needs to be displayed as sound for blind people as well as text for non blind people? Do you code the intimate details of how to display sound AND text in every single object you create? A simple 'display as text' or 'display as sound' which takes a string or something would seem to be much simpler. But this violates the fundamentals of object design, at least according to the article.

At the end of the article he seems to respond to this criticism with the following text:

Gripe #2. Different views into the same object
The other bugaboo that I want to put to death is the notion of different views into the same object, usually characterized by the question: "Suppose you need to display this data as a pie chart over here and a grid over there? How can you do this if the object displays itself?"

Now let's get real. How often in your work has this problem actually come up? In talking about object-oriented architectures for the user interface to many hundreds, if not thousands, of programmers, only two or three have ever raised their hands when I asked that question. If I need a generic presentation program that has no notion of what the data means, I'll go buy a copy of Excel or Quattro Pro. I won't write a program. The fact is that data has meaning -- it's not just an arbitrary collection of numbers. For a given set of data, I would argue that that there is only one "best" way to represent it for a specific problem domain. If there's no "best" way, then just settle on one "good" way. This degree of flexibility is rarely required. In any event, it is possible for an object to display itself in different ways without violating its integrity. I'll talk about how to do just that in a forthcoming column.



It seems to be that he's arguing multiple views aren't necessary because nobody ever uses them? But in my example above it was trivial to think of two different views that may be critical to an applicaton (for whatever reason) and I'm sure anyone could easily think of a few more that might be needed. So my question/meditation on this is: Do you agree with what he's saying? Have you found in your work that most of the time objects only need to display themselves in one way? Of course maybe this is a case of 'specific strategies for specific situations' but he seems to be arguing that this model is appropiate for all development.

Edit by castaway: Marked 'OT'.

In reply to (OT) OOUI: multiple views in an object. by BUU

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.