Java видимый интерфейс, который не может быть реализован - PullRequest
0 голосов
/ 01 мая 2019

Я работаю над созданием языка программирования, который компилируется в байт-код JVM, и он очень полагается на интерфейсы как типы. Мне нужен какой-то способ сделать интерфейс закрытым, но у другого кода все еще будет возможность получить к нему доступ, но не делать что-то, что его реализует.

Я думал об использовании абстрактных классов с закрытым конструктором, поэтому только классы в одном файле смогут получить к нему доступ. Единственная проблема состоит в том, что невозможно расширить несколько абстрактных классов одновременно. Например, структура простой скомпилированной программы будет такой:

// -> Main.java
public class Main {
    public static MyInteger getMyInteger() {
        return new MyIntegerImpl(10);
    }

    public static void main(String[] args) {}

    private interface MyInteger {
        public int getValue();
    }

    private static class MyIntegerImpl implements MyInteger {
        private final int value;

        public int getValue() {
            return value;
        }

        public MyIntegerImpl(int value) {
            this.value = value;
        }
    }
}

И еще один файл, в котором есть проблема:

// -> OtherFile.java
public class OtherFile {
    public static void main(String[] args) {
        Main.MyInteger myInteger = Main.getMyInteger(); //Error: The type Main.MyInteger is not visible.
        System.out.println(myInteger.getValue());
    }

    //I do not want this to be allowed
    public static class sneakyInteger implements Main.MyInteger { //Error(Which is good)
        public int getValue() {
            System.out.println("Person accessed value");
            return 10;
        }
    }
}

Причина, по которой я хочу сделать это, заключается в том, что один человек не может испортить код любого другого человека, предоставляя свои собственные реализации вещей, которые должны быть реализованы только этим другим человеком.

Любая помощь будет высоко ценится.

1 Ответ

2 голосов
/ 01 мая 2019

Я почти уверен, что вам следует снова подумать о том, что вы пытаетесь сделать, и изменить подход, но ответ на ваш вопрос заключается в добавлении в интерфейс некоторого пустого void метода, который получает параметр внутреннегоprivate класс, специфичный для класса-оболочки

public class Test {
    private class InnerPrivateClass {
        private InnerPrivateClass() {}
    }

    public interface MyInteger {
        int getValue();

        void accept(InnerPrivateClass c);
    }

    private class MyIntegerImpl implements MyInteger {
        @Override
        public int getValue() {
            return 0;
        }

        @Override
        public void accept(InnerPrivateClass c) {}
    }
}

Однако, как я уже сказал, мне это не нравится, и для меня это означает, что ваша идея нарушена

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...