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

Should all non-interface classes be internal? #194

@JSAbrahams

Description

@JSAbrahams

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    code qualityCode quality improvementsquestionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions