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

[iD3LSY]

А можешь привести пример того, что ты написал?

Держи, его гит: ку

 

[iD3LSY]

Это старый гит, мой новый здесь - https://github.com/AbstractCoderX/

Ок, буду знать, хотя, это почти одно и тоже (форки)

 

[Exception_Prototype]

Посмотреть вложение 50757

Да это и так понятно, просто ты как-то слишком непонятно(лично для меня) написал.

 

[MrMagaChannel]

Да это и так понятно, просто ты как-то слишком непонятно(лично для меня) написал.

Суть в том, что классу обработки команд не понадобится 5 зависимостей передать при правильной архитектуре.

 

[_MasterCapeXD_]

Короче говоря, это все зависит от ситуации (как и всегда). Когда будут использоваться разные имплементаторы какого-либо интерфейса, то логично, что этот вариант отлично подходит. Но это не значит, что нужно отказываться от getInstance() в любом проекте. Все-же, в каждом классе делать конструктор - зачем? Мы экономим время, когда вызываем getInstance(), а не делаем конструктор, потом инициализируем в каком-то другом классе.

Зачем отказываться от getInstance() во всем проекте, когда конструктор нужен только в нескольких классах, которые без проблем можно проинициализировать в Main (как в данном случае).

 

[hyndorik]

Короче говоря, это все зависит от ситуации (как и всегда). Когда будут использоваться разные имплементаторы какого-либо интерфейса, то логично, что этот вариант отлично подходит. Но это не значит, что нужно отказываться от getInstance() в любом проекте. Все-же, в каждом классе делать конструктор - зачем? Мы экономим время, когда вызываем getInstance(), а не делаем конструктор, потом инициализируем в каком-то другом классе.

Зачем отказываться от getInstance() во всем проекте, когда конструктор нужен только в нескольких классах, которые без проблем можно проинициализировать в Main (как в данном случае).

Ля походу темку ты не читал, так и не понял, что требования могут меняться, а количество имплементаций может меняться со временем как и растет проект

 

[bristol]

Короче говоря, это все зависит от ситуации (как и всегда). Когда будут использоваться разные имплементаторы какого-либо интерфейса, то логично, что этот вариант отлично подходит. Но это не значит, что нужно отказываться от getInstance() в любом проекте. Все-же, в каждом классе делать конструктор - зачем? Мы экономим время, когда вызываем getInstance(), а не делаем конструктор, потом инициализируем в каком-то другом классе.

Зачем отказываться от getInstance() во всем проекте, когда конструктор нужен только в нескольких классах, которые без проблем можно проинициализировать в Main (как в данном случае).

Решай сам что использовать, тут сказали как лучше делать, твое дело юзать это или нет.

 

[hyndorik]

К чему себе жизнь усложнять?

    private Main plugin;

    public EventListener(Main plugin) {
        this.plugin = plugin;
    }

this.plugin.getOne();
this.plugin.getTwo();

Ну во-первых, я типо уже говорил, что может быть ситуация, когда в разных имлементация plugin.getOne() должен будет возвращать разные имлементации.

Вот смотри. есть к примеру класс PacketBuffer. Там куча методов, они никогда все вместе не юзаются одним классом. Но это не мешает ему быть. Дискуссия вообще ни о чем тут.

PacketBuffer не выполняет роль холдера каких-то имплементаций, а просто враппер над ByteBuf

 

[alexandrage]

Ну во-первых, я типо уже говорил, что может быть ситуация, когда в разных имлементация plugin.getOne() должен будет возвращать разные имлементации.


PacketBuffer не выполняет роль холдера каких-то имплементаций, а просто враппер над ByteBuf

Найс отмазка. Зачет.

 

[hyndorik]

Найс отмазка. Зачет.

Почему отмазка?)

 

[_MasterCapeXD_]

Ля походу темку ты не читал, так и не понял, что требования могут меняться, а количество имплементаций может меняться со временем как и растет проект

Я читал тему. Я о том, что не всегда и не везде используються интерфейсы, и в таких случаях удобнее использовать getInstance(). Вот, например, самый обычный getConfig(). Не всегда нужно его получать в подобных ситуациях, так что getInstance() тут отлично подходит. Название темы настолько показывает неприязнь к static ссылке JavaPlugin'a, что создается ощущение, что getInstance() плох в любом случае.

