3

将来の内部認証ライブラリに使用することを意図したクラスがあります(そのような既存のライブラリが既にあることは知っています)。したがって、今後の多くのプロジェクトで開発者がこのライブラリを利用できるように、可能な限り単純にするために、役割を持つ列挙型を定義することを念頭に置いていました。単純な例では、役割 sysadmin です。

// Not a project specific class, but Auth is intended to be part of the library
class Auth {

        public static enum AUTH_ROLE {
            sysadmin( new Rule(AdminController.class, "*") );

            private String name;

            AUTH_ROLE() {
                name = this.name();
                Roles.add( name );
            }
            AUTH_ROLE(String name) {
                this.name = name;
                Roles.add( name );
            }

            AUTH_ROLE(Rule rule) {
                name = this.name();
                Roles.add( name, rule );
            }
            AUTH_ROLE(String name, Rule rule) {
                this.name = name;
                Roles.add( name, rule );
            }
            public String getName() {
                return name;
            }
        }

        public boolean hasRole(AUTH_ROLE role) {

            String[] usersRoles = getLoggedInUsersRoles();

            for ( String userRole : usersRoles ) {
                if ( role.getName().equals(userRole) )
                    return true;
            }

            return false;
        }

    }

現在、ご覧のとおり、enum AUTH_ROLEは現在、プロジェクト固有ではないクラスであると想定されているもので*定義されています*が、Auth クラスは、多くのプロジェクトで使用されるライブラリの一部であると想定されています。

問題は、現在の設計では、メソッド hasRole ( AUTH_ROLE ...) を定義するために、ロールとそのルールを同じクラス Auth で定義する必要があることです ...

私がやりたいことは、すべてのプロジェクトに対して一度だけ定義された現在のすべてのロジックを含むこの列挙型を作成し、新しいプロジェクトの開発者が役割とそのルールを定義するだけで済むようにすることです。

私が信じている問題は、Javaで列挙型を拡張できないことです。そのため、列挙型ロジックのすべて（単純ですが、重要ではありません！）を実際に新しいプロジェクトごとに繰り返し、ライブラリで提供される実装とインターフェースを実装する必要があります。 .

拡張が可能であれば、新しい列挙型でこれらのロールを簡単に定義できたはずです。つまり、次のようになります。

public enum AUTH_ROLE extends authlibrary.Auth.AUTH_ROLE {
    sysadmin( new Rule(AdminController.class, "*") );
}

もう1 つのオプションは、先ほど述べたように、enum を実装するためのインターフェイスを定義することですが、理解できるように、新しいプロジェクトごとに実装することになりますが、それはコピー アンド ペーストと同じくらい簡単です。

メソッドを呼び出す前に何かを文字列や数値に変換することには興味がありません...この質問は、言語の*制限*を回避する方法についてではなく、単に同意/受け入れることですこれは、他の方法ではよりクリーンなコードにつながる制限です。

したがって、この特定のケースでは、別の列挙型を拡張/含めることが有益であり、結果としてコードが少なくなることに同意する人はいますか?

Ps。私はばかかもしれないので、私は自分自身をばかと呼ぶ権利を留保したい:)

4

2 に答える 2

6

この質問を自問してください。なぜこれを列挙型にする必要があるのですか? あなたのコードが、決して拡張できない定義済みの既知のアイテムのセットを扱っていない場合、あなたが持っているものは実際には列挙型にはまったく適しておらず、定義済みのベースを拡張するシングルトンオブジェクトを使用する方が良いかもしれませんクラス。

列挙型の便利な機能 (組み込みの文字列/序数変換機能) を使用していない場合、なぜそれらを使用するのでしょうか? そして、これらの便利な機能は、あなたが説明した状況では機能しません。すべての列挙値の名前を知る必要があるコードを生成する必要があるためです。これは今では不可能です。

于 2012-04-12T09:19:05.620 に答える
5

これがどのように価値があるかわかりません。継承や拡張が常に答えだとは思いません。列挙型にさらに値が必要な場合は、それらを追加します。私は、コードがよりきれいになったこと、またはこれが言語の重大な制限を表していることに同意しません。

于 2012-04-12T09:10:24.617 に答える