Разобраться в системе интерфейсов не могу.

  • Автор темы Автор темы FAQCoder
  • Дата начала Дата начала
Статус
Закрыто для дальнейших ответов.

FAQCoder

Активный участник
Пользователь
Баллы
61
Здравствуйте, на днях пробовал систематизировать пару проектов. Наткнулся на очень интересный код:
PHP:
interface Art extends InventoryHolder{
void draw();
Pickture build(int slot, Player p);
}
interface Pickture{
void give();
}

public class ArtListener implements Listener {
    @EventHandler
    public void onClick(InventoryClickEvent event) {
InventoryHolder holder = event.getInventory().getHolder();
if(holder instanceof Art){
Art art = (Art)holder.getMenu();
Picture pic = art.build(event.getSlot(), (Player)event.getWhoClicked());
}
}
На фоне происходит какойт билд и все выполняется. Понять не могу че за билд происходит, все классы перерыл, ничего толком не нашел. Слышал про callback, но не особо въехал как он работает. Можно ли как-то на фоне реализовывать интерфейсы по условию предположим.
 
Здравствуйте, на днях пробовал систематизировать пару проектов. Наткнулся на очень интересный код:
PHP:
interface Art extends InventoryHolder{
void draw();
Pickture build(int slot, Player p);
}
interface Pickture{
void give();
}

public class ArtListener implements Listener {
    @EventHandler
    public void onClick(InventoryClickEvent event) {
InventoryHolder holder = event.getInventory().getHolder();
if(holder instanceof Art){
Art art = (Art)holder.getMenu();
Picture pic = art.build(event.getSlot(), (Player)event.getWhoClicked());
}
}
На фоне происходит какойт билд и все выполняется. Понять не могу че за билд происходит, все классы перерыл, ничего толком не нашел. Слышал про callback, но не особо въехал как он работает. Можно ли как-то на фоне реализовывать интерфейсы по условию предположим.
Ищи класс который реализует интерфейс Picture. В нем найдёшь реализацию этого метода.
 
Ищи класс который реализует интерфейс Picture. В нем найдёшь реализацию этого метода.
Проще говоря можно, все таки оформить методы интерфейса без вызова эксемпляра реализующего класса?
 
Собстно вот тебе наглядный пример. Там где @Override это реализация метода интерфейса.
Методов может не быть у интерфейсров, как у Listener. Там он просто используется для метода registerEvents.
Код:
public class Menu implements InventoryHolder, Listener {

    public Menu(Plugin plugin) {
        plugin.getServer().getPluginManager().registerEvents(this, plugin);
    }

    private Inventory inventory;
    private List<Stack> stack;

    @EventHandler
    public void on(InventoryClickEvent e) {
        Inventory inv = e.getClickedInventory();
        if (inv != null && inv.getHolder() instanceof Menu) {
            e.setCancelled(true);
            this.stack.get(e.getSlot()).runCommand();
        }
    }

    public Menu(String title, int line, List<Stack> stack) {
        this.inventory = Bukkit.createInventory(this, 9 * line, title);
        this.stack = stack;
    }

    @Override
    public Inventory getInventory() {
        return this.inventory;
    }
}
 
Проще говоря можно, все таки оформить методы интерфейса без вызова эксемпляра реализующего класса?
Верно. Интерфейс вообще не знает кто его наследует и как именно реализованы его методы.
 
Верно. Интерфейс вообще не знает кто его наследует и как именно реализованы его методы.
Странно, я очень много прочитал про эти интерфейсы, я особо не нашел пути заочной реализации. Вроде нашел класс SimplePickture который реализует нужный интерфейс, но связи в классе евента с классом реализующим интерфейсы через конструктор с приватными полями, так и не нашел.
 
Странно, я очень много прочитал про эти интерфейсы, я особо не нашел пути заочной реализации. Вроде нашел класс SimplePickture который реализует нужный интерфейс, но связи в классе евента с классом реализующим интерфейсы через конструктор с приватными полями, так и не нашел.
Оно где то в реализации некого Art или где то дальше.
 
Собстно вот тебе наглядный пример. Там где @Override это реализация метода интерфейса.
Методов может не быть у интерфейсров, как у Listener. Там он просто используется для метода registerEvents.
Код:
public class Menu implements InventoryHolder, Listener {

    public Menu(Plugin plugin) {
        plugin.getServer().getPluginManager().registerEvents(this, plugin);
    }

    private Inventory inventory;
    private List<Stack> stack;

    @EventHandler
    public void on(InventoryClickEvent e) {
        Inventory inv = e.getClickedInventory();
        if (inv != null && inv.getHolder() instanceof Menu) {
            e.setCancelled(true);
            this.stack.get(e.getSlot()).runCommand();
        }
    }

    public Menu(String title, int line, List<Stack> stack) {
        this.inventory = Bukkit.createInventory(this, 9 * line, title);
        this.stack = stack;
    }