Крч говоря, я о том, что для каждого метода реализации доступа к Main-классу свои случаи использования. В данном примере ты отлично обьяснил почему здесь надо использовать DI, но это не обязательно везде, и есть много моментов, где getInstance() отлично справится с задачей.

 

[hyndorik]

Я читал тему. Я о том, что не всегда и не везде используються интерфейсы, и в таких случаях удобнее использовать getInstance(). Вот, например, самый обычный getConfig(). Не всегда нужно его получать в подобных ситуациях, так что getInstance() тут отлично подходит. Название темы настолько показывает неприязнь к static ссылке JavaPlugin'a, что создается ощущение, что getInstance() плох в любом случае.

Крч говоря, я о том, что для каждого метода реализации доступа к Main-классу свои случаи использования. В данном примере ты отлично обьяснил почему здесь надо использовать DI, но это не обязательно везде, и есть много моментов, где getInstance() отлично справится с задачей.

Ну если у тебя достаточно классов которые не используют интерфейсы, чтоб юзать getInstance, то из этого уже вытекает нарушение одного из SOLID принципов, а именно DIP (Зависимость на абстракциях). А ну и да, к твоему случаю с getConfig. FileConfiguration - абстрактный класс, ConfigurationSection - интерфейс. MemoryConfiguration - имплементация ConfigurationSection. Ну и опять же, даже если это обычные классы, то в будущем через DI в какой-то конкретный класс будет намного легче воткнуть например какой-то унаследованный класс от FileConfiguration, чем если это было бы через getInstance

 

[MrMagaChannel]

Я читал тему. Я о том, что не всегда и не везде используються интерфейсы, и в таких случаях удобнее использовать getInstance(). Вот, например, самый обычный getConfig(). Не всегда нужно его получать в подобных ситуациях, так что getInstance() тут отлично подходит. Название темы настолько показывает неприязнь к static ссылке JavaPlugin'a, что создается ощущение, что getInstance() плох в любом случае.

Крч говоря, я о том, что для каждого метода реализации доступа к Main-классу свои случаи использования. В данном примере ты отлично обьяснил почему здесь надо использовать DI, но это не обязательно везде, и есть много моментов, где getInstance() отлично справится с задачей.

Ну бред же пишешь. Тебе пояснили, что сегодня у тебя в плагине юзается getInstance и все норм, а завтра ты захочешь что-то добавить/изменить и тогда много переписывать придется.
getInstance() используют плагины, которые предоставляют API, но никак не внутри самого себя, а как для внешних пользователей. Ты безуспешно пытаешься оправдать свое неуместное использование getInstance, по твоему коду понятно, что ты любитель переписывать одно и то же много раз, не делай ошибочных выводов.

 

[iD3LSY]

Ну бред же пишешь. Тебе пояснили, что сегодня у тебя в плагине юзается getInstance и все норм, а завтра ты захочешь что-то добавить/изменить и тогда много переписывать придется.
getInstance() используют плагины, которые предоставляют API, но никак не внутри самого себя, а как для внешних пользователей. Ты безуспешно пытаешься оправдать свое неуместное использование getInstance, по твоему коду понятно, что ты любитель переписывать одно и то же много раз, не делай ошибочных выводов.

В чем проблема? :/

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

Эти принципы - это исключительная формальность. Если руки у тебя не из очка растут, то тебе не придется никогда пол проекта переписывать, а доказательство тому - я:

• Я даже с кривыми руками, но никогда не переписывал проект с нуля по глупости;
• Я всегда пользовался отдельными модулями, которые конектил как мини-утилы (например, моя либа. Как понимаешь, я не переписываю всю либу/копирую энный раз в нужный проект, я просто конекчу)

 

[hyndorik]

Эти принципы - это исключительная формальность. Если руки у тебя не из очка растут, то тебе не придется никогда пол проекта переписывать, а доказательство тому - я:

• Я даже с кривыми руками, но никогда не переписывал проект с нуля по глупости;
• Я всегда пользовался отдельными модулями, которые конектил как мини-утилы (например, моя либа. Как понимаешь, я не переписываю всю либу/копирую энный раз в нужный проект, я просто конекчу)

Если, что когда я говорю "копировать" и переиспользовать, это и значит подключать ту либу. С Main.getInstance() ты либу не как не переюзаешь, так как у тебя идет прямая зависимость от Main)

