数日前に以下のエントリでlombokをAndroidStudio環境へ導入しましたが、数日使ってみての感想です。
使っている機能
自分が使っている機能はシンプルに以下の2つだけです。
- @Getter/@Setter
- val
@Getter/@Setter
使うとこんな感じになります。
// 宣言している方のクラス public class Point { @Getter @Setter private int x; @Getter @Setter private int x; // コンストラクタ public Point() { this.x = 10; this.y = 20; } }
// 利用者側コード public class UserSide { public static void main(String args[]) { Point point = new Point(); int x = point.getX(); int y = point.getY(); Log.i("x = " + x + ", y =" + y); // -> x = 10, y = 10 } }
@Getter/@Setterのメリットとデメリット
メリットですが、個人的には普段c#を使っているので@Getter/@Setterを使うと#のProperty構文にかなりまね。それに伴い、Getter/Setterを自分で明示的に記述しないで済むのでコードはシンプルに保ちつつ外部に公開しているかどうかを明示できますね。コードがシンプルなのは宣言元だけで利用者はいつも通り使えるのも好印象です。
参考までにc#のProperty構文版も掲載しておきます。
// c#のProperty構文 // 宣言している方のクラス public class Point { public int X { get; set; } public int Y { get; set; } // コンストラクタ public Point() { this.X = 10; this.Y = 20; } }
// c#版の利用者側コード public class UserSide { public static void main(String args[]) { Point point = new Point(); int x = point.X; int y = point.Y; Debug.WriteLine("x = " + x + ", y =" + y); // -> x = 10, y = 10 } }
デメリットですが、AndroidStudioを起動した直後に@Getter/@Setterで生成されたコードが認識されず、コンパイルエラーマークが出まくるときがあります。大抵リコンパイルして数分待つと大体解消されます。が、それでも認識されないと気がごく稀にあるので、その時はAndroidStudio自体を再起動になります…
val構文
こっちは、上記コード例に倣うと以下の通りになります。
// 利用者側コード public class UserSide { public static void main(String args[]) { val point = new Point(); // ←★ここ int x = point.getX(); // ここは見た目では右辺の型が判断できないので int y = point.getY(); // valで値を受けていません Log.i("x = " + x + ", y =" + y); // -> x = 10, y = 10 } }
valのメリットとデメリット
メリットですが、冗長な宣言がシンプル化できるのでかなり好ましいです。ただし、HashMapをMapで受けたいときでもvalを宣言すると右辺から推測されてHashMapになるのでそこだけ注意したほうがいいかもしれません。(複数インターフェース継承しているときにどの型で受けるのか推測なんてできないですもんね…)
デメリットですが、自分の環境ではこのval構文全く使い物になりませんでした…。
まず、valはオブジェクト型ですと言われてメソッドの候補が出てきません。無理やりメソッドを書いてもコンパイルエラーが起きます。運がいいと10回に1回くらい認識されますが、認識されないとずっとコンパイルエラー表示(何故かコンパイルは通ったり通らなかったり)になります。
なので便利そうなのですが利用は見送りました。
