On Sat, 11 Jan 2025 04:13:14 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> This way, there is no need for the 3 XXXKeyMaterialMerger (where XXX: >> Any/Data/Key) and the merging code is in 1 method instead of handled over 4 >> different methods. > > May be a matter of taste and trade-offs, but I personally lean more towards > the object-oriented/polymorphic design. While a bit more verbose, I like the > separation of responsibilities, the closed-world type of transitions in the > states machine and the potential for extensibility. The procedural approach > bases transitions in the state of a record that is not self-explanatory, > opens the world to the reader for meaningless instantiations/states (e.g. > with a key and a byte array, or with `isBytes = false` and a byte array) and > is less extensible. That type of aggregation could be just fields in the > merger class, and I don't see the point of doing `keyMerger = > keyMerger.merge(key);` for a method that can only return `this`. @franferrax ? @martinuy: I agree and also acknowledge that it might be a matter of taste. In my view, the object-oriented/polymorphic design looks more idiomatic. Even if it spans a couple more classes/methods, each of them is shorter and simpler. Overall, it requires less control flow statements and clarifying comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22215#discussion_r1913532228