Можешь посмотреть на мой проект - https://github.com/hyndor/SightMenu , все SOLID принципы, DI и IoC соблюдены. Посмотри на сколько легко можно все менять не делая breaking api changes и не переписывая отдельные классы при изменение других.

Ну и как-бы, не следуя SOLID принципам тебе по-любому придется переписывать намного большую часть проекта, чем пришлось бы если бы ты следовал SOLID'у

 

[iD3LSY]

Если, что когда я говорю "копировать" и переиспользовать, это и значит подключать ту либу. С Main.getInstance() ты либу не как не переюзаешь, так как у тебя идет прямая зависимость от Main)

Можешь посмотреть на мой проект - https://github.com/hyndor/SightMenu , все SOLID принципы, DI и IoC соблюдены. Посмотри на сколько легко можно все менять не делая breaking api changes и не переписывая отдельные классы при изменение других.

Ну и как-бы, не следуя SOLID принципам тебе по-любому придется переписывать намного большую часть проекта, чем пришлось бы если бы ты следовал SOLID'у

Почему это? Если у меня все проекты используют именно Main.getInstance(), то все ок, ведь оно использует такие же ссылки на классы (а если нет, то в эклипсе есть кнопочка - Organize imports, она фиксит импорты по всему проекту. В интеллии, должно быть, такое тоже есть).

Переименовал главный класс в Main (а у меня все главные классы называются Plugin), импортнул, а потом назад)

 

[iD3LSY]

Кстати, как раз в твоем проекте, вообще ничего не понятно:

Спойлер: Скрин

Если изначально не разрабатывать бок о бок с тобой, то вообще нихера не поймешь потом)

 

[Reality_SC]

Кстати, как раз в твоем проекте, вообще ничего не понятно ... если изначально не разрабатывать бок о бок с тобой, то вообще нихера не поймешь потом)

Вполне нормальный код. Выглядит понятно, если читать не имена файлов, а содержимое. А ещё лучше начинать изучение кода с readme / вики проекта.

Код, который написан с соблюдением хороших практик, обычно всё-таки легче воспринимается, и уж тем более изменяется (подчеркну, что речь идёт именно о доработках после изначальной разработки).

Друг, тебя ведь никто не заставляет делать именно так. Но в нормальных конторах за такое на ревью всё-таки будут бить по рукам.

 

[hyndorik]

Почему это? Если у меня все проекты используют именно Main.getInstance(), то все ок, ведь оно использует такие же ссылки на классы (а если нет, то в эклипсе есть кнопочка - Organize imports, она фиксит импорты по всему проекту. В интеллии, должно быть, такое тоже есть).

Переименовал главный класс в Main (а у меня все главные классы называются Plugin), импортнул, а потом назад)

Лол а если ты захочешь юзать свою либу в другом проекте где нету Main.getInstance? Все, обосрешься) У меня в проекте все понятно, там везде есть SRP и каждый класс имеет единственную отвественность + есть хорошие доки

 

[iD3LSY]

Вполне нормальный код. Выглядит понятно, если читать не имена файлов, а содержимое. А ещё лучше начинать изучение кода с readme / вики проекта.

Код, который написан с соблюдением хороших практик, обычно всё-таки легче воспринимается, и уж тем более изменяется (подчеркну, что речь идёт именно о доработках после изначальной разработки).

Друг, тебя ведь никто не заставляет делать именно так. Но в нормальных конторах за такое на ревью всё-таки будут бить по рукам.

Какие-то вы слишком тугие. Я вам одно - вы мне другое; я отрицаю обязательство наличия проектом соблюденности этих принципов, но не говорю, что это плохо;

Я абсолютно нейтрален к тому, что на некоторых проектах требуется соблюдения некоторых принципов; форматирования кода. Не агрюсь на это, а просто принимаю, если мне говорят, что должно быть что-то, в основе чего лежит именно давно сформулированная другими кодерами основа.

Лол а если ты захочешь юзать свою либу в другом проекте где нету Main.getInstance? Все, обосрешься) У меня в проекте все понятно, там везде есть SRP и каждый класс имеет единственную отвественность + есть хорошие доки

По себе людей не судят. Тебя же я лицом тыкал в то, что у тебя все главное в одном пекейдже, независимо от назначения классов (отсутствует продуманная структура проекта) .-.