PG日誌

受託系 PG が C# の事を書いています

AndroidStudio 1.3でlombokを数日使ってみた感想

数日前に以下のエントリでlombokをAndroidStudio環境へ導入しましたが、数日使ってみての感想です。

takachan.hatenablog.com

使っている機能

自分が使っている機能はシンプルに以下の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回くらい認識されますが、認識されないとずっとコンパイルエラー表示(何故かコンパイルは通ったり通らなかったり)になります。

なので便利そうなのですが利用は見送りました。

まとめ

使っている機能は少ないですがかなりいい感じです。面倒さから解放されています。なので現時点ではおすすめですね。

ただ、やっぱり標準の機能ではないせいか、AndroidStudioが悪いのかlombok自体が割と不安定です。最悪AndroidStudio自体を再起動する事になるのでちょっとめんどくさい感はあります。ただ、Java8がAndroid開発に使えない現状不安定にならない構文を選んで使っていくのは十分ありかと思います。(1.4で全滅したら相当めんどくさいリファクタリングしないといけなくなりそうです。)