Псс, братишь, инкапсуляция, да, слышал? На пакеты раскладывают все по логическим составляющим проекта. Походу вообще никогда на нормальные проекты не смотрел. Советую тебе открыть хотя бы guava какой-нибудь и заглянуть в какой-нибудь из пекейджов например - com.google.common.collect, инкапсуляции принцип даже не понимаешь.
Ну да - все правильно, проект не обязан соблюдать эти принципы, но без них архитектура говно получается(
Ты хочешь сказать, что у тебя все 26 классов связаны логически между собой? SessionResolver <-> ItemStackBuilder - какая между ними связь?
Ну интерфейсы если че много используются) И как ты представляешь себе делать нормальную инкапсуляцию при таком разделение на пакеты?)
Хз, хз... Смотря о чем ты говоришь)
Ну например MenuItemBuilder и SessionResolverImpl имеют конструктор package private и инициализируются через фактори обджект MenuApiInstance, если я запихну MenuItemBuilder в отдельный пекедж типо builder, ему придется делать паблик конструктор, а я в своем апи хочу иметь на будущее прослойку через MenuApiInstance, так что такое разделение хреновенько будет
Хорошо сказано. Не могу больше придраться к структуре. Ну ок!
Честно говоря не совсем понимаю смысловую нагрузку от твоего комента. Что ты призываешь использовать? Со стороны TDD подход через getInstance всегда плох. DI всегда значительно облегчает поддержку кода. Ну и тут вообще не понятно в каком контексте ты говоришь об синглтоне. Имея ioc container метод инстенса иметь совсем не обязательно, при этом он будет оставаться синглтоном, ну кнч со своими особенностями взависимости от контейнера
Не всегда.
Ну слушай, если ты отрицаешь мое утверждение, которое полностью расписано в статье, то хотя бы приведи примеры затруднения поддержки кода при использовании DI. А то немного смешно получается, если читать твое сообщение
Смысловая нагрузка простая - если весь плагин это 1000 строк, то смысла от всех этих энтерпрайзных методов разработки никакого. Для плагина такого размера и тесты то не пишут, и тз зачастую существует на уровне головы одного человека. Потратишь больше времени на написание обвязки чем на сам плагин. А таких плагинов 99% от всех плагинов.
Ну необязательно же спринг тащить) Есть guice - он весит около 0.7мб. Да и был еще вообще ультра легковесный какой-то около 0.2мб. Ну кнч на хеллоу ворлд контейнеры тащить смысла нет. Ну а если вообще в коде больше 1000 строк, то толк от юзания TDD подхода будет, так как проект скорее всего хоть как-то вырастет. Ну и вообще для меня даже мелкие плагины приятнее и быстрее писать с DI, ну и с подходом TDD. Да и DI так-то не энтерпрайзная фича, а юзается везде) Написание конструктора вместо создания статической ссылки почти никакого времени при разработке не отнимает, но сразу приучает правильно думать. А то человек постепенно пишет проекты больше чем хелоу ворлды, а архитектура остается на уровне хелоу ворлдов. Ну и я вообще для большинства своих проектов пишу тесты, банально даже из-за того, что лень сервер запускать, финальный тест в майне и он почти всегда корректно работает с первого раза
1000 строк может быть и вполне законченным плагином, у меня на гитхабе таких вагон и маленькая тележка.
При правильной архитектуре объектам редко будет нужно запускать шедуляр, а только каким-то управляющим классам.
А что сам шевчик может сказать по этой теме?
Да вроде все сказал выше он.
Ну контейнер и на асм может быть, тем более в пепере сразу ведь асм зашарен. Ну и вот насчет отучить людей, здесь как раз таки в теме приводятся минусы заюзывания такого. Тащить через череду объектов в большинстве случаев не надо, если нормально реализованы фабрики, да и уж создать конструктор нажав реальную одну кнопку в интелии не так уж и сложно, потратив на это на 1мс больше.
Ну ты походу тему вообще не читал)
а, я прост не читал всю тему
Тут не бред написан в общем-то. Очень даже полезные советы, но очень плохо расписаны плюсы и минусы такого подхода. Написанное здесь стоит взять на заметку людям которые пишут огромные плагины. У меня тоже есть некоторые плагины в которых бы контейнер с депенденси менеджментом ой как бы пригодился, но так как я уже сделал всё херово, то перепысывать ни сил ни времени.