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

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

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

 

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

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

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

 

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

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

 

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

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

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

 

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

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

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

 

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

 

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

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

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