This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 86007

Summary: Design Pattern : Mediator : Bad design in template
Product: uml Reporter: bugbridge <bugbridge>
Component: Design CenterAssignee: issues@uml <issues>
Status: NEW ---    
Severity: blocker CC: ads
Priority: P4    
Version: 5.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description bugbridge 2006-09-28 10:50:43 UTC
Original submitter: ads

Description:
Date: 08/06/2004



Bow06:
Apply Mediator behavioral pattern .
Look at ConcreteMediator implementation.
Private  attribute has bad design matter.
It should has Colleague as type ( not implementation class ConcreteColleague )
and array of Colleague in this case more convenient.
So attribute declaration in ConcreteMediator should be:

private Colleague[] attr;

======================================================================

Evaluation:
The code genaration depends on the model we create. If you look carefully, there
is an association between ConcreteMediator and ConcreteColleague and because of
this association, the related code becomes
    private ConcreteColleague mConcreteColleague;

For example, if you create two classes and associate them, you will get similar
code generation.

In design pattern, we try to depict the pattern as in GOF, as close as possible.
And I believe there is absolutely no problem with this one. We dont prevent user
from changing any of the implementation details.

xxx@xxxx 2004-09-20

Still reproducible in Bow9.
xxx@xxx 2004-09-10

Bug is reopened.
I completely disagree with your point of view.
You base youreslf on Design point of view: we have "right" design representation
, so we
have automatically such "right" source code.
But this is wrong. We cann't give to user source inconsistent source code.
User may ADD new code to generated after applying template. But in current
situation user
get source code that should be completely rewritten. He cannot use interface in
such manner 
with private member, so he should either remove this member at all from interface or
change interface to abstract class. So , why I should use this pattern if after
applying I should change all "design matter" ? I will never use this pattern and
if I want this design
construction I write source code for them from scratch.
Generation well source code for Design patterns is very important . And we
shouldn't accent ourself on good-looking design picture for patterns.
So source code after appliyng pattern should be correct.
If current design representation leads to wrong source code then pattern should
be changes in 
such manner that generated source code appear as right.
There are may be many opinions how design pattern may be looks on diagram , so
there are may be many 
points of view how it may be realized and we have some freedom for any patterns.
So pattern may 
be changed.

*Besides* in this case pattern should be changed in such manner that array of
ConcreteColleague
should appear as array of Colleague. Elsewhere we got implementation pattern not
design.
xxxx@xxxx 2004-09-21
Comment 1 Peter Lam 2008-06-11 00:07:02 UTC
not sure if the generated code is correct since the 6.5 generated code is the same as in the comment.