What I meant was, this separation of UI and object isn't necessarily all its cracked up to be and just winds up relocating the coupling issues to exist across different levels of abstraction. Acknowledging this and putting the coupling where (the author believes) it belongs is the point of the articles.

Very well. I happen to disagree. I'm in a project right now that requires different data to be viewed in different forms. One part of this application deals with generating reports for users. They might output an Excel spreadsheet or a pipe-delimited file or some HTML or a PDF. I cringe at the thought of attempting this by following the author's advice. By having the data stored in one object (which you can call a fancy data structure if you want) and given to a subclass of a ReportGenerator object solved this problem quite elegantly for me.

Many of his examples (like "what if we want to change the method to return a float instead of an int?") could be avoided by using a dynamically-typed language. What particularly bugs me is this statement:

Moreover, an attribute doesn't necessarily map to a field in the class. The salary might be stored in an external database, for example, with the Employee storing only the information needed to retrieve the attribute from the database . . . What, then, could a get_salary() function return?

Easy: the get_salary() does the database access for you and returns the result instead of some private variable. That's why you have accessors/mutators in the first place instead of declaring your internal variable public--because you might not want it to be an internal variable. get/set methods are just another part of the interface, and like any OO interface, it doesn't matter what happens inside as long as the input and output are consistant.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

In reply to Re: Re: Re: Re: Re: (OT) OOUI: multiple views in an object. by hardburn
in thread (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.