Skip to content
This repository has been archived by the owner on Mar 8, 2024. It is now read-only.

Should all non-interface classes be internal? #194

Open
JSAbrahams opened this issue Jun 1, 2018 · 0 comments
Open

Should all non-interface classes be internal? #194

JSAbrahams opened this issue Jun 1, 2018 · 0 comments
Labels
code quality Code quality improvements question Further information is requested

Comments

@JSAbrahams
Copy link
Contributor

JSAbrahams commented Jun 1, 2018

In light of recent PR's (i.e. #183 #184 #185 #193 to name a few) a discussion point has been raised. Do we want to make such classes internal, and which classes should be interna?

Originally, the idea was that only classes that implement the interface as public, and all other classes are considered implementation specific and are internal to the module to make the module safer.
However, a valid point was raised, namely that making all classes internal does somewhat decrease extendibility of classes. (A question was also raised about which classes should be final or not but that is another discussion)

At the moment I prefer having only the classes that implement the interface be public. Perhaps it is best to go through the modules one by one and make classes public sparingly if we conclude that it could be used by another module as well, for instance a future module which builds upon a module or does something similar to a module. The Filter classes in the filter package in the jimple-library-usage-graph module for instance could be public.

@JSAbrahams JSAbrahams added the code quality Code quality improvements label Jun 1, 2018
@JSAbrahams JSAbrahams changed the title Should non-interface classes be internal? Should all non-interface classes be internal? Jun 1, 2018
@FWDekker FWDekker added the question Further information is requested label Oct 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
code quality Code quality improvements question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants