Martins Design Study
(Added final point.) |
(Added first two corrections.) |
||
| Line 40: | Line 40: | ||
In the improved version, I used the following design patterns: | In the improved version, I used the following design patterns: | ||
| − | TODO. | + | * Added a set of ActivityCategory objects to the ActivityReport class to track the categories shown. Added appropriate methods to enforce the [[Law of Demeter]]. |
| + | * To enforce [[Separation of Concerns]], I created a GUI class to handle the [[View]] of the report. This would allow updating the report internals and then updating display as well. Before, the only time that ''SetStartDate()'' and ''getEndDate()'' were called was in the ''save()'' method of the ''ActivityReportWizardPage'' class (which meant that after creating the report, the dates could not be changed). '''TODO'''. | ||
== Discussion == | == Discussion == | ||
The design project was to improve the reporting interface for the "Team Patchwork Reporting Application". TODO. | The design project was to improve the reporting interface for the "Team Patchwork Reporting Application". TODO. | ||
Revision as of 23:25, 27 July 2010
Contents |
Overview
My design study is about the reporting interface for my group (Team Patchwork's) Eclipse plugin which we designed last year. I wrote the reporting interface myself, but without using good OO design. Although it worked, it is a little bothersome to extend (I.E. to create new types of reports or new views an layouts. Hence, I decided to analyze and improve it somewhat.
Use Cases
The reporting interface would be used as follows:
- The user should be able to generate a report for any date range.
- The user should be able to generate a report for any metric defined by the plugin.
- The user should be able to edit an existing report, by changing the date range. The report display should update to reflect the new date range.
- The user should be able to add or remove metrics from an existing report. The report display should update to reflect the new date range.
- The user should be able to save a report as some sort of file (XML, CSV, anything will do, really).
Initial Design
A diagram of the initial design of the reporting interface is shown below.
Flaws
The flaws in the initial design include the following:
- ActivityCategory is not linked to the report.
- The ActivityReportWizard class does not allow the containing of sub-forms. It is all packed into one huge form. This is inconvenient - it would be good to allow a wizard with multiple forms. It does allow for one page, but not many.
- The ActivityReportWizard class and ActivityReportWizardPage class both contain the ActivityReport object, making changes to it. This does not smell right!
- ActivityCategory is unused! This class is supposed to dictate which metrics appear in the report.
- ActivityCategory should perhaps be either a Composite or a Decorator. It is neither at the moment.
- There is no way to export to XML or any other file format. A new class should be introduced for this.
Improved Design
A diagram of the improved design of the reporting interface is shown below.
TODO.
Patterns Used
In the improved version, I used the following design patterns:
- Added a set of ActivityCategory objects to the ActivityReport class to track the categories shown. Added appropriate methods to enforce the Law of Demeter.
- To enforce Separation of Concerns, I created a GUI class to handle the View of the report. This would allow updating the report internals and then updating display as well. Before, the only time that SetStartDate() and getEndDate() were called was in the save() method of the ActivityReportWizardPage class (which meant that after creating the report, the dates could not be changed). TODO.
Discussion
The design project was to improve the reporting interface for the "Team Patchwork Reporting Application". TODO.
