Kotlin中继承Lambda是否属于良好编程实践？

Hey there! Great question—this is a common point of confusion for Kotlin newcomers, so let’s break down whether this approach is advisable.

First: Why Your Code is Legal #

In Kotlin, function types like (Int) -> String are actually SAM (Single Abstract Method) interfaces under the hood. They define exactly one abstract method: invoke(), which is what you’re overriding in your Test class. So your code is just implementing a standard interface, which is fully supported by the language.

When This Approach Makes Sense #

There are valid scenarios where using a class to implement a function type is the right call:

• Stateful function logic: If your "function" needs to hold and modify state between calls, a class is perfect. For example, you could add a prefix property to Test and return "$prefix${p1.toString()}"—something you can’t do with a basic lambda without capturing mutable variables (which is often less clean).
• Additional methods/properties: If you need to attach helper methods or metadata to your function (like a resetPrefix() method or a description property), a class lets you bundle all that together, whereas lambdas are limited to just the function logic.
• Clear type identity: In cases like dependency injection or explicit type checks, a named class (like Test) makes your code more readable. Other developers can instantly recognize what this type represents, unlike an anonymous lambda.

When You Should Avoid It #

Your intuition that this might not always be good practice is spot-on—here’s when to stick with regular lambdas instead:

• Simple, stateless logic: If your function does nothing more than convert an Int to a String, writing val test: (Int) -> String = { it.toString() } is far more concise. Defining a full class here adds unnecessary boilerplate.
• One-off function instances: Lambdas are lightweight and ideal for passing as arguments to higher-order functions (like list.map { it.toString() }). A class would be overkill for these temporary use cases.
• Team readability: Most Kotlin developers are used to seeing lambdas for function type implementations. Using a class here might confuse teammates who aren’t familiar with this pattern, unless you document it clearly.

Final Verdict #

This approach isn’t inherently a "bad practice"—it’s just a tool that’s suited for specific situations. Use it when you need state, additional functionality, or clear type semantics. For simple, stateless function logic, stick with lambdas to keep your code clean and idiomatic.

内容的提问来源于stack exchange，提问作者mol