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.
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
not sure if the generated code is correct since the 6.5 generated code is the same as in the comment.