Javaでは「再代入できない」をあらわすモノは今のところ用意されていません。
多くの場合はfinalを型の前につけるだけです。
Javaでのfinal利用はそれほど単純ではありません。
幾人かはこれを無視し、不快で一貫性のない混乱が生じます。
finalな参照型変数は、参照先のインスタンスが保持する値や状態が変わらないというわけではなく、あくまで変数の参照先のインスタンスを変えられないだけです。
このためimmutable(不変性)にするにはfinalだけでは不十分で、既存のfinalだけだと荒れがちという理由から、lombokを使って無理やりvarやvalを使ってるケースを見かけます。
varは再代入できる変数、valは再代入できない変数、という使い分けがあります。
Lombokを使う事で、javaでもvarやvalを使うことができますが、正直なところ無理やり使うと分かりにくいです。
Lombok
Lombok を使用すると、やるべきことだけに集中できるため、コードを簡単に記述できます。
たとえば、ゲッターとセッターを生成したい場合は、クラスに@Getterおよび@Setterアノテーションを付けるだけです。
varとvalは、Javaの変数宣言を簡略化するために使用できるアノテーションです。
Lombokでvarとvalを使用する際の良い点と悪い点を紹介します。
Lombokでvarを使用する良い点
コードが簡潔になる
varを使うと、明示的に型を指定することなく変数を宣言することができます。
型は、代入された値からコンパイラが推測します。
これにより、定型的なコードが減り、コードが簡潔になります。
柔軟性
varを使うと、変数の宣言を変更することなく、変数の型を簡単に変更することができます。
これは、コードをリファクタリングするときや、型が複雑だったり長かったりするときに便利です。
可読性の向上
明示的な型宣言のノイズを減らすことで、特に複雑なデータ型を扱う場合に、varはコードの可読性を向上させることができる。
メンテナンスフレンドリー
varを使用する場合、メソッドの戻り値の型が変わっても、変数宣言を修正する必要はありません。
コードは自動的に新しい戻り値の型に適応します。
Lombokでvalを使用する良い点
不変の変数
valは最終的な（不変の）変数を宣言するために使用します。
これは、代入された値から自動的に型を推測し、変数に final 修飾子を追加します。
これにより、不変性が促進され、偶発的な再割り当てを防止することができます。
可読性
valを使用することで、不変の変数を作成するという意図を明示的に伝えることができます。
これにより、コードがより読みやすくなる可能性があります。
安全なリファクタリング
val変数の代入値を変更する必要がある場合、コンパイラは再代入の試行を検出します。
これにより、偶発的な変更を防ぎ、変数が不変であることを保証します。
Lombokでvarを使用する悪い点
わかりやすさの低下
varはコードの可読性を向上させることができますが、場合によっては明瞭性を低下させることもあります。
過剰に使用したり、不明瞭な変数名で使用すると、他の開発者（または将来の自分）がコードを理解するのが難しくなる可能性があります。
隠し型
varは変数の型を明示的に指定しないので、実際の型を決定するためには、代入された値を参照するか、コード内を移動する必要があるかもしれません。
これは、特に大規模なコードベースや他人のコードで作業する場合、困難なことです。
Lombokでvalを使用する悪い点
使用方法が限定される
valは最終変数にしか使えません。
一度初期化された変数を再代入することはできませんし、機能的にそれだけです
型を隠す
varと同様に、valは変数の明示的な型を隠します。
特に代入される値が複雑な場合や、変数名が十分に説明的でない場合は、コードの理解が困難になることがあります。
互換性の問題
valはLombokによって導入された機能であり、すべてのIDE、ビルドツール、コード解析ツールと互換性があるとは限りません。
開発環境によっては利用が制限されることがあります。
最後に
Lombok は、コードの記述を減らすのに役立つ優れたツールです。
全体として、Lombokのvarとvalは、簡潔なコードや可読性の向上といったメリットをもたらしますが、明快さや保守性を犠牲にしないよう、賢く慎重に使用する必要があります。
個人的には、ローカル変数の型推論はどう利用されるかを型推する必要があり、既存の言語にうまく適合させる必要があります。
個人的な主観が大きいのですが、正確にはLombokの問題ではなく、開発者が開発で Lombok をどのように使用するかが問題になりがちです。
利用者はLombok がコードを生成することを忘れています。
これは、ソース コードには表示されないためです。
ほとんどの開発者が最初に行うことは、何かを実装する前に、クラスに Lombok アノテーションを追加することです。
たとえば、@Dataアノテーションを使用して DTO クラスにアノテーションを付け、ゲッターとセッターを生成します。
これは、私もかつてやっていたことです。
迂闊な使用者が忘れている (または知らない) ポイントは、Lombok がequals、hashCode、toString、canEqualなどの追加のメソッドを生成することです。
そして、実際にはこれらを使用しない場合も多くあります。
コードリポジトリには、使用しないものを含めるべきではありません。
自分達が書いたコードが何であれ、存在する理由がなければ、それを削除する必要があります。
正しいLombokアノテーションを使用するのは開発者の責任です。
これを修正する最も明白な方法は、@Dataアノテーションではなく@Getterおよび@Setterアノテーションを追加することです。
一部の開発者は、Lombok を使用して Sonar 違反を修正するのではなく、非表示にしています (意図的または非意図的)。
