On Mon, 13 Jan 2025 17:12:33 GMT, Francisco Ferrari Bihurriet <fferr...@openjdk.org> wrote:
>> 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. Yes, it's a matter of taste. Both work. It took me a while to understand the various Mergers, their differences and the flow of how it works. Just want to note that the lack of comments doesn't mean the code is more self-explanatory, it may just need more comments. Anyway, it's just different personal preference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22215#discussion_r1915822455
