Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Concrete implementations should be private #2704

Open
retailcoder opened this issue Feb 17, 2017 · 3 comments
Open

Concrete implementations should be private #2704

retailcoder opened this issue Feb 17, 2017 · 3 comments
Labels
difficulty-02-ducky Resolving these involves the internal API, but with relatively easy problems to solve. enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. feature-inspections up-for-grabs Use this label in conjunction with a difficulty level label, e.g. difficulty-02-ducky

Comments

@retailcoder
Copy link
Member

By default, the VBE makes interface member implementations (/event handlers) Private, which leaves the member invisible to consumers of the concrete type, but visible to consumers of the interface.

We need an inspection that finds Public interface implementations, with a quick-fix that makes them Private.

The catch is that doing that might break callers if the callers are written against the concrete type, so the inspection's meta description should mention that.

@retailcoder retailcoder added difficulty-01-duckling Issue where no particularly involved knowledge of the internal API is needed. feature-inspections difficulty-02-ducky Resolving these involves the internal API, but with relatively easy problems to solve. and removed difficulty-01-duckling Issue where no particularly involved knowledge of the internal API is needed. labels Feb 17, 2017
@retailcoder
Copy link
Member Author

The quick-fix should be disabled if the member has direct callers. This makes it a little bit more difficult to implement, but not too much.

@Vogel612
Copy link
Member

On that note: We should flag such direct callers in another inspection. "Explicit call to interface member on concrete class instance" seems like a good idea. The quickfix would then declare the accessed variable As Interface instead of As ConcreteClass (assuming that's possible)...

For instances where both call types are intermingled, we could have another related inspection (but that might be asking too much).

@retailcoder
Copy link
Member Author

@Vogel612 we know which interface(s) the concrete class is implementing, so there could be a quick-fix for changing the declaration to either. e.g. "Declare As ISomething" and "Declare As ISomethingElse", assuming the concrete type implements both ISomething and ISomethingElse.

Hmm.. that feels like R#'s "(thing) can be declared as (interface)"...

@Vogel612 Vogel612 added enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. up-for-grabs Use this label in conjunction with a difficulty level label, e.g. difficulty-02-ducky labels Dec 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty-02-ducky Resolving these involves the internal API, but with relatively easy problems to solve. enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. feature-inspections up-for-grabs Use this label in conjunction with a difficulty level label, e.g. difficulty-02-ducky
Projects
None yet
Development

No branches or pull requests

2 participants