Kotlin 最大的优点之一也可能是它的弱点。当我们今天谈论数据类时，以及以同样的方式谈论 Java 记录时，我们倾向于（至少我认识的许多人）将重点放在完全消除样板代码上。样板代码多年来一直困扰着开发人员。它不仅存在于Java中，其他语言也有。如果我们考虑以任何方式创建数据访问对象，那么使用 Kotlin、Java 或任何其他语言来创建并不重要。 我们经常重复相同的过程：存储库创建、服务和控制器。无论如何，我们所做的很多事情仍然是样板文件。然而，样板代码可能是创建数据类或 Java 记录决策的一部分，软件工程的一个更重要的范例是创建这些类型的数据结构的实际焦点。 这一切都归结为不变性或在任何情况下其可能性。让我们回滚时间并回到 1995 年，当时我们开始创建数据结构，在其中指定不同的事物。我们将定义字段、getter、setter、属性、访问器、属性和参数，以便能够将参数传递给方法、函数或构造函数。在这一部分，我们将拥有一些有趣的节目，使用 80 年代中期系列中的角色：The Golden Girls。话虽如此，我们来看看一个类在 15 年左右会是什么样子：   public class GoldenGirlsJava { public String goldenGirl1; private final String goldenGirl2; private final String goldenGirl3; private final String goldenGirl4; public GoldenGirlsJava() { this.goldenGirl1 = "Dorothy Zbornak"; this.goldenGirl2 = "Rose Nylund"; this.goldenGirl3 = "Blanche Devereaux"; this.goldenGirl4 = "Sophia Petrillo"; } public GoldenGirlsJava( String goldenGirl1, String goldenGirl2, String goldenGirl3, String goldenGirl4 ) { this.goldenGirl1 = goldenGirl1; this.goldenGirl2 = goldenGirl2; this.goldenGirl3 = goldenGirl3; this.goldenGirl4 = goldenGirl4; } public String getGoldenGirl1() { return goldenGirl1; } public void setGoldenGirl1(String goldenGirl1) { this.goldenGirl1 = goldenGirl1; } public String getGoldenGirl2() { return goldenGirl2; } public String getGoldenGirl3() { return goldenGirl3; } public String getGoldenGirl4() { return goldenGirl4; } @Override public String toString() { return "GoldenGirlsJava{" + "goldenGirl1='" + goldenGirl1 + '\'' + ", goldenGirl2='" + goldenGirl2 + '\'' + ", goldenGirl3='" + goldenGirl3 + '\'' + ", goldenGirl4='" + goldenGirl4 + '\'' + '}'; } } 仅为了创建两个构造函数就需要输入大量代码。尽管 hashcode 和 equals 不一定在所有情况下都是必须的，但我们几乎总是必须在更通用的构造函数旁边实现一个无参数构造函数。创建所有这些样板代码的好处是我们非常清楚地知道编译为字节码后一切会是什么样子。 然而，无论如何，样板代码对于许多开发人员来说始终是一个有争议的问题，因此 2009 年，lombok 出现并彻底改变了我们创建数据结构的方式。它引入了使用注释处理器并解释特定注释的概念，这些注释将为我们的类提供所需的质量，因此 lombok 带注释的类将如下所示：   @Getter @Setter @AllArgsConstructor @ToString public class GoldenGirlsLombok { public String goldenGirl1; private final String goldenGirl2; private final String goldenGirl3; private final String goldenGirl4; public GoldenGirlsLombok() { this.goldenGirl1 = "Dorothy Zbornak"; this.goldenGirl2 = "Rose Nylund"; this.goldenGirl3 = "Blanche Devereaux"; this.goldenGirl4 = "Sophia Petrillo"; } } 有一段时间，人们对龙目岛感到非常高兴！最后，必须创建所有样板代码的负担消失了。但这种感觉持续了大约 7 年，当新玩家到来时，这一次是软件开发行业始料未及的。它被称为 Kotlin，于 2016 年首次亮相，并立即引入了数据类。我们在 Kotlin 中的 Golden girls 实现现在看起来像这样：   data class GoldenGirls( var goldenGirl1: String = "Dorothy Zbornak", private val goldenGirl2: String = "Rose Nylund", private val goldenGirl3: String = "Blanche Devereaux", private val goldenGirl4: String = "Sophia Petrillo" ) 尽管 Kotlin 慢慢开始聚集粉丝，但另一方面 Java 意识到市场上还有其他东西，这方面的一些开发开始获得一些动力，比如项目 Loom，该项目一直在制作中，但也被搁置了一段时间。这就是为什么随着 20202 年 Java 14 的发布，Java 引入了 java 记录，Java 中的数据结构现在如下所示：   public record GoldenGirlsRecord( String goldenGirl1, String goldenGirl2, String goldenGirl3, String goldenGirl4 ) { public GoldenGirlsRecord() { this( "Dorothy Zbornak", "Rose Nylund", "Blanche Devereaux", "Sophia Petrillo" ); } } 直到今天，代码简化和代码减少似乎还在继续。然而，随着样板代码的减少，字段、getter、setter、属性、访问器、属性和参数的概念变得不那么直观，也更不容易在我们的脑海中映射。无论我们是否喜欢，这些概念仍然是 JVM 如何工作并使用字节码组织代码。但是代码过度简化实际上是为了使代码更易于阅读，对于数据类和 java 记录，这个想法也是为了创建数据结构是不可变的或部分不可变的。  Java 记录确实是不可变的，因为它包含的所有值或引用都无法修改。出于同样的原因，Kotlin 数据类也可以是真正不可变的，但它们不必这样做，这在某种程度上允许开发人员创建复杂且最糟糕的可变代码。无论如何，这一切都很好，直到我们需要与 Spring 框架等严重依赖注释的框架一起使用。这是一个例子：   @Entity @Table(name = "shelf_case") data class Case( @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) val id: Long?, var designation: String?, var weight: Long? ) { constructor() : this(0L, null, null) override fun toString(): String { return super.toString() } } 这个例子效果很好。对于毫无戒心的人来说，这里并没有发生什么特别的事情。这在 Kotlin 中有效，就像在 Java 中一样。但现在让我们看一个类似的例子，但这次带有 Jackson 注释：   data class AccountNumbersPassiveDto( @NotNull val accountNumberLong: Long?, val accountNumberNullable: Long?, @DecimalMax(value = "10") @DecimalMin(value = "5") val accountNumber: BigDecimal, val accountNumberEven: Int, val accountNumberOdd: Int, @Positive val accountNumberPositive: Int, @Negative val accountNumberNegative: Int, @DecimalMax(value = "5", groups = [LowProfile::class]) @DecimalMax(value = "10", groups = [MiddleProfile::class]) @DecimalMax(value = "15", groups = [HighProfile::class]) @DecimalMax(value = "20") val accountNumberMaxList:Int ) 这个例子将会失败，原因是在 Kotlin 中，没有办法告诉编译器我们到底希望我们的注释应用到哪里。在前面使用注释  （jakarta 持久性注释）的示例中，注释已正确应用于字段。如果我们反编译该代码，我们会发现： @Entity   public final class Case { @Id @GeneratedValue( strategy = GenerationType.SEQUENCE ) @Nullable private final Long id; @Nullable private String designation; @Nullable private Long weight; 但对于后者，这是一个雅加达验证示例，我们发现：   public final class AccountNumbersPassiveDto { @Nullable private final Long accountNumberLong; @Nullable private final Long accountNumberNullable; @NotNull private final BigDecimal accountNumber; private final int accountNumberEven; private final int accountNumberOdd; 这意味着 并未受到其字段上的这些注释的影响。在第一个例子中我们很幸运。它实际上也可能失败了。为了指定我们的注释需要转到哪里，Kotlin 使我们可以使用使用站点目标作为任何注释的前缀。要求当然是满足条件。在这种情况下，解决此问题的一种方法是为所有注释添加 前缀，如下所示： AccountNumbersDto @field   data class AccountNumbersPassiveDto( @field:NotNull val accountNumberLong: Long?, val accountNumberNullable: Long?, @field:DecimalMax(value = "10") @field:DecimalMin(value = "5") val accountNumber: BigDecimal, val accountNumberEven: Int, val accountNumberOdd: Int, @field:Positive val accountNumberPositive: Int, @field:Negative val accountNumberNegative: Int, @field:DecimalMax(value = "5", groups = [LowProfile::class]) @field:DecimalMax(value = "10", groups = [MiddleProfile::class]) @field:DecimalMax(value = "15", groups = [HighProfile::class]) @field:DecimalMax(value = "20") val accountNumberMaxList:Int ) 如果我们现在尝试使用 IntelliJ 反编译生成的字节码，我们会发现它会生成以下 Java 代码：   public final class AccountNumbersPassiveDto { @NotNull @Nullable private final Long accountNumberLong; @Nullable private final Long accountNumberNullable; @DecimalMax("10") @DecimalMin("5") @org.jetbrains.annotations.NotNull 这意味着注释已应用于字段，并且我们的代码按预期工作。 此时你大概可以想象，长期从事 Java 工作的人适应 Kotlin 不会有任何问题，因为我们都知道什么是字段、参数、属性等。我们今天观察到的、我也亲眼目睹的情况是，代码简化似乎有可能适得其反。有很多次我意识到在项目中花费了时间试图弄清楚为什么在某些项目或模块中注释似乎不起作用。这一切似乎都归结为不利用使用站点目标。 我最有可能的理论是，新一代的开发人员可能会将我们这一代人认为并不复杂并出于本能而学到的东西视为真正复杂的材料。使用现场目标就是这种情况。这些曾经是我们很容易想象的事情。然而在当今时代，由此产生的混乱似乎在某些情况下推迟了项目的按时开发。当然，我无法一概而论，但 java 记录和数据类可能有好的一面，也有可能坏的一面。数据类和记录将如何塑造我们的未来很难说，但有一点是明确的，由于这个问题，其他框架正在押注于完全无注释，就像 Ktor 的情况一样。 我在 Scribed:  上创建了有关此内容的文档，也在幻灯片共享上创建了相关文档：   。 Fields-in-Java-and-Kotlin-and-What-to-Expect fields-in-java-and-kotlin-and-what-to-expect 您还可以在 GitHub 上找到我给出的示例。 Golden girls 示例可以在这里找到：   ，jakarta 持久性和验证注释示例可以在这里找到：https:   。 jeorg-kotlin-test-drives //github.com/jesperancinha/jeorg-spring-master-test-drives 最后，我还在 YouTube 上制作了一个有关此内容的视频，您可以在这里观看：   https://youtu.be/rTCjlyGVDGE?embedable=true 也发布 。 在这里

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

該音頻是用故事的原始語言製作的！

太長; 讀書

如何解决处理使用站点目标时的 Kotln 问题

since the early Beginnings in Java we would create 
our data structures using Getters and Setters we  

would declare our Fields like this and we would 
create our pams like this then we would create  

our instances passing out the arguments to the 
Constructor this way in 2009 a project made its  

debut to the jvm world that would revolutionize 
the way we create data structures this was called  

long walk and Long Walk would allow us to 
reduce the bottle plate code that we have  

been used to creating up until this time that way 
we would create Getters in a different way using  

annotations like this another language was being 
developed at the same time called cotlin and its  

debut was in 2016 where cotlin introduced for 
the first time data classes data classes didn't  

have to use any annotation and with them you could 
create something like this which looks much much  

simpler but cotlin was still not as popular as it 
is today so in 2020 with the release of java 14  

records were introduced and with records we could 
do exactly the same this way just as much as in  

data classes so let's go back to the traditional 
way of creating data structors in Java here we  

can see where we have created a getter and here 
we see where we have created a setter this is a  

property because we are using accessors to reach 
it this is a field because we access it publicly  

and these are the parameters of our Constructor 
fast forward and we can get to records and data  

classes and let's look at data classes when we 
look at data classes we just don't see any of  

this if we do compile this class we can see all 
of these Concepts implemented in this gigantic  

Java class which is something we don't really see 
in the data class as we don't see it in this data  

class in my career I hardly ever had bumped into 
so many people questioning what is a getter what  

is a Setter what is a field and and what it's Pam 
and when we see this happening is when we try to  

apply annotations Frameworks like the spring 
framework usually needs annotations applied to  

either a field or either a getter either a Setter 
they have very specific places where they need  

to be applied in a data class that is not visible 
and because it's not visible lots of people have a  

lot of questions and a lot of trouble figuring out 
what is going on why are they not behaving the way  

The Decorator is telling them to behave usually 
the reason is just because we do need to specify  

in cotlin for example where does this annotation 
needs to be applied to so we do need to specify  

either a field either a Pam either a getter either 
Center and so forth it is one of these negative  

signs of a long-term effect of using cutland that 
we forget what is a field what is a parameter what  

is a getter what is a Setter maybe Getters and 
Setters is a completely different discussion  

but I would expect property in field not to 
be such a huge discussion and in it actually

is so can cotlin be an answer to all 
our problems it can be an answer to  

some problems definitely but for 
other things it might actually be a

curse so that was a dramatic ending to the 
first part of our video for this part I want  

to show you an example about how annotations 
actually work for those examp examples that  

we have seen so in this case for my project 
spring Master test drives I have this class  

account lists asserts dto this is part of a 
project and this is called size size is part  

of the Jakarta annotations package and with 
Jakarta we can decorate our data objects when  

we want to send data Through the Wire via rest 
services in this case we want to essentially  

validate our field according to groups now 
groups is something different but what's  

important here is to make these annotations 
work as you can see right over here on the  

left bottom corner of the screen we see that 
all tests are in the clear if for example I do

this and remove field from it and run the tests 
again we're going to see that these tests are  

going to fail just as I expected they fail and 
if we go here down to the bottom of it this test  

what it does it expects a bad request because 
we are sending data that it's not valid to be  

sent through the wire but in this case we get a 
200 and the reason for that is that of course as  

we have seen before the size annotation doesn't 
have a specific prefix letting it know that we  

need to apply this to field but here's the 
catch when we look at size The annotation  

itself we see that the target annotation 
that it contains thus comprises of method  

field anotation type Constructor parameter 
and type use important to note is that it  

is already stereotyped with a target of field 
but unfortunately in cotland it doesn't really  

work that way when we apply certain annotations 
what usually happens is something different so  

now let's have a look at the decompiled code so 
when we decompile this code so code decompile we  

can see an interesting thing so the field 
that we want to annotate is postcode post  

code is located here and we already see that 
the field is not annotated because this is a  

final variable with Val we also are not going 
to generate Setters we only have Getters in  

this case and none of the Getters is annotated 
with the size annotation but we can see that the

Constructor is the Constructor has all the 
annotations that we need for post code and  

curiously enough the parameter of the copy 
function is also annotated with size but  

the crucial thing that needs to be annotated is 
field and field isn't there I can can see this  

very clearly with the Java code but with cotlin 
I don't see anything so when I put field here and  

let's put field on all of the three annotations 
why do I have it this way it doesn't really matter  

I have a whole video about it that explains what 
this group is I put in a link in the description  

um so that you can see a tutorial I made about 
it but for now it's important that we get our  

tests running again and that I can show you 
why are these tests now working why do I get  

them why do we get them all green and what was the 
change so now let's decompile our class again by  

code decompile exactly so here we have the post 
code it's annotated with the three options with  

the size annotation and if we look further down 
we can see that in postcode now we have nothing  

and obviously in copy we don't have it as well 
so the only thing that's annotated now is field  

and another important aspect of this is that for 
this case these Jackson annotations work really  

well because for our specific case they only need 
field so that's why this works and of course each  

manufacturer or its brand has its way of using 
annotations in this case for our case we need  

field it doesn't necessarily have to be the 
case all the time so now let's have a look at  

what happens with other annotations that don't 
need this if we look at for example a many to  

many many to many is an annotation that only has 
a starget method in FEI field and this works this  

works without the need to put in field on it or 
anything like that and the reason for that is that  

if we then decompile this we can directly see that 
many to many along with the other annotations is  

already applied to a field in this case receipts 
and also shop yeah shops and in this case there  

is no confusion where the confusion exists is for 
annotations like in the case of Jakarta where the  

cotton compiler doesn't really know what to do 
with it and so we don't see size applied to field  

and these are the cases that we need to specify 
that we want our annotation applied to a field  

and I can tell you that using field is something 
that is not necessarily the first thing that pops  

into mind when someone is used to programming in 
Java and of course the literature is filled with  

examples of using simple simply just size and that 
doesn't necessarily have have to be the case all  

the time I'm also not saying that field in this 
case is the only possible fix there is maybe with  

configuration of a certain Plug-In or something 
else external but the bottom line is when these  

errors happen it's very important for us to 
understand these Concepts so we can find the  

source of the of the book understand the problem 
and be able to fix it which is the subject of this  

whole video and this concludes my presentation on 
possible problems using cotlin data structures for  

some people of course I've been using cotlin 
already for a long time and I cannot say that  

I understood this problem immediately but it 
became clear after the compiling what didn't  

became clear of course is what I said already 
in the video that so many questions came up  

when trying trying to explain the source of the 
problem and the fix all right so this wraps up our  

video I hope this video made a difference to you 
I hope that you were able to learn something with  

it and that you can use this in your future career 
whether it is in cotlin Java or any other language  

I think it's important never to forget what a 
field and what a parameter is what a property  

and especially what an argument and a parameter 
is these concepts are important to know and if  

you enjoyed this video don't forget to leave a 
like the usual don't forget to subscribe if you  

dislike this video please give me your dislike 
and if you are interested and want to give an  

input I will be very happy to hear your comment 
in the comment section find out the links to  

these projects especially the spring Master Test 
R project with these examples that I just showed  

如何解决处理使用站点目标时的 Kotln 问题

About Author

註釋

標籤

这篇文章刊登在

Related Stories

比特币 UTXO 模型，为独特的生态系统提供动力

架构师指南：构建 AI/ML 数据湖参考架构

成功云迁移的完整指南：策略和最佳实践

看不见的层面：为什么用户访谈是不可替代的资产

比特币 UTXO 模型，为独特的生态系统提供动力

架构师指南：构建 AI/ML 数据湖参考架构

成功云迁移的完整指南：策略和最佳实践

看不见的层面：为什么用户访谈是不可替代的资产

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps