Timeline for Object Paradigm for PHP, Practice in Design
Current License: CC BY-SA 2.5
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 15, 2011 at 21:56 | vote | accept | 65Fbef05 | ||
| Feb 15, 2011 at 21:55 | comment | added | 65Fbef05 | I've just started reading 'Object Design: Roles, Responsibilities and Collaborations' - From reading the forward, the ability to define responsibility clearly seems to be an important skill to develop. | |
| Feb 15, 2011 at 21:43 | comment | added | David Harkness | As for access level, any public method/property becomes part of the external contract (API) that client classes will use and becomes difficult to change over time. If you start with private, there are no external dependencies to fix if you need to change it or elevate it to public status. The same is true of protected with subclasses. | |
| Feb 15, 2011 at 21:41 | comment | added | David Harkness |
@65Fbef05 - Deciding class responsibilities takes practice, and often the classes tend to be abstract concepts like "a regularly-run report" that need subclasses to make them complete such as "a weekly volume report" and finally instances to make them useful such as "the weekly volume report for January 12th, 2011". One goal I try to follow is for each class to have a single major responsibility. Here AbstractReport is tasked with two: generate a report and manage its storage on disk. In this case I think it's okay, and you could always split them apart later.
|
|
| Feb 15, 2011 at 21:08 | comment | added | 65Fbef05 | Also, regarding protection - As a rule of thumb, should every field or method begin as private to then have restrictions loosened as the need arises? This question is more or less on common convention as I'm sure literal behavior changes from language to language. PS. I've edited my classes to reflect your suggested changes and posted them above. | |
| Feb 15, 2011 at 21:07 | comment | added | 65Fbef05 | +1 for pointing out my clear "area for improvement": Finding Objects. To verify I understand a few of your concepts, in createReport() you are creating an object for each report, then storing these in an array while the "what day is today/should this report be generated" logic is stored in each report class. When I created this thread, I had identified "automated report creation" as an object. Clearly from your response, this is too broad. What are the signs of an appropriately responsible class? What's too much or too little? | |
| Feb 15, 2011 at 14:51 | vote | accept | 65Fbef05 | ||
| Feb 15, 2011 at 21:07 | |||||
| Feb 15, 2011 at 6:28 | history | edited | David Harkness | CC BY-SA 2.5 |
Added ReportManager
|
| Feb 15, 2011 at 5:56 | history | answered | David Harkness | CC BY-SA 2.5 |