Package Structure

#Package Structure

Class, method, and field visibility should never be overlooked when creating a Privvy component. Since every piece of the architectural puzzle is completely modular, nothing outside of any given component should know about anything else. Breaking visibility rules is what leads to the breach of encapsulation of models, the violation of single responsibility, and various other knocks at maintainability.

The Privvy package structure keeps one component per package, in the same package, so that package visibility can always be used. The lack of public access identifiers means that this modularity is always imposed -- if one finds him/herself wanting to use a ViewModel from another Privvy component, he/she is programmatically dissuaded.

Yes, this does make each Privvy component package very full. Each package will have around 8 classes. This, however, is less of a problem when each class has an architecturally predefined purpose, causing less cognitive load. The benefit of narrowed visibility outweighs the con of bigger packages.

sample/
├── ui/
│ ├── list/
│ │ ├── ListFragment.class
│ │ ├── ListPresenter.class
│ │ ├── ListInteractor.class
│ │ ├── List...
│ └── floatingnumbers/
│ │ ├── button/
│ │ │ ├── ButtonFragment.class
│ │ │ ├── ButtonPresenter.class
│ │ │ ├── ButtonInteractor.class
│ │ │ ├── Button...
│ │ │ ├── ...
│ │ └── number/