Я всячески старался избегать слова проблема, больше старался подчеркивать личная неприязнь, но справдливости ради скажу, что проблемы if VS switch находятся при review кода, как в одну так и в другую стороны.
Отдельно можно сказать про проверку на null. Она нужна в любом случае, т.к. передача null в метод ...
Бесспорно! Но жизнь такова, что многие проверки не делают и в результате получаем, в одном случае крайне неинформативную ошибку NPE, а в другом просто недостаточно информативную (если из примера «Неподдерживаемый канал связи null»)
Не рубите так с плеча, про идеальный сайт. Я вообще думаю, что бизнес во многом сейчас решает быть или не быть js на сайте. Про интернет банкинг, могу сказать, что без js вообще нельзя — есть и логика защиты процеса работы с данными и шифрование и трюки-крюки простите за слег.
Про синглтон:
Что так: простой и паттерн реализации легко запоминается
Что не так:
1) Эстетический пейзаж фауны enum класса в виде синглтона оставляет желать лучшего
2) enum все таки перечисление сущностей одного типа и предназначен для другого нежели сингл тон — как боевая единица бизнес задачи
3) под капотом этого синглтона будут лишние методы values и valueOf, конструктор с лишними аргументами, скрытые поле $values с блоком инициализации, неоправданное наследование от класса Enum, а также по факту он будет фабрикой для получения единственного объекта по имени енума. Кое-что мог упустить или не точно указать так как пишу по памяти
По второму вопросу — это один ИЗ прикладных способом защиты приложения, а не bad-design code как Вы подумали
Простите меня за невежество, не знал я ранее про Lombok, прочитал захлебом пару статей (одна на хабре), но не суть.
Хотелось услышать Ваши экспертные мнения, не халивара ради, a больше для себя, по некоторым аспектам, которые меня беспокоят:
1) Не станет ли 'наша' java другой после внедрения Lombok, не потеряет ли она свое изящество, когда содержательной части станем меньше, чем аннотаций, как пример:
2) Как будет осуществляться поиск использования методов, скажем, toString или getId и что будет с java-doc'ми этих методов в наших любимых IDE?
3) Какие баги нас могут ждать после начала эксплуатации фишек этого проекта?
Я понимаю что отстал по этой теме лет на 6 так, но все же. Заранее спасибо отвечающим.
Хороший перевод, спасибо. С автором статьи согласен.
Но мне показалось, что к первым двум пунктам:
1. Понимает ли пользователь, что от него требуется ввести адрес электронной почты в это поле?
2. Правильно ли он ввёл свой адрес в поле?
Обязательно нужно добавить 3 — А насколько Вашему сервису важно знать валидный адрес пользователя?
И мыслей здесь несколько:
1. Со времен появления сотовых телефонов значимость почты в разрезе возможности идентификации пользователя и обратной связи с ним резко упала.
2. Что важней, что пользователь получит возможность приносить Вам прибыль, пользуясь Вашим сервисом (например ввиде покупки товаров и т.п.) или обязательная доставка рекламы на его почтовый адрес?
Но справедливость ради скажу, что участвовал в проекте где были четкие бизнес требования на проверку введенного пользователем адреса (не массовый продукт) и связано это было с внутренним регламентом компании-закаpчика (ограничение по допустимым доменам и именам до собаки)
Так что всякое бывает.
Это вы мне хорошенько помордам надавали, за идеи то :) Но если серьезно, я с Вами согласен, но позвольте немного оправданий и историй:
Про потокобезопасность Singleton — так в том-то и суть, чтобы java забрала у нас шедевры человеческого разума по их реализации и сделала безопасными, я такие видел, как вспомню аж муражки по коже, да и сам черные дела творил, что греха таить. Вот один из них
// Прости гениев и помилуй
public enum MySingleton {
MY_SINGLETON;
private MySingleton() {
init();
}
private void init() {/**..some_init_work...*/}
public Result doSomeWork(/**args*/){/**..some_work...*/}
}
//где-то в коде, статик импорт
MY_SINGLETON.doSomeWork(/**params*/);
— мопед не мой.
Насчет протестировать, я наверное Ваш контекс не уловил,
По поводу JSP 299 и реализации (weld, как пример), есть маленький проектик на 40-50 классов и 2 синглтона, уж очень не хочется тащить в проект слона или из жизни, главный архитектор запретил напрочь в ядро системы (оформлено обычным модулем с java классами) использовать какие-либо зависимости (даже apache) — только jdk и синглтончик там имеется.
По поводу декапсуляции все таки рефлексия != оператор декапсуляции. Пример из жизни (про безопасность), делали мы проект для 3их лиц, код представляет ценность и его эксплуатация тоже, Один из классов имеет 3 поля, важных, наружу не торчат нужно было проверять время от времени их состояние и согласованность, дошло время до защиты исходников — тут все просто, накрыли jar proguard'ом, нужна была защита от reverse engineering, дела здесь посложнее, но выкрутились — критичное накрыли stringer'ом (не сочтите за рекламу). И дальше — самое интересное, что достучаться просто до поля по его имени (после всего что было :) — та еще задачка (глаза вверх — момент тогда я познал дзен)
Много лет назад я думал, чтобы я добавил в Java, если бы…
Аннтоцию @Singleton — метод getInstance() и ссылка на объект генерятся автоматически
Аннтоцию @Sealed — метод sealed() генерится автоматически и после его вызова все поля класса становятся final Элвис оператор — взгляд со стороны: вместо 'употребления' его с вызывающей стороны перенести в тип, как пример, public SomeData? getSomeData(String? type), думаю идея понятна
Оператор декапсуляции — опасный, но иногда очень нужный — осуществляет доступ к приватным полям (например для тестов), пример, someInstance#privateFieldName
Некоторые фантазии свои вспомнить не могу, дело давно было…
function fetchUntilAvailable(url) {
while (true) {
let result = await fetch(url);
if (isGood(result))
return result;
await delay(timeOut);
}
}
//А насчет промисов тоже решение имеется:
function fetchUntilAvailable(url) {
return fetch(url).then(function(result) {
return isGood(result) && result
|| delay(timeOut).then(() => fetchUntilAvailable(uri)));
});
}
//при условии, что delay возвращает Promise
Хотя Ваш вариант (await) мне нравится куда больше.
Спасибо за статью, словно побывал на той стороне процесса.
Но вопрос один имеется: «ТЗ высокой четкости» для кого?
Я разработчик и бывало такое когда ТЗ утвердило руководство, акцептовал начальник отдела аналитики собрали все подписи с клиента, а потом удаленький разработчик задает маленький вопрос и все летит в там-тарары.
Вот еще несколько выводов, опять же с допущениями:
Часто встречаемая ошибка — IOException
Java классы довольно хорошо докумнтированны
Литералов true и false примерно одинаково (12,989,940/12,745,131)
Java пронизана языками и технологиями:
— SQL / JDBC
— XML / JSON
— Regexp
— JUnit /
Не плохо покрыта тестами
Хорошо бы еще добавить информацию о среднем кол-ве вхождений слова в 1 файле, например, return — 68,848,062 + в среднем 10 раз в 1 файле и общее кол-во проанализированных файлов одного типа.
Самый популярный тип — java.lang.String;
Самый популярный примитивный тип int;
Самая популярная конструкция — if, куда же без них;
Значимое количество методов не возвращающих ничего void,
Самое распрастраненное наименование переменной i — циклы рулят;
Самое распрастраненное слово в java-doc the
В java больше открытого public чем закрытого(private) и наследуемого(protected)
Я всячески старался избегать слова проблема, больше старался подчеркивать личная неприязнь, но справдливости ради скажу, что проблемы if VS switch находятся при review кода, как в одну так и в другую стороны.
Бесспорно! Но жизнь такова, что многие проверки не делают и в результате получаем, в одном случае крайне неинформативную ошибку NPE, а в другом просто недостаточно информативную (если из примера «Неподдерживаемый канал связи null»)
Согласен, но тоже верно и про switch-case?
Косвенно Вы поднимаете более глубокую тему сравнения языков и их возможностей.
Не рубите так с плеча, про идеальный сайт. Я вообще думаю, что бизнес во многом сейчас решает быть или не быть js на сайте. Про интернет банкинг, могу сказать, что без js вообще нельзя — есть и логика защиты процеса работы с данными и шифрование и трюки-крюки простите за слег.
Про синглтон:
Что так: простой и паттерн реализации легко запоминается
Что не так:
1) Эстетический пейзаж фауны enum класса в виде синглтона оставляет желать лучшего
2) enum все таки перечисление сущностей одного типа и предназначен для другого нежели сингл тон — как боевая единица бизнес задачи
3) под капотом этого синглтона будут лишние методы values и valueOf, конструктор с лишними аргументами, скрытые поле $values с блоком инициализации, неоправданное наследование от класса Enum, а также по факту он будет фабрикой для получения единственного объекта по имени енума. Кое-что мог упустить или не точно указать так как пишу по памяти
По второму вопросу — это один ИЗ прикладных способом защиты приложения, а не bad-design code как Вы подумали
Хотелось услышать Ваши экспертные мнения, не халивара ради, a больше для себя, по некоторым аспектам, которые меня беспокоят:
1) Не станет ли 'наша' java другой после внедрения Lombok, не потеряет ли она свое изящество, когда содержательной части станем меньше, чем аннотаций, как пример:
2) Как будет осуществляться поиск использования методов, скажем, toString или getId и что будет с java-doc'ми этих методов в наших любимых IDE?
3) Какие баги нас могут ждать после начала эксплуатации фишек этого проекта?
Я понимаю что отстал по этой теме лет на 6 так, но все же. Заранее спасибо отвечающим.
Но мне показалось, что к первым двум пунктам:
1. Понимает ли пользователь, что от него требуется ввести адрес электронной почты в это поле?
2. Правильно ли он ввёл свой адрес в поле?
Обязательно нужно добавить 3 — А насколько Вашему сервису важно знать валидный адрес пользователя?
И мыслей здесь несколько:
1. Со времен появления сотовых телефонов значимость почты в разрезе возможности идентификации пользователя и обратной связи с ним резко упала.
2. Что важней, что пользователь получит возможность приносить Вам прибыль, пользуясь Вашим сервисом (например ввиде покупки товаров и т.п.) или обязательная доставка рекламы на его почтовый адрес?
Но справедливость ради скажу, что участвовал в проекте где были четкие бизнес требования на проверку введенного пользователем адреса (не массовый продукт) и связано это было с внутренним регламентом компании-закаpчика (ограничение по допустимым доменам и именам до собаки)
Так что всякое бывает.
Про потокобезопасность Singleton — так в том-то и суть, чтобы java забрала у нас шедевры человеческого разума по их реализации и сделала безопасными, я такие видел, как вспомню аж муражки по коже, да и сам черные дела творил, что греха таить. Вот один из них — мопед не мой.
Насчет протестировать, я наверное Ваш контекс не уловил,
По поводу JSP 299 и реализации (weld, как пример), есть маленький проектик на 40-50 классов и 2 синглтона, уж очень не хочется тащить в проект слона или из жизни, главный архитектор запретил напрочь в ядро системы (оформлено обычным модулем с java классами) использовать какие-либо зависимости (даже apache) — только jdk и синглтончик там имеется.
По поводу декапсуляции все таки рефлексия != оператор декапсуляции. Пример из жизни (про безопасность), делали мы проект для 3их лиц, код представляет ценность и его эксплуатация тоже, Один из классов имеет 3 поля, важных, наружу не торчат нужно было проверять время от времени их состояние и согласованность, дошло время до защиты исходников — тут все просто, накрыли jar proguard'ом, нужна была защита от reverse engineering, дела здесь посложнее, но выкрутились — критичное накрыли stringer'ом (не сочтите за рекламу). И дальше — самое интересное, что достучаться просто до поля по его имени (после всего что было :) — та еще задачка (глаза вверх — момент тогда я познал дзен)
Аннтоцию @Singleton — метод getInstance() и ссылка на объект генерятся автоматически
Аннтоцию @Sealed — метод sealed() генерится автоматически и после его вызова все поля класса становятся final
Элвис оператор — взгляд со стороны: вместо 'употребления' его с вызывающей стороны перенести в тип, как пример, public SomeData? getSomeData(String? type), думаю идея понятна
Оператор декапсуляции — опасный, но иногда очень нужный — осуществляет доступ к приватным полям (например для тестов), пример, someInstance#privateFieldName
Некоторые фантазии свои вспомнить не могу, дело давно было…
Хотя Ваш вариант (await) мне нравится куда больше.
Но вопрос один имеется: «ТЗ высокой четкости» для кого?
Я разработчик и бывало такое когда ТЗ утвердило руководство, акцептовал начальник отдела аналитики собрали все подписи с клиента, а потом удаленький разработчик задает маленький вопрос и все летит в там-тарары.
Вот еще несколько выводов, опять же с допущениями:
Часто встречаемая ошибка — IOException
Java классы довольно хорошо докумнтированны
Литералов true и false примерно одинаково (12,989,940/12,745,131)
Java пронизана языками и технологиями:
— SQL / JDBC
— XML / JSON
— Regexp
— JUnit /
Не плохо покрыта тестами
Самый популярный тип — java.lang.String;
Самый популярный примитивный тип int;
Самая популярная конструкция — if, куда же без них;
Значимое количество методов не возвращающих ничего void,
Самое распрастраненное наименование переменной i — циклы рулят;
Самое распрастраненное слово в java-doc the
В java больше открытого public чем закрытого(private) и наследуемого(protected)
Конечно есть нюансы, но куда без них :)
За статью спасибо.