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.
Summary: | JPDABreakpoint with protected constructor. | ||
---|---|---|---|
Product: | debugger | Reporter: | Martin Entlicher <mentlicher> |
Component: | Java | Assignee: | apireviews <apireviews> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | Keywords: | API |
Priority: | P2 | ||
Version: | 7.1 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | The proposed API change. |
Description
Martin Entlicher
2011-08-24 13:59:28 UTC
Created attachment 110183 [details]
The proposed API change.
Y01 Don't use subclassing, use composition: create a factory method which takes something and returns JPDABreakpoint. Leave the class final. Y02 I don't understand the usecase, but setSession clearly serves two purposes: Is any client supposed to call it? Why? Is any subclass supposed to override it? Why? Y03 fireJPDABreakpointChange is not final. Y04 protected static methods are quite useless - e.g. anyone can call them. The purpose of fillFilesForClass remains an undocumented mistery... Y05 There is tons of other (untouched by the patch) methods in the JPDABreakpoint where one should decide what purpose they serve. So far they were good only for callers, now, when the class is not final, do they serve double purpose? That would not be a good sign. Btw. in case you implement Y01, the Y02-Y05 will be automatically rendered obsolete. Y01 Changing subclassing to composition would go against the current principle, since Breakpoint is an abstract class and all it's implementation classes are subclasses of Breakpoint. Therefore to allow subclassing of JPDABreakpoint sounds natural to me. However I've managed to implement the component breakpoints without the necessity to extend JPDABreakpoint, therefore I'm closing this issue as won't fix. Thanks for your comments. |