Минусуйте сколько влезет, но боже мой, как вы надоели со своим тестированием. Создали целую мини-индустрию вокруг стандартного процесса разработки ПО, чтобы наживаться на людях, не имеющих образования, с баннерами вроде "освой карьеру в ИТ! Получай 200к в месяц!", раздаете титулы вроде "QA-профессионалов", как будто это вообще что-то значит. Сходи в институт, получи диплом, вот это будет что-то значит. Я может и далек от реального положения дел, но последний раз я проверял, это программист должен тестировать свой код. Это называется "твоя работа". Более тесные интеграции ему может помочь тестировать дев-оп. Какие учебники, какие 40 модулей, включая о Линуксе ?♀️ Ну если есть предложение наверное есть спрос. Полное вырождение индустрии. Когда раньше один профессионал мог в фотошопе нарисовать компонент, сверстать его, написать код и протестировать, теперь это -- дизайнер, верстальщик, дев, тестировщик.
Что значит с дизайном реализации можно не заморачиваться? Я заморочился и сделал самым простым возможным способом, чтобы доказать работоспособность метода. Ты говоришь, что все, что я написал -- это просто трейты, а я говорю что нет, что трейтами реализован принцип дизайна.
Красота -- это самое объективное понятие в мире. Чем больше развиваешься, тем больше видишь красивые вещи. Говорят что красота субъективна обычно те, кто ничего в этом не понимает.
Ну и что ты дальше написал? "А вот правильно ли вообще в данном месте реализовывать этот функционал?". Давай еще обсудим "а вот правильно ли вообще было идти программистом?" Почему такое отношение к профессионалам, как к полным дегенератам, которые не умеют думать? Что значит "правильно ли вообще реализовывать функционал" -- ну если мне нужна зависимость, то да, конечно правильно.
И я предлагаю вместо того, чтобы 40 классам делать одно и тоже свойство, выделить его и интерфейс, вернее даже специальную категорию интерфейсов, и имя им даже подобрал -- универсалии. Это вообще основной DRY. В чем ваша проблема всех? Зачем начинать упираться, приводить какие-то доводы доведенные до экстрима "перестают думать а нужен ли вообще функционал", минусовать комментарии автора, ничего конструктивного не приводя.
И к тому же, это не просто "добавить аннотацию". @Inject это просто добавить аннотацию. Тут же наоборот у тебя больше контроля к тому, что происходит, когда ты создаешь экземпляры через конструкторы, которым передаешь универсалии, ты уже знаешь, что используешь паттерн.
Хорошо даже если читают, то чем традиционный @Inject лучше? Там ровно тем же образом не будет ничего прописано в коде, никто ничего не сможет прочитать.
показываем/прячем элемент (возможно, с каким-то эффектом)
добавляем / убираем класс элемента (.Hidden, .Shown)
модифицируем аттрибуты элемента (включая стиль)
Обновляем список, из которого берутся данные для отображения
возьмем простой метод компонент:
function Render({propA, propB, list}) {
// some hook calculations
var [b]=useSomething([])
return (<div data-a={propA} disabled={propB}>
{list.map(a=><ListItem item={a} b={b} />)}
</div>)
}
Это твой любимый "неимперативный" метод. Только дело в том, что он такой же неимперативный, как и недекларативный. Настоящий декларатив -- это CSS, ты прописал пару правил, они распарсились и показались тебе, при этом ты вообще не знаешь, как. Компоненты вроде реакта -- это не декларативный код. Декларативный код подразумевает, что ты задал какие-то правила, и они магическим образом показываются. В примере выше нет ничего магического: если изменилось свойство и нужно лишь поменять аттрибут "data-a", помимо VDom о котором ты говоришь, будет перевыполнен ВЕСЬ код как самого компонента, включая хуки (вся стена хуков), так и детей, который находятся в списке. Это друг ни разу не декларатив, это просто сотейник со спагетти. Я на 100% за то, что не нужно писать императивный код, потому что веб страницы - это тип систем, которые остаются запущенными, в отличие от вон ноймановских программ, которые получили input и отдали output. Тут нужны стратегии по data-flow, но реакт - это не лучшая стратегия. VDom вообще не нужен. Представь, что метод Render можно проанализировать заранее, и выяснить, что data-a зависит от свойства propA, и поэтому когда propA меняется, мы исполним только ту часть, которая бы была ответственна за это. То есть функция компонента разбивается на 3 рендера:
function RenderA({propA}) {
return (<div data-a={propA} />)
}
function RenderDisabled({propB}) {
return (<div disabled={propA} />)
}
function RenderList({list}) {
var [b]=useSomething([])
return (<div>
{list.map(a=><ListItem item={a} b={b} />)}
</div>)
}
Каждая из функций делает только свою часть по отрисовке, и реагирует только на определенное свойство, от которого зависит. Это, конечно, возможно только если у нас уже есть стандартный Домовский элемент, которым можно манипулировать. И сделать это очень даже можно, если только перестать думать в "функиональном" стиле, который является тупиком и ничего по-настоящему интересного, как выше, не дает, а уж тем более не является декларативным.
Я лишь описал принцип, концепт дизайна. То, как его позволяет реализовать Джава - это проблема Джавы. Я не знаю, чем он вам недостаточно гибок, любые конкретные пожелания можно обсудить.
Зачем читать передачу / получение зависимостей? Нужно ли это? В ваших интерфейсах будет описано, какие зависимости они могут иметь. И кто читает библиотеки? 1% мейнтейнеров? Библиотеки не читают а устанавливают. Еще раз повторюсь, видеть как передается определенный параметр может и нужно, зачем видеть передачу зависимостей и что может быть такого ужасного если ее не прочитают, я не знаю.
Интерфейс - понятие дизайна. Трейты - поняти имплементации. Универсалия - это специальный тип интерфейса, имеющий только одно свойство, указывающее на объект зависимости. интерфейсы с дефолтными методами - это способ их реализации. Про публичные методы я и написал в "ограничения". Это не моя проблема - это проблема Java, которая не дает нормально выполнить принцип дизайна ПО, о чем я так же написал. Но всем конечно, пофигу, на такое абстрактное понятие, как дизайн, потому что его никто не понимает, всем нравится писать уродский код.
Нет, я неправильно сказал, не своего "дерева", а только своего уровня в дереве, то есть не лезть в перерисовку детей вообще. То есть не "исполнять нужно будет только этого ребенка" как ты говоришь, а "исполнять нужно будет только этого ребенка и все его дерево". С другой стороны, можно сделать так, что если у ребенка что-то изменилось, он сам перерисует тот кусок, который изменился. vDOM - очень неэффективный способ решения этой проблемы. Места искать не нужно, они должны быть уже известны за счет того, что в идеале мы можем знать, какое свойство влияет на какую отрисовку.
во-первых, не глобальная коммуникация, а локальная, то есть компонент-компонент, а не компонент -> хранилище состояния -> компонент. у моих компонентов уже есть состояния, зачем мне создавать какие-то там хранилища, и через них обмениваться? во-вторых, событейная модель подходит не до конца, потому что она не реактивна, зачем мне подписываться на какие-то там события, если значение переменной в состоянии одного компонента напрямую, по формуле, зависит от значения состояния в другом компоненте? Из вашей логики, мол вот вам стандарт "веб-компонентов", который по сути своей не привносит ровным счетом ничего (что такое "точка сборки"), а чтобы решить реальную, насущую проблему - делайте что хотите. Да я хочу чтобы мне дали единственную правильную архитектуру, иначе зачем вообще тогда делать специальный стандарт компонентов, если потом все равно приходится к нему прикручивать базовую функциональность обмена сообщениями между ними?
Что значит не предназначен? Взаимодействие между компонентами - это фундаментальная проблема пользовательского интерфейса. Есть 3 уровня для веб-разработки: презентация (стили, классы), интеракция с пользователем (нажал кнопку -> что-то произошло) и коммуникация (передать сообщение другому компоненту / получить сообщение от другого компонента), напр, вышел из системы - поле комментариев погасло. Как вы можете говорить, что API веб-компонентов не предназначен для обмена данных между ними? А что тогда предназначено? Вернее, то что вы говорите это на данном этапе правда, и в этом и есть проблема: что внешний вид / интеракции можно спокойно писать и на чистом HTML/JS, а вот реактивную коммуникацию между компонентами никто не потрудился устроить, которая является самой актуальной проблемой. Ну и зачем они тогда нужны без протокола коммуникации?
Ты 100% прав, я же добавлю, что математически чистая функция - это не так уж и приятно. Даже если взять реакт, скажем у компонента 10 детей, а если обновилось только 1 его свойство, которое затрагивает только 1 ребенка, нужно идти в каждого из ребенков и исполнять его как чистую функцию, чтобы смотреть, не нужно ли что перерисовать. Поэтому и говорят, что "реакт на самом деле не реактивен". Чистые функции для отрисовки UI, которые все так боготворят, это на самом чистый фаб, просто хак оттого, что никто не знает, как правильно сделать. не легче ли каждому компоненту иметь свои свойства, и если эти свойства меняются, давать ему перерисовывать только свое дерево, причем реально только в тех местах, где надо?
да кому нужны ваши веб-компоненты, если главная проблема -- не сами компоненты и их стили, а общение между ними, протокол которого напрочь отсутствует как концепт в текущей html 5 модели веб-компонентов. что значит общение? вот есть кнопка, я ее нажал, я хочу, чтобы изменилось состояние другого компонента, например, кол-во кликов. А если кол-во кликов больше 10, то я хочу изменить еще другое свойство еще другого компонента. В первом вопросе поможет событейная модель: onClick -> component.incrementClicks(). Со вторым поможет только фреймворк, и в этом все горе, что в html 5 просто не продумана реактивность, которая свойственна всем persistent системам (то есть тем системам, которые запускаешь и они продолжают работают, а не просто выводят результат). Сколько бы ни пилили сами компоненты, пока не реализуют eventual transconsistency (правильное название реактивности) на уровне протокола, они так и останутся никому не нужны.
"Первый вопрос, который нужно себе задать: зачем". Слушай, ты вообще статью читал? Затем, что дизайн должен быть разделен от кода. Полное разделение на интерфейсы и классы-конструкторы, понятно? А ты наоборот предлагаешь добавлять дефолтные методы в интерфейсы ? И не работает то, что у интерфейса не может быть приватных (private) полей, или даже защищенных (protected) если уж на то пошло. Твоя ссылочка на какой-то стаковерфлоу для меня не аргумент. Это не холи вор, это не точка зрения -- это стандарт, писать I перед интерфейсом, почему -- читай выше (1 буква, не надо ничего придумывать, легко найти в древе проекта). Не видишь смысла что-то начинать потому что знаешь что все кто спорит на эту темы должны иметь их pay docked то бишь оштрафованы работодателем, если их босс увидит, что они смеют разглагольствовать на эту темы. Это не мнение, понятно, это стандарт индустрии. Проявите уважение к профессионалам.
Спасибо, что напомнил про Impl, я знал что кроме DefaultX еще делают XImpl, но забыл, что за 4 буквы. Не вижу разницы между делать это (VisitorControllerImpl) или обозначать интерфейс через IVisitorController. Обозначать через интерфейс более выгодно, потому что а) меньше букав, б) можно сразу найти в package explorer.
Методы с реализацией по-умолчанию в интерфейсах не катят. Если ты попробуешь, ты поймешь, почему. Я попробовал. Я понял. Наверное, ты просто не знаешь, что у дефолтных методов в интерфейсах нет чего-то, что есть у настоящих методов.
П.С. фантазии не просто не хватит, ее реально не будет. Ну вот класс у меня, CssNode. Как я должен разделить интерфейс/класс? Мой сотрудник должен сидеть думать над этим вопросом по часу в день? Никто не должен этим заниматься, когда можно просто поставить I.
Минусуйте сколько влезет, но боже мой, как вы надоели со своим тестированием. Создали целую мини-индустрию вокруг стандартного процесса разработки ПО, чтобы наживаться на людях, не имеющих образования, с баннерами вроде "освой карьеру в ИТ! Получай 200к в месяц!", раздаете титулы вроде "QA-профессионалов", как будто это вообще что-то значит. Сходи в институт, получи диплом, вот это будет что-то значит. Я может и далек от реального положения дел, но последний раз я проверял, это программист должен тестировать свой код. Это называется "твоя работа". Более тесные интеграции ему может помочь тестировать дев-оп. Какие учебники, какие 40 модулей, включая о Линуксе ?♀️ Ну если есть предложение наверное есть спрос. Полное вырождение индустрии. Когда раньше один профессионал мог в фотошопе нарисовать компонент, сверстать его, написать код и протестировать, теперь это -- дизайнер, верстальщик, дев, тестировщик.
Что значит с дизайном реализации можно не заморачиваться? Я заморочился и сделал самым простым возможным способом, чтобы доказать работоспособность метода. Ты говоришь, что все, что я написал -- это просто трейты, а я говорю что нет, что трейтами реализован принцип дизайна.
Красота -- это самое объективное понятие в мире. Чем больше развиваешься, тем больше видишь красивые вещи. Говорят что красота субъективна обычно те, кто ничего в этом не понимает.
Ну и что ты дальше написал? "А вот правильно ли вообще в данном месте реализовывать этот функционал?". Давай еще обсудим "а вот правильно ли вообще было идти программистом?" Почему такое отношение к профессионалам, как к полным дегенератам, которые не умеют думать? Что значит "правильно ли вообще реализовывать функционал" -- ну если мне нужна зависимость, то да, конечно правильно.
И я предлагаю вместо того, чтобы 40 классам делать одно и тоже свойство, выделить его и интерфейс, вернее даже специальную категорию интерфейсов, и имя им даже подобрал -- универсалии. Это вообще основной DRY. В чем ваша проблема всех? Зачем начинать упираться, приводить какие-то доводы доведенные до экстрима "перестают думать а нужен ли вообще функционал", минусовать комментарии автора, ничего конструктивного не приводя.
И к тому же, это не просто "добавить аннотацию". @Inject это просто добавить аннотацию. Тут же наоборот у тебя больше контроля к тому, что происходит, когда ты создаешь экземпляры через конструкторы, которым передаешь универсалии, ты уже знаешь, что используешь паттерн.
Хорошо даже если читают, то чем традиционный @Inject лучше? Там ровно тем же образом не будет ничего прописано в коде, никто ничего не сможет прочитать.
есть в общем 4 варианта, когда что-то меняется:
показываем/прячем элемент (возможно, с каким-то эффектом)
добавляем / убираем класс элемента (.Hidden, .Shown)
модифицируем аттрибуты элемента (включая стиль)
Обновляем список, из которого берутся данные для отображения
возьмем простой метод компонент:
Это твой любимый "неимперативный" метод. Только дело в том, что он такой же неимперативный, как и недекларативный. Настоящий декларатив -- это CSS, ты прописал пару правил, они распарсились и показались тебе, при этом ты вообще не знаешь, как. Компоненты вроде реакта -- это не декларативный код. Декларативный код подразумевает, что ты задал какие-то правила, и они магическим образом показываются. В примере выше нет ничего магического: если изменилось свойство и нужно лишь поменять аттрибут "data-a", помимо VDom о котором ты говоришь, будет перевыполнен ВЕСЬ код как самого компонента, включая хуки (вся стена хуков), так и детей, который находятся в списке. Это друг ни разу не декларатив, это просто сотейник со спагетти. Я на 100% за то, что не нужно писать императивный код, потому что веб страницы - это тип систем, которые остаются запущенными, в отличие от вон ноймановских программ, которые получили input и отдали output. Тут нужны стратегии по data-flow, но реакт - это не лучшая стратегия. VDom вообще не нужен. Представь, что метод Render можно проанализировать заранее, и выяснить, что data-a зависит от свойства propA, и поэтому когда propA меняется, мы исполним только ту часть, которая бы была ответственна за это. То есть функция компонента разбивается на 3 рендера:
Каждая из функций делает только свою часть по отрисовке, и реагирует только на определенное свойство, от которого зависит. Это, конечно, возможно только если у нас уже есть стандартный Домовский элемент, которым можно манипулировать. И сделать это очень даже можно, если только перестать думать в "функиональном" стиле, который является тупиком и ничего по-настоящему интересного, как выше, не дает, а уж тем более не является декларативным.
Я лишь описал принцип, концепт дизайна. То, как его позволяет реализовать Джава - это проблема Джавы. Я не знаю, чем он вам недостаточно гибок, любые конкретные пожелания можно обсудить.
спасибо, что подсказал, посмотрю ) вау люди целые книги пишут по этому поводу...
Зачем читать передачу / получение зависимостей? Нужно ли это? В ваших интерфейсах будет описано, какие зависимости они могут иметь. И кто читает библиотеки? 1% мейнтейнеров? Библиотеки не читают а устанавливают. Еще раз повторюсь, видеть как передается определенный параметр может и нужно, зачем видеть передачу зависимостей и что может быть такого ужасного если ее не прочитают, я не знаю.
Интерфейс - понятие дизайна. Трейты - поняти имплементации. Универсалия - это специальный тип интерфейса, имеющий только одно свойство, указывающее на объект зависимости. интерфейсы с дефолтными методами - это способ их реализации. Про публичные методы я и написал в "ограничения". Это не моя проблема - это проблема Java, которая не дает нормально выполнить принцип дизайна ПО, о чем я так же написал. Но всем конечно, пофигу, на такое абстрактное понятие, как дизайн, потому что его никто не понимает, всем нравится писать уродский код.
Нет, я неправильно сказал, не своего "дерева", а только своего уровня в дереве, то есть не лезть в перерисовку детей вообще. То есть не "исполнять нужно будет только этого ребенка" как ты говоришь, а "исполнять нужно будет только этого ребенка и все его дерево". С другой стороны, можно сделать так, что если у ребенка что-то изменилось, он сам перерисует тот кусок, который изменился. vDOM - очень неэффективный способ решения этой проблемы. Места искать не нужно, они должны быть уже известны за счет того, что в идеале мы можем знать, какое свойство влияет на какую отрисовку.
во-первых, не глобальная коммуникация, а локальная, то есть компонент-компонент, а не компонент -> хранилище состояния -> компонент. у моих компонентов уже есть состояния, зачем мне создавать какие-то там хранилища, и через них обмениваться? во-вторых, событейная модель подходит не до конца, потому что она не реактивна, зачем мне подписываться на какие-то там события, если значение переменной в состоянии одного компонента напрямую, по формуле, зависит от значения состояния в другом компоненте? Из вашей логики, мол вот вам стандарт "веб-компонентов", который по сути своей не привносит ровным счетом ничего (что такое "точка сборки"), а чтобы решить реальную, насущую проблему - делайте что хотите. Да я хочу чтобы мне дали единственную правильную архитектуру, иначе зачем вообще тогда делать специальный стандарт компонентов, если потом все равно приходится к нему прикручивать базовую функциональность обмена сообщениями между ними?
Что значит не предназначен? Взаимодействие между компонентами - это фундаментальная проблема пользовательского интерфейса. Есть 3 уровня для веб-разработки: презентация (стили, классы), интеракция с пользователем (нажал кнопку -> что-то произошло) и коммуникация (передать сообщение другому компоненту / получить сообщение от другого компонента), напр, вышел из системы - поле комментариев погасло. Как вы можете говорить, что API веб-компонентов не предназначен для обмена данных между ними? А что тогда предназначено? Вернее, то что вы говорите это на данном этапе правда, и в этом и есть проблема: что внешний вид / интеракции можно спокойно писать и на чистом HTML/JS, а вот реактивную коммуникацию между компонентами никто не потрудился устроить, которая является самой актуальной проблемой. Ну и зачем они тогда нужны без протокола коммуникации?
Ты 100% прав, я же добавлю, что математически чистая функция - это не так уж и приятно. Даже если взять реакт, скажем у компонента 10 детей, а если обновилось только 1 его свойство, которое затрагивает только 1 ребенка, нужно идти в каждого из ребенков и исполнять его как чистую функцию, чтобы смотреть, не нужно ли что перерисовать. Поэтому и говорят, что "реакт на самом деле не реактивен". Чистые функции для отрисовки UI, которые все так боготворят, это на самом чистый фаб, просто хак оттого, что никто не знает, как правильно сделать. не легче ли каждому компоненту иметь свои свойства, и если эти свойства меняются, давать ему перерисовывать только свое дерево, причем реально только в тех местах, где надо?
да кому нужны ваши веб-компоненты, если главная проблема -- не сами компоненты и их стили, а общение между ними, протокол которого напрочь отсутствует как концепт в текущей html 5 модели веб-компонентов. что значит общение? вот есть кнопка, я ее нажал, я хочу, чтобы изменилось состояние другого компонента, например, кол-во кликов. А если кол-во кликов больше 10, то я хочу изменить еще другое свойство еще другого компонента. В первом вопросе поможет событейная модель: onClick -> component.incrementClicks(). Со вторым поможет только фреймворк, и в этом все горе, что в html 5 просто не продумана реактивность, которая свойственна всем persistent системам (то есть тем системам, которые запускаешь и они продолжают работают, а не просто выводят результат). Сколько бы ни пилили сами компоненты, пока не реализуют eventual transconsistency (правильное название реактивности) на уровне протокола, они так и останутся никому не нужны.
"Первый вопрос, который нужно себе задать: зачем". Слушай, ты вообще статью читал? Затем, что дизайн должен быть разделен от кода. Полное разделение на интерфейсы и классы-конструкторы, понятно? А ты наоборот предлагаешь добавлять дефолтные методы в интерфейсы ? И не работает то, что у интерфейса не может быть приватных (private) полей, или даже защищенных (protected) если уж на то пошло. Твоя ссылочка на какой-то стаковерфлоу для меня не аргумент. Это не холи вор, это не точка зрения -- это стандарт, писать I перед интерфейсом, почему -- читай выше (1 буква, не надо ничего придумывать, легко найти в древе проекта). Не видишь смысла что-то начинать потому что знаешь что все кто спорит на эту темы должны иметь их pay docked то бишь оштрафованы работодателем, если их босс увидит, что они смеют разглагольствовать на эту темы. Это не мнение, понятно, это стандарт индустрии. Проявите уважение к профессионалам.
Спасибо, что напомнил про Impl, я знал что кроме DefaultX еще делают XImpl, но забыл, что за 4 буквы. Не вижу разницы между делать это (VisitorControllerImpl) или обозначать интерфейс через IVisitorController. Обозначать через интерфейс более выгодно, потому что а) меньше букав, б) можно сразу найти в package explorer.
Методы с реализацией по-умолчанию в интерфейсах не катят. Если ты попробуешь, ты поймешь, почему. Я попробовал. Я понял. Наверное, ты просто не знаешь, что у дефолтных методов в интерфейсах нет чего-то, что есть у настоящих методов.
П.С. фантазии не просто не хватит, ее реально не будет. Ну вот класс у меня, CssNode. Как я должен разделить интерфейс/класс? Мой сотрудник должен сидеть думать над этим вопросом по часу в день? Никто не должен этим заниматься, когда можно просто поставить I.
like the boss. курсачи так же сдавал. 3 ошибки нашел править пока не буду не хочу редить скажете нельзя редить было )
Имелось ввиду, что сама программа собирается с javac, который AOT прекомпилирует байт-код для JVM ?, но, кажется, подразумевалось JIT ?