    @Override
    public Inventory getInventory() {
        return this.inventory;
    }
}
Как-же тот-же Bukkit api, и интерфейс Player, где нету никакой реализации и default полей очень мало. Мы же не создаем предположим CommandExecutor, где еще и методы Player реализовываем.
 
Так где-то в коде создается инвентарь и плагин открывает его игроку, там скорее всего лямбда
ищи в коде Player#openInventory(Inventory)

А в bukkit api интерфейс Player нужен, чтобы ограничить использующего от некоторых методов
Где-то читал про интерфейсы, мол, интерфейс это как пульт от телевизора, тебе не нужно знать, как реализован телевизор, ты просто пользуешься пультом
 
Последнее редактирование:
Как-же тот-же Bukkit api, и интерфейс Player, где нету никакой реализации и default полей очень мало. Мы же не создаем предположим CommandExecutor, где еще и методы Player реализовываем.
Там уже все реализовано, умник. А ты юзаешь уже готовое апи и все.
Ты еще слишком тупенький для ооп программирования.
 
Последнее редактирование:
Предположим я нашел все классы которые реализуют нужные мне интерфейсы, так-же наткнулся на мнимое расширение Art:
default Pickture build(int raw, int cal){
return build(raw,cal);
}
+ еще нашел множество реализаций интерфейса, абстрактными и обычными классами.
 
Там уже все реализовано, умник. А ты юзаешь уже готовое апи и все.
Ты еще слишком тупенький для ооп программирования.
Как тогда объяснить ссылки на интерфейсы? В которых кроме методов ничего нету. Чекал на github & decompiler что-бы разобраться, в итоге опять нашел класс реализации, который не имеет никакого прямого отношения к использованию api в целом. Просто его реализация. Возник вопрос, как тогда сделать реализацию интерфейса в другом классе, получается без прямой ссылки на сам реализующий класс и его эксемпляры?
Получается я вызываю тот-же метод, player.getHeath(); только Player это интерфейс который реализуется в 2-3 классах. Ссылка на getHeath() ведет только на метод интерфейса. А не на его реализацию, которая похоже скрыта. Зацепок на реализующий класс, тоже не найти.
 
Последнее редактирование:
Как тогда объяснить ссылки на интерфейсы? В которых кроме методов ничего нету. Чекал на github & decompiler что-бы разобраться, в итоге опять нашел класс реализации, который не имеет никакого прямого отношения к использованию api в целом. Просто его реализация. Возник вопрос, как тогда сделать реализацию интерфейса в другом классе, получается без прямой ссылки на сам интерфейс.
Ядро создаёт объекты - это CraftBukkit. Эти объекты реализуют интерфейсы Bukkit API.
У тебя есть Bukkit.getServer() который всегда возвращает тебе org.bukkit.Server - класс апи. Но по факту это объект реализации - т.к. org.bukkit.craftbukkit.v.CraftServer. Ты можешь это проверить - либо вывести куда-то название класса объекта, либо просто взять и кастануть.
И так работает абсолютно всё в Bukkit.
Реализация интерфейса: MyRealisation implements MyInterface
 
Ядро создаёт объекты - это CraftBukkit. Эти объекты реализуют интерфейсы Bukkit API.
У тебя есть Bukkit.getServer() который всегда возвращает тебе org.bukkit.Server - класс апи. Но по факту это объект реализации - т.к. org.bukkit.craftbukkit.v.CraftServer. Ты можешь это проверить - либо вывести куда-то название класса объекта, либо просто взять и кастануть.
И так работает абсолютно всё в Bukkit.
Реализация интерфейса: MyRealisation implements MyInterface
Окей, я знаю есть CraftPlayer где есть относительная реализация интерфейса Player. Как мне сделать реализацию интерфейса в левом классе предположим:
PHP:
interface Head {
Pickture getPickture();
Sting name(Pickture name, String... args);
default String name(Pickture name){
return name(name, null);
}
}
public class Realise implements Head{
private Pickture pick;
public Realise(final Pickture pick){
this.pick = pick;
}
@Override
Pickture getPickture(){
return this.pick;
}
@Override
String name(Pickture name, String... args){
if(args.lenght > 100){
throw new ....
return null;
}
return name.getName(); // interface Pickture{void build(int slot, Player p) String getName();}.
}

}
public class AnyClass extends Realise{
public AnyClass(Pickture realise){
...
}

}
public class EventConsumer implements Listener{
@EventListener
public void anyEvent(AnyEvent e){
System.out.print(Head.getName()); // HOW  TO?
}
}
Что-бы по 100 раз не вызывать эксемпляр реализации и его конструктор, предположим он был уже вызван и реализован. Тоесть не писать Head head = new Realise(args);
 
Как мне тогда показать компилятору, реализацию и предположим свой интерфейс API?
 
Окей, я знаю есть CraftPlayer где есть относительная реализация интерфейса Player. Как мне сделать реализацию интерфейса в левом классе предположим:
PHP:
interface Head {
Pickture getPickture();
Sting name(Pickture name, String... args);
default String name(Pickture name){
return name(name, null);
}
}
public class Realise implements Head{
private Pickture pick;
public Realise(final Pickture pick){
this.pick = pick;
}
@Override
Pickture getPickture(){
return this.pick;
}
@Override
String name(Pickture name, String... args){
if(args.lenght > 100){
throw new ....
return null;
}
return name.getName(); // interface Pickture{void build(int slot, Player p) String getName();}.
}

}
public class AnyClass extends Realise{
public AnyClass(Pickture realise){
...
}

}
public class EventConsumer implements Listener{
@EventListener
public void anyEvent(AnyEvent e){
System.out.print(Head.getName()); // HOW  TO?
}
}
Что-бы по 100 раз не вызывать эксемпляр реализации и его конструктор, предположим он был уже вызван и реализован. Тоесть не писать Head head = new Realise(args);
Это уже не вопрос интерфейсов. Храни где-то свои Realise
 
Это уже не вопрос интерфейсов. Храни где-то свои Realise
Я для яркого примера обозначил код. В принципе вообще как может выглядеть api реализация интерфейса & реализующего метода, что-бы ссылка на метод вела к интерфейсу?
 
Я для яркого примера обозначил код. В принципе вообще как может выглядеть api реализация интерфейса & реализующего метода, что-бы ссылка на метод вела к интерфейсу?
Выше alexandrage привёл пример. Если у тебя всё так туго - лучше садись за уроки по Java
 
Последнее редактирование:
Статус
Закрыто для дальнейших ответов.
Назад
Верх