shemp has asked for the wisdom of the Perl Monks concerning the following question:

Hey all, yet another design question for something im implementing in Perl. I have a class called DataReportManager which contains a collection of TableReporter objects. The TableReporter objects each contain a collection of RecordReporter (and family) objects.

I am not quite sure where to store certain pieces of data, such as the table names being reported on. (this is crunching data from MySQL).

The DataReportManager references its TableReporters using the table name, (a hashref). The TableReporter objects should probably store the table names because the table name is certainly part of what the TableReporter needs to know about. But the DataReportManager knows when to use which TableReporter. The DataReportManager reporting input params are the table name and a row, which are processed one at a time.

Finally after the dataset has been analyzed, the reports are generated. The table name is needed for the reports, and the RecordReport objects create the reports. So part of me says that each RecordReporter should store the table name, but the TableReporter could just pass it in when it coordinates the RecordReporter's to generate the reports.

So where would people store the table names in this situation?

Sorry for the long post for something thats probably really obvious. Or is this really a style issue?

Replies are listed 'Best First'.
Re: Object data storage (design question)
by Zaxo (Archbishop) on Jun 28, 2004 at 21:43 UTC

    It sounds as though the TableReporter has responsibility for knowing which table it is based on. I think the DataReportManager should not know that implementation detail, but rather have a collection of TableReporters that it just manages.

    You may find the DBI dbhandle methods like data_sources() and tables() to be helpful.

    After Compline,
    Zaxo

[reply]
      Maybe im not fully understanding you, but the DataReportManager needs to know which TableReporter deals with which table. This is becaue when the DRM is given data to report on, it needs to pass it on to the proper TR. I suppose i could have a TableReporter::WhichTable() method.

      In any case the DRM does not know how the TR stores its name, but the DRM has a hashref of TR objects and the keys are the table names.

      I am pretty sure im going with storing the name in the TR, and it can pass the name along to the RecordReporter as needed, which is currently only when the report is generated after all data has been analyzed.

      Did i misunderstand you?
[reply]
        Have the DRM ask each TR if it wants to do something with a given table name. Basically, the DRM is a glorified array with a few methods. It should then delegate all execution of those methods to the TRs. It should ask each TR in turn if it wants to deal with the request that it received. As each TR does something (or nothing), the DRM will aggregate those results and return them to the client.

        If I understand what you're doing, this will give you a few new features:

        • You can have more than one TR handle a given table.
        • You can now have a TR deal with more than one table at a time.
        • You can now move the sorting into the DRM instead of in the TR. (I'm assuming you're doing this.)
        • You can share RRs between TRs.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
        ... the DataReportManager needs to know which TableReporter deals with which table.

        Rather, it needs to be able to find that out.

        So, iterate over the collection of TableReporters and ask them whether they deal with the given table. (If you're worried about performance, you can later add a cache of the results by table-name which gets cleared when more TableReporters are added, but don't optimize prematurely.)

[reply]

Back to Seekers of Perl Wisdom