Recently, I was writing a test method similar to this:<\/p>\n
\r\n\/**\r\n * SOME_FEATURE is a constant that identifies a feature the application provides if enabled\r\n *\/\r\nvoid transferMoneyTest() {\r\n\twithEnabledFeature(SOME_FEATURE, () -> {\r\n\t\t\/\/ line one of the test method\r\n\t\t\/\/ line two of the test method\r\n\t\t\/\/ line three of the test method\r\n\t\t\/\/ line four of the test method\r\n\t\t\/\/ line five of the test method\r\n\t\t\/\/ line six of the test method\r\n\t\t\/\/ line seven of the test method\r\n\t});\r\n}\r\n<\/pre>\nOne of my colleagues pointed out that it is a best practice to place lambda code in a distinct method when its size exceeds a certain threshold (e.g., 2 or 3 lines). Hmm, I thought to myself, he is right, but there are exceptions – and this is one of them.<\/p>\n
But why is that an exception? Well, let’s see other similar examples:<\/p>\n
\r\n\/**\r\n * \"transactional\" method provides the ACID transaction context for the lambda \r\n * execution (is the equivalent of e.g., @Transactional from Spring Framework)\r\n *\/\r\npublic void transferMoney() {\r\n\ttransactional(() -> {\r\n\t\t\/\/ line one of the method's implementation\r\n\t\t\/\/ line two of the method's implementation\r\n\t\t\/\/ line three of the method's implementation\r\n\t\t\/\/ line four of the method's implementation\r\n\t\t\/\/ line five of the method's implementation\r\n\t\t\/\/ line six of the method's implementation\r\n\t\t\/\/ line seven of the method's implementation\r\n\t});\r\n}\r\n\r\n\/**\r\n * \"preAuthorize\" method provides the security context for the lambda \r\n * execution (is the equivalent of e.g., @PreAuthorize from Spring Security)\r\n *\/\r\npublic void transferMoney() {\r\n\tpreAuthorize(\"hasAuthority('permission:write')\", () -> {\r\n\t\t\/\/ line one of the method's implementation\r\n\t\t\/\/ line two of the method's implementation\r\n\t\t\/\/ line three of the method's implementation\r\n\t\t\/\/ line four of the method's implementation\r\n\t\t\/\/ line five of the method's implementation\r\n\t\t\/\/ line six of the method's implementation\r\n\t\t\/\/ line seven of the method's implementation\r\n\t});\r\n}\r\n\r\n\/**\r\n * Let's suppose it doesn't make sense to use *synchronized* at the method level.\r\n *\/\r\npublic void transferMoney() {\r\n\tsynchronized (merchant) {\r\n\t\t\/\/ line one of the method's implementation\r\n\t\t\/\/ line two of the method's implementation\r\n\t\t\/\/ line three of the method's implementation\r\n\t\t\/\/ line four of the method's implementation\r\n\t\t\/\/ line five of the method's implementation\r\n\t\t\/\/ line six of the method's implementation\r\n\t\t\/\/ line seven of the method's implementation\r\n\t});\r\n}\r\n<\/pre>\nAll the above examples show some code blocks executed in a particular *context*.
\nWould the code be more readable if one took the below approach instead of a lambda expression?<\/p>\n
\r\npublic void transferMoney() {\r\n\ttransactional(doTransferMoney);\r\n}\r\n\/\/ ...\r\n\/\/ a\r\n\/\/ bunch\r\n\/\/ of \r\n\/\/ other \r\n\/\/ public, \r\n\/\/ protected, \r\n\/\/ and \r\n\/\/ private \r\n\/\/ methods \r\n\/\/ go \r\n\/\/ here\r\n\/\/ (i.e., there's a big distance between transferMoney and doTransferMoney)\r\n\/\/ ...\r\nprivate void doTransferMoney() {\r\n\t\/\/ line one of the method's implementation\r\n\t\/\/ line two of the method's implementation\r\n\t\/\/ line three of the method's implementation\r\n\t\/\/ line four of the method's implementation\r\n\t\/\/ line five of the method's implementation\r\n\t\/\/ line six of the method's implementation\r\n\t\/\/ line seven of the method's implementation\r\n}\r\n<\/pre>\nWell, the transferMoney is much shorter and hence easier to read; the problem though is with *what* is left to read:
\nthe user reads a method meaning “transfer money” (i.e., transferMoney) which does “transfer money” (i.e., doTransferMoney) in a transactional fashion (well, at least he learns something about the *execution context*). <\/p>\n
This is silly; in the above situations, I would rather keep the doTransferMoney content in transferMoney method because it’s easy to spot the distinction between the *execution context* and the *behaviour* implementation; moving the *behaviour* in another method brings no benefit.<\/p>\n
This does not invalidate the rule of thumb that a lambda expression larger than 2-3 lines is best to be moved to a distinct method. In most situations, the *behaviour* is mixed with the lambda expressions hence the reader has to collapse the lambda expression to see the rest (i.e., the *behaviour*). It’s not the same for transferMoneyTest and the similar examples above, because collapsing the lambda expression means hiding the *behaviour* the user intends to view.<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently, I was writing a test method similar to this: \/** * SOME_FEATURE is a constant that identifies a feature the application provides if enabled *\/ void transferMoneyTest() { withEnabledFeature(SOME_FEATURE, () -> { \/\/ line one of the test method […]<\/p>\n