[ note: originally sent this from the wrong e-mail identity. sorry
for dupe e-mail! ]
Linus Tolke wrote:
Hello Tony!
1. Yes.
If you have a closer look at the Model subsystem the classes
are
named according to the pattern used and the pattern is documented in
the Cookbook.
Hm. Wow. Yes.
I feel silly. :) Now I'm going to have to save face by proposing a
follow-up idea:
I think the Cookbook might benefit from a quick cheatsheet of the
design patterns employed. An example would be a table listing
"Classes by Design Pattern" and the inverse "Design Patterns by Class",
allowing for quick reference.
Also, perhaps a useful appendix would list Design Patterns, a synopsis
of each, and some examples.
2. Great idea. Shall I start a subproject? What shall we
name
it?
I was overdue for a great idea. :) (Thanks! In fact I'm flattered,
hehe!)
Hmm, some ideas for a subproject name:
- argouml-modelwizard
- argouml-designpatterns
- argouml-patterns
- argouml-patternwizard
- argouml-modeltemplates
- argouml-templates
If we implement a template system for this, Design Patterns are
probably the best place to start, but templates don't need to end
there… :)
2008/1/17, Tony | Zearin <[EMAIL PROTECTED]>:
I have 2 thoughts regarding
ArgoUML and Design Patterns.
- Would it be possible to document the patterns used in the
ArgoUML source?
By this I mean label them both in the Developer's Cookbook and in
comments of the source code itself.
It may make it easier for new developers to join, as they could simply
take note in ways like " Okay, this component fulfills the [ role
] in this [ design
pattern ]" and then become familiar with the specifics of the Argo
implementation. This would allow familiarizing to follow General ➝
Specific and take advantage of an individual's prior knowledge of Best
Practices.
- What about a subproject that allows a user to quickly
generate models based off of Design Pattern templates?
For example, there might be a "New from Template…" dialog allowing a
user to create a new Model / Package / Class (depending on need) and
present some quick forms for naming the various components.
This would be another tool to help usability and adaptability, as well
as help to spread Best Practices.
-- Tony | "Zearin"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
