Войти или зарегистрироваться
  • Вы находитесь в сообществе Rubukkit. Мы - администраторы серверов Minecraft, разрабатываем собственные плагины и переводим на различные языки плагины наших коллег из других стран.

Стартап Почему надо использовать DI вместо статической ссылки на Main класс ?

Хмммммммммммммммм, может потому что этот класс хранит граф и обрабатывает его? Зачем выносить шедулер куда то, если ему там самое место? Хотя нет! Давайте в мейн засунем, там вообще круто будет, всегда можно будет найти, и.т.д(сарказм).
Ну вообще в такой системе по-любому будет враппер над бакитовским шедулером. Бакитовские шедулеры убогие же довольно. Бакитовский шедулер в такой системе будет скорее всегда запихнут в ExecutorService, и его скорее всего и будут передавать
 
Ну это кнч хоть и лучше чем getInstance, но все равно такое себе. Пока в твоем Main имеется 1-2 геттера таких еще все более менее хорошо. Если у тебя там больше 3-4 таких геттеров то уже плохо, так как в этом классе может появиться надобность использовать две разные имплементации, которые у Main идут одинаковые. Ну и вообще если тебе нужен только сам объект JavaPlugin и MessageManager то в конструкторе лучше их и передавать.
Код:
class Some {
 
    private JavaPlugin plugin;
    private MessageManager messageManager;
 
    public Some(JavaPlugin plugin, MessageManager messageManager) {
        this.plugin = plugin;
        this.messageManager = messageManager;
    }
 
}
Такая реализация будет намного лучше
а если нужно например много зависимостей, например DatabaseManager, MSGManager и CFGManager, то нужно так?
Код:
private JavaPlugin plugin;
private MSGManager msgmanager;
private CFGManager cfgmanager;

public Events(JavaPlugin plugin, MSGManager msgmanager, CFGManager cfgmanager) {
    this.cfgmanager = cfgmanager;
    this.msgmanager = msgmanager;
    this.plugin = plugin;
}
}
 
а если нужно например много зависимостей, например DatabaseManager, MSGManager и CFGManager, то нужно так?
Код:
private JavaPlugin plugin;
private MSGManager msgmanager;
private CFGManager cfgmanager;

public Events(JavaPlugin plugin, MSGManager msgmanager, CFGManager cfgmanager) {
    this.cfgmanager = cfgmanager;
    this.msgmanager = msgmanager;
    this.plugin = plugin;
}
}
Если у тебя слишком много зависимостей то ты не до-конца прочитал мою тему - upload_2018-5-9_0-20-22.png
Ну тот код который ты кинул сейчас там 3 зависимости, вполне нормально
 
а если нужно например много зависимостей, например DatabaseManager, MSGManager и CFGManager, то нужно так?
Код:
private JavaPlugin plugin;
private MSGManager msgmanager;
private CFGManager cfgmanager;

public Events(JavaPlugin plugin, MSGManager msgmanager, CFGManager cfgmanager) {
    this.cfgmanager = cfgmanager;
    this.msgmanager = msgmanager;
    this.plugin = plugin;
}
}
К чему себе жизнь усложнять?

Код:
    private Main plugin;

    public EventListener(Main plugin) {
        this.plugin = plugin;
    }
this.plugin.getOne();
this.plugin.getTwo();
 
К чему себе жизнь усложнять?
this.plugin.getOne();
this.plugin.getTwo();
Теперь класс Events получил зависимость от example.plugin1.Main и не может быть скопипащен в plugin2.
Так сказать, он завязан на большее число зависимостей, нежели ему на самом деле нужны.
 
Теперь класс Events получил зависимость от example.plugin1.Main и не может быть скопипащен в plugin2.
Так сказать, он завязан на большее число зависимостей, нежели ему на самом деле нужны.
И что? От этого ему хреного не стало.
 
Вот смотри. есть к примеру класс PacketBuffer. Там куча методов, они никогда все вместе не юзаются одним классом. Но это не мешает ему быть. Дискуссия вообще ни о чем тут.
 
Вот смотри. есть к примеру класс PacketBuffer. Там куча методов, они никогда все вместе не юзаются одним классом. Но это не мешает ему быть. Дискуссия вообще ни о чем тут.
Нарушен принцип единственной ответственности.
 
А теперь представь, что у меня овер90 классов ивентов и всем нужны разные методы Main. Мне им лепить 90 интерфейсов? Чет как то НЕТ.
 
А теперь представь, что у меня овер90 классов ивентов и всем нужны разные методы Main. Мне им лепить 90 интерфейсов? Чет как то НЕТ.
Каждому классу ивента необходимы лишь свои компоненты и класс не должен знать ничего о том, что ему не нужно. Каждому классу просто нужно передать то, что он должен использовать, не больше, не меньше.
 
И что? От этого ему хреного не стало.
Ему не стало, в данный момент. Стало хуже тому программисту, который это потом захочет переиспользовать. Грустно знать, что ты уже написал код, который делал нужную тебе работу, но не можешь его просто взять. Либо тяжелый рефакторинг.
 
А теперь представь, что у меня овер90 классов ивентов и всем нужны разные методы Main. Мне им лепить 90 интерфейсов? Чет как то НЕТ.
Нет необходимости делать им интерфейсы, если они не требуются друг другу. Методы из Main -- о каких речь? Если баккитовские, сужаем до JavaPlugin (или Plugin, по возможности), если свои, то тут тоже много вариантов к действиям.
 
Ему не стало, в данный момент. Стало хуже тому программисту, который это потом захочет переиспользовать. Грустно знать, что ты уже написал код, который делал нужную тебе работу, но не можешь его просто взять. Либо тяжелый рефакторинг.
В чем проблема? :/

Всегда пишу отдельными модулями дополнения, а потом просто леплю их к проекту при компиляции... Намного практичнее, нежели копировать из каждого проекта засоряя диск дубликатами кода, при том, устаревшими относительно последних версий, дубликатами.
 
Каждому классу ивента необходимы лишь свои компоненты и класс не должен знать ничего о том, что ему не нужно. Каждому классу просто нужно передать то, что он должен использовать, не больше, не меньше.
Я чет запутался. То есть, например, есть у меня класс команды какой нибудь. Мне там нужны такие классы как: CFGManager, MSGManager, CheckerManager, BuildManager и объект JavaPlugin, возможно еще классы будут. Вот если они все необходимы и я их передам, будет ли это нарушением солид принципов?
 
Я чет запутался. То есть, например, есть у меня класс команды какой нибудь. Мне там нужны такие классы как: CFGManager, MSGManager, CheckerManager, BuildManager и объект JavaPlugin, возможно еще классы будут. Вот если они все необходимы и я их передам, будет ли это нарушением солид принципов?
Ты должен разбить класс обработки команд на архитектуру классов и каждый компонент получит только то, что будет использовать.
 
Ты должен разбить класс обработки команд на архитектуру классов и каждый компонент получит только то, что будет использовать.
А можешь привести пример того, что ты написал?
 

Поделиться этой страницей

Назад
Верх