Kotlin の最大の長所の 1 つは、同時に弱点にもなります。今日、データ クラスについて話すとき、そして Java レコードについて話すとき、少なくとも私が知っている多くの人は定型コードの完全な削除に焦点を当てる傾向があります。ボイラープレート コードは、長年にわたって開発者を悩ませてきました。これは Java にだけ存在するものではなく、他の言語にも同様に存在します。データ アクセス オブジェクトを何らかの方法で作成することを考えた場合、それを Kotlin で行うか、Java で行うか、またはその他の言語で行うかは、あまり重要ではありません。 多くの場合、リポジトリの作成、サービス、コントローラーという同じプロセスを繰り返します。私たちが行っていることの多くは、依然として定型的なものです。データ クラスまたは Java レコードを作成する決定には定型コードが含まれていた可能性がありますが、ソフトウェア エンジニアリングのより重要なパラダイムは、これらのタイプのデータ構造を作成する実際の焦点でした。 それはすべて、不変性、またはいずれにしてもその可能性について要約されます。時間を巻き戻して、ある時点でさまざまなものを指定するデータ構造の作成を開始した 1995 年に戻りましょう。メソッド、関数、コンストラクターのいずれかに引数を渡せるように、フィールド、ゲッター、セッター、プロパティ、アクセサー、属性、パラメーターを定義します。この部分については次のようになります。 80 年代半ばのシリーズ、ゴールデン ガールズのキャラクターを使った楽しいプログラミング。これを踏まえて、約 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 + '\'' + '}'; } }  2 つのコンストラクターを作成するためだけに入力するコードは膨大な量でした。ハッシュコードとイコールは必ずしもすべての場合に必須というわけではありませんが、ほとんどの場合、より一般的なコンストラクターの隣に引数なしのコンストラクターを実装する必要がありました。この定型コードをすべて作成して良かった点は、バイトコードにコンパイルした後にすべてがどのように見えるかが非常に明確にわかっていたことです。 しかし、いずれにせよ、定型コードは多くの開発者にとって常に議論の的となる問題であったため、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 でのゴールデン ガールズの実装は次のようになります。   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" ); } } そして今日に至るまで、コードの簡素化とコード削減は続くようです。しかし、ボイラープレート コードが削減されると、フィールド、ゲッター、セッター、プロパティ、アクセサー、属性、パラメーターの概念がはるかに視覚的でなくなり、頭の中でマッピングするのが難しくなりました。私たちが好むと好まざるにかかわらず、これらの概念は依然として JVM の動作方法であり、コードをバイトコードで編成する方法です。しかし、コードの過度の単純化は実際にはコードを読みやすくすることを目的としており、データ クラスと Java レコードの場合は、データ構造を作成するという考え方もあります。不変または部分的に不変です。  Java レコードは、それに含まれるすべての値や参照が変更できないという意味で、真に不変です。同じ理由で、Kotlin データ クラスも真に不変にすることもできますが、その必要はなく、ある意味、開発者に複雑で最悪の、変更可能なコードを作成する権限を与えます。いずれにせよ、必要になるまではこれで十分です。アノテーションに大きく依存する Spring Framework のようなフレームワークを使用します。以下に例を示します。   @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() } } この例は正常に動作します。疑いを持たない目には、ここで特別なことが起こっているわけではありません。これは、Java で動作するのと同じように、Kotlin でも動作します。ここで、同様の例を見てみましょう。今回はジャクソンの注釈が付けられています。   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 では use-site ターゲットをアノテーションのプレフィックスとして使用することができます。もちろん条件を満たしていることが条件となります。この場合、これを修正する 1 つの方法は、次のようにすべての注釈の前に を付けることです。 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 レコードとデータ クラスには良い影響もあれば悪い影響もある可能性があります。データクラスとレコードが私たちの将来をどのように形作るのかを語るのは難しいですが、1つ明らかなことは、この問題があるため、他のフレームワークはKtorの場合と同様に完全にアノテーションフリーになることに賭けているということです。 これに関するドキュメントを Scribed:  作成し、 slide-share:  も作成しました。 Fields-in-Java-and-Kotlin-and-What-to-Expect で fields-in-java-and-kotlin-and-what-to-expect に  GitHub で私が挙げた例を見つけることもできます。 Golden Girls の例は にあり、jakarta 永続性と検証アノテーションの例は にあります。 jeorg-kotlin-test-drives https://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のモデル

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

Telegram: クリプト島と本土を結ぶ橋

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

ユニークなエコシステムを支えるビットコインUTXOのモデル

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

Telegram: クリプト島と本土を結ぶ橋

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps