Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re: Re: Re: Re: (OT) OOUI: multiple views in an object.

by hardburn (Abbot)
on Oct 31, 2003 at 18:43 UTC ( [id://303653]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Re: (OT) OOUI: multiple views in an object.
in thread (OT) OOUI: multiple views in an object.

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

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: (OT) OOUI: multiple views in an object.
by Anonymous Monk on Oct 31, 2003 at 21:08 UTC
    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.

    A dynamically typed language is: A) not always an option, and B) not a solution to the general problem of possible changes to the underlying data representation. Although it may be a perfectly acceptable solution in the simple case you describe.

    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.

    You cringed, but did you then attempt to imagine how such model might work? In the simplest terms, the controlling code in your model creates (or otherwise obtains) the data object, creates an appropriate ReportGenerator object (based on the desired output format desired), and then passes the data object to the generator object which uses accessors to retrieve the data, formats it appropriately, and produces output somewhere or returns a formatted string (or something unspecified). Even if that doesn't describe your model, let's consider it anyway.

    What if I described a model, in simplest terms, in which the controlling code creates an object and asks it to generate an appropriate report (again, based on the desired output desired). Does that sound so awful? The system I imagine here still has ReportGenerator subclasses, but the object's to_html() method (for example) does any necessary transformations on its underlying data representation, instantiates the appropriate generator, and produces the output or a formatted string, or perhaps it takes an IO object and appends itself (and the IO object could point to a file, STDOUT, or a scalar). Should the object require non-trivial changes (to accessors or underlying data representation), I do not need to go beyond the class itself to make these changes.

    I hope I wasn't (and am still not) sounding adversarial. That is not my intent. I haven't made up my mind whether the author's methods are sound or not. For myself, I need more than a simple reading of the articles to make that decision (if I want some semblance of intellectual honesty). I'm not prepared to simply brush it aside because of any received dogma about the separation of implementation and display.

      . . . not a solution to the general problem of possible changes to the underlying data representation. Although it may be a perfectly acceptable solution in the simple case you describe.

      I think that Perl could switch quite easily from "return an int" to "return a complext object" either by overloading numification on the overloaded object, or by returning a tied scalar. This may not be always possible, either, but I bet it will work in many cases.

      Does that sound so awful?

      Your first paragraph describes what I'm doing already pretty well. Right now, if I need to add new report, I add the class name to a certain hash in the base ReportGenerator class (which can be used to give the user a list of possible reports to generate) and then code the report subclass to extract stuff from the data class.

      In your model, I would also need to add a subroutine to the data class to generate the report. Which I suppose isn't the worst thing that could be done, but I don't see why I need to do it when I don't see any particular problems with my current model. Even if I were to start this project from scratch, I would still probably do the report generator the same way.

      Incidently, I read over the author's article Why getter and setter methods are evil. It appears he doesn't think all get and set methods are evil--just the ones that are expected to return a primitive type. Returning more complex objects is fine by him.

      ----
      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

        but I don't see why I need to do it when I don't see any particular problems with my current model.

        Agreed. And in the present case, a purely procedural solution from the outset would be perfectly fine in my mind. It isn't a complex system.

        Incidently, I read over the author's article Why getter and setter methods are evil. It appears he doesn't think all get and set methods are evil--just the ones that are expected to return a primitive type. Returning more complex objects is fine by him.

        Well yes, I don't even consider methods that deal in non-primitive objects (eg, domain level or interface level objects) to be getter/setter methods.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://303653]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (3)
As of 2024-03-28 17:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found