Зависит. Можно подкрадываться и съедать конкурентов делением. Можно кидать приманки, можно растить зеленые растения, чтобы они делились и разрывали бОльшего конкурента на части…
Шахматы прям :)
Реально страшно за что?
Ну да, бывают баги в любом коде, в любых либах. Мы ж на этом не самолеты запускаем с реакторами, а лишь в интернете чатики, да картинки показываем.
Может.
Я же больше склоняюсь, что идея сама по себе не нужна публике.
Мы нынче очень перегружены различными публичными сервисами.
Поэтому не все новые идеи встречают отклик в избалованных сердцах и перегруженных мозгах людей :)
Убежден, что причина именно такого кода — педантичность автора.
Не навязываю, но как совет: будет лучше, если всю эту «ненужную» мишуру спрятать как-то в недра. Ведь чем меньше видишь кода, тем проще его понимать. А спрятать всегда можно — было бы желание :)
Попытаюсь сказать по-другому:
«проблема с cohesion» — это обычно не такая критичная проблема, чтобы решать ее на каждом проекте. Да, вас может раздражать что один класс содержит 2 тысячи строк кода и лучше бы этот код разбить на отдельные классы.
Но проекты с такими God Сlass-ами вполне нормально живут, для них пишутся такие же юнит-тесты как и для меньших классов.
Потому что мы все равно разнесли логику на слои. Контроллеры получают запросы, DAO общаются с БД, а God Сlass-ы бизнес-логики содержат все сценарии работы, которые нужны от системы.
Я не говорю что God Сlass-ы — это хорошо. Я говорю, что они терпимы и с ними можно жить.
Про юнит-тесты не соглашусь. Если мы раскидываем код из God Сlass-а в кучу разных других классов — то мы наводим некий порядок, но не уменьшаем сложность всей системы.
Юнит тесты для класса с 30 методами — это условно 30 разных тестов для каждого отдельного метода.
Юниты тест для разделенных 6 разных классов с 5 методами в каждом — это те же 30 тестов.
Т.о. как у вас было 30 тестов, так и придется поддерживать те же 30 тестов.
Однако, опыт показывает, что в 90% случаев проще использовать простой подход: один-два-много God Сlass-ов с кучей публичных методов в каждом из них.
Да будет немного муторно, когда методов 20-30.
Но это нормальная цена за простоту — любой джуниор сразу понимает, как это работает.:)
Я не призываю использовать только такой подход, нет!
Мысль моя в том, что обычно этого достаточно. А когда проект станет большим, то тогда отдельные участки проекта можно поменять на что-то другое.
Предложу еще одно решение поставленной в задаче проблемы:
Итак у нас есть сервис, в котором куча «методов-скриптов».
Если количество этих методов уже неудобно, то можно выносить их в отдельные классы-команды.
Пример
class CreateApplication extends BaseCommand<Application, Result>{
public Application app;
public InvocationContext context;
public CreateApplication(Application app){
this.app = app;
}
public Result invoke(){
//здесь делаем логику создания в возвращаем результат
//используем context
}
}
Тогда у сервиса будет универсальный метод invoke:
public <T> invoke(BaseCommand<?, T> command){
command.context = ...; //проставляем контекст выполнения
return command.invoke();
}
Как видите, здесь мы создаем команду где-то извне, передаем ее сервису, сервис проставляет свой контекст исполнения (например контекст может содержать классы DAO) и дальше вызывает команду на исполнение.
У такого подхода есть свои плюсы, минусы и вариации.
Но в целом он тоже применим.
Довольно понятный код и учитываются все аспекты данного вопроса:
— ограничение сверху на макс.количество соединений
— обработка ошибок соединения
— обновление пула соединений новыми, при обрыве старых
Я даже брал когда-то этот код для реализации пула сокетов.
Первый раз потому, что проделали такую большую работу и довели ее до логического конца (релиза). А второй раз — Вы написали большую статью на Хабр и не повелись на типичные провокации в духе «да нафига это нужно?».
Будьте уверены — это нужно. Не согласны обычно те, кто сам ничего такого не создает ;)
Спасибо.
Я хотел показать данной статьей, что не нужно ограничивать себя рамками больших типовых решений.
Для небольших веб-проектов может оказаться приятней и быстрей написать что-то своё.
Формально вы конечно правы!
Но на практике это скорее простой и удобный стандарт Java веб-приложений. Например Томкат нельзя считать полноценным JEE-сервером — всё что в нем есть — это как раз-таки одни сервлеты :)
Шахматы прям :)
Ну да, бывают баги в любом коде, в любых либах. Мы ж на этом не самолеты запускаем с реакторами, а лишь в интернете чатики, да картинки показываем.
Там даже на странице проекта уже есть кнопка «Export to GitHub»
Я же больше склоняюсь, что идея сама по себе не нужна публике.
Мы нынче очень перегружены различными публичными сервисами.
Поэтому не все новые идеи встречают отклик в избалованных сердцах и перегруженных мозгах людей :)
Год назад сам запустил такую штуку: http://freecom.me/
У меня не взлетело, но вам искренне желаю удачи!
Примеры:
Убежден, что причина именно такого кода — педантичность автора.
Не навязываю, но как совет: будет лучше, если всю эту «ненужную» мишуру спрятать как-то в недра. Ведь чем меньше видишь кода, тем проще его понимать. А спрятать всегда можно — было бы желание :)
«проблема с cohesion» — это обычно не такая критичная проблема, чтобы решать ее на каждом проекте. Да, вас может раздражать что один класс содержит 2 тысячи строк кода и лучше бы этот код разбить на отдельные классы.
Но проекты с такими God Сlass-ами вполне нормально живут, для них пишутся такие же юнит-тесты как и для меньших классов.
Потому что мы все равно разнесли логику на слои. Контроллеры получают запросы, DAO общаются с БД, а God Сlass-ы бизнес-логики содержат все сценарии работы, которые нужны от системы.
Я не говорю что God Сlass-ы — это хорошо. Я говорю, что они терпимы и с ними можно жить.
Юнит тесты для класса с 30 методами — это условно 30 разных тестов для каждого отдельного метода.
Юниты тест для разделенных 6 разных классов с 5 методами в каждом — это те же 30 тестов.
Т.о. как у вас было 30 тестов, так и придется поддерживать те же 30 тестов.
Да будет немного муторно, когда методов 20-30.
Но это нормальная цена за простоту — любой джуниор сразу понимает, как это работает.:)
Я не призываю использовать только такой подход, нет!
Мысль моя в том, что обычно этого достаточно. А когда проект станет большим, то тогда отдельные участки проекта можно поменять на что-то другое.
Итак у нас есть сервис, в котором куча «методов-скриптов».
Если количество этих методов уже неудобно, то можно выносить их в отдельные классы-команды.
Пример
Тогда у сервиса будет универсальный метод invoke:
Как видите, здесь мы создаем команду где-то извне, передаем ее сервису, сервис проставляет свой контекст исполнения (например контекст может содержать классы DAO) и дальше вызывает команду на исполнение.
У такого подхода есть свои плюсы, минусы и вариации.
Но в целом он тоже применим.
Как пример реализации такого подхода, я даже когда-то написал свою библиотеку для Java.
Если нужна оптимистическая блокировка в ситуации INSERT-а строки вместо UPDATE существующей, то можно использовать внешнюю таблицу для лока:
«Добавить новую строку баланса, проставив новую ревизию в глобальную таблицу ревизий, если ожидаемая старая ревизия такая-то»
Надеюсь идея понятна.
UPDATE users SET balance = ${newValue} WHERE balance=${expectedOldValue};Данный запрос вернет 0, если ожидаемый баланс не совпадет с текущим — т.е. кто-то нас опередил и наши данные о балансе больше не актуальны.
Довольно понятный код и учитываются все аспекты данного вопроса:
— ограничение сверху на макс.количество соединений
— обработка ошибок соединения
— обновление пула соединений новыми, при обрыве старых
Я даже брал когда-то этот код для реализации пула сокетов.
Первый раз потому, что проделали такую большую работу и довели ее до логического конца (релиза). А второй раз — Вы написали большую статью на Хабр и не повелись на типичные провокации в духе «да нафига это нужно?».
Будьте уверены — это нужно. Не согласны обычно те, кто сам ничего такого не создает ;)
Спасибо.
Для небольших веб-проектов может оказаться приятней и быстрей написать что-то своё.
Плюс всегда приятно опуститься на уровень «пониже», чтобы самому познать то, что скрыто от вас в Больших Фреймворках.
Но на практике это скорее простой и удобный стандарт Java веб-приложений. Например Томкат нельзя считать полноценным JEE-сервером — всё что в нем есть — это как раз-таки одни сервлеты :)
А я с товарищем 5 лет назад делал что-то похожее в университете.
Приятно, что мы двигались в том же направлении, что и авторы из Фейсбука.