-
Notifications
You must be signed in to change notification settings - Fork 0
ADR 1. One Class vs Many Classes
Initially, all stream utility methods were placed in a single class StreamUtils.java. This approach has its advantages, but at the same time such a class will quickly become overloaded.
There are two main ways how to structure stream utility methods. We have to specify which approach to follow:
| Approach | Pros | Cons |
|---|---|---|
One class for all methods |
* Easy for library users, they always use import of a single class * For new methods there is no effort to choose between using of existing class or creating a new one |
* Looks like garbage of unstructured methods * Requires regular efforts to find desired method in the long list * Scrolling! * Anyway requires some logical separation in the code (additional comments/lines that separates method groups) |
Separate classes divided by some criteria |
* Better level of granularity * Reduces cognitive effort for users (with clear naming, of course) * Just logical! |
* Requires to remember which methods belongs to which class * For new methods, the decision algorithm must be specified: create a separate class or use an existing one * It can get worse with bad class naming |
Looks like in both cases we will spend time/effort to separate methods into some groups (for single class it will be line-separators or something like this).
With separate classes, it’s native and definitely more handy. All benefits outweigh the disadvantages.
So, the decision is to put methods in separate classes grouped by some criteria.
Logical class separation will:
-
(critical) reduce cognitive effort for library users
-
(critical) make code more structured
-
(minor) reduce scrolling :)
On the other hand:
-
(critical) clear naming should be specified for library classes
-
(critical) for new utility methods, the decision algorithm must be specified: how to choose between existing or new class
-
(minor) for users, it requires imports of several classes