The Java Collection framework, and equivalents in .NET, are widely used by developers worldwide, but rarely used by Findur plugin developers, whether it is Openlink professional services or a 3rd party.
We wonder why the world’s Findur developers avoid using collections, but the truth is more likely that they just don’t know about them. The framework has been around for decades, and is tried-and-tested, responsible for today’s most robust solutions.
We think all developers should use collections in their code. Keep reading to learn more about why we use collections in our custom development work, and why your solutions would benefit from this approach.
More Transparent Solutions
Consider the use of the Collection interface because it offers a fast, easy-to-interpret, and easy-to-implement way to handle a lot of business logic that is otherwise obfuscated within a customization.
We have published another note about problems with transparency of solutions that heavily rely on the Table.select() method.
Increased use of a Collection is usually associated with a refactoring effort that implements more object-oriented programming principles, and improves the ease of supporting the customizations.
More Reusable Code
Implementations of the Collection interface include List, Set and Map, and they each have an important role to play in customizations. The Map class, in particular, is usually a better class than Openlink’s Table class because it is easier to initialize, find, iterate, and sort.
Compared to the Table class, it is easier to build reusable helper methods that operate on collections: for example finding duplicate objects, getting the intersection or union of two collections, sorting a Map by its values, logging entries in a Map., and more.
Of course, the Table class is necessary when retrieving data from Findur’s database, and extracting to a report. However, much of the intermediate processing, where the complex business logic is performed, can be more easily implemented using a Map.
More Automated Tests
It is easy to construct JUnit test cases on a Collection. It is much more difficult to construct a JUnit test case on a Table. The goal of automated testing is to increase confidence in the solution quality. Sufficient test coverage of the most complex business logic increases users’ confidence in the solution, by focusing on the code that has the greatest chance of failing.
Less Risk During Upgrades
Favoring a Collection reduces reliance in one area on native Openlink APIs, which will simplify application upgrades. The Table class is subject to change from one version to another as the database schema can change from INT to BIGINT, as one example. The Table class often suffers from silent failures, addressed specifically elsewhere in this document.
Refactoring Example
In the following snippet, the method could be refactored to initialize a Map<Integer, Double> named balances that stores the subledgerAccountId and the balance. The benefits will be greater transparency of the solution to aid subsequent developers in their debugging/enhancement work, reduction of code from seven lines to two, and likely ability to reuse static methods that operate on a Collection (e.g. sorting on the Map value, checking for missing balances, removing entries with zero values, and so on).
Future Application Migration
Over time, clients change their tech stack. The cost and effort to move from one application to another is immense. Anything that can be done to reduce the difficulty should be done ahead of time. No technology is ‘future-proof.’
The snippet shown above is part of a long complex customization that is proprietary to one client. No vendor, Openlink or any other vendor’s solution used in the future, will ever offer the functionality out-of-the-box. Extracting the proprietary business logic from the Openlink data model and divorcing it from the Openlink API will make the solution easier to migrate when the client eventually migrates to another platform, which may be years into the future.
Conclusion
We use collections a lot in our custom development work. It makes for more transparent solutions that are easier to understand and enhance. We build automated test suites to deliver high quality (read more about why you should expect that from any technology partner here), which favors the use of collections. And when it comes time to retire Findur, more of the truly bespoke components you have trusted for years will be more easily migrated to a new platform.
