Понравился малый размер классов. Некоторые вещи режут глаз.
Однако же мне это сильно напоминает мир Scala (не код, но, скажем, отличие от традиционного мира Java).
Свидетели Scala тоже говорят, что у них золотая таблетка, правильное ФП и вообще рай. Однако там точно такие же проблемы: высокий порог вхождения, сложность с поиском людей, сложность с чтением кода.
Тогда появится какой-то новый Егор, который будет ездить по конференциям и рассказывать, что «чистый ООП» — это ужасно, что все проекты плохие и что надо писать в процедурном стиле.
А почему книга должна обладать поведением «сохраниться в базу»? Single responsibility principle хоть Егор не отменил еще своим божественным указанием? :)
Мне не нравится ни тот код, который я писал, ни та Java, которую я видел, ни библиотеки, с которыми я сталкивался, мне неприятно с ними работать. Не только мне, а людям, которые вокруг меня, программистам. Я вижу, какой код они пишут, как тяжело этот код потом понимать, поддерживать, как вообще неприятно программировать.
Но не ясно — нравится ли ему тот код, который он пишет «правильно»? Дальше он упоминает, что концепция in progress, что код, ушедший в продакшн, уже не такой «правильный». То есть я не вижу каких-то радикальных плюсов по сравнению с другими концепциями.
Каков вообще средний возраст его проектов? Если они пишут под заказ, то, я предполагаю, нет долгоживущих проектов. Тогда да, можно нагородить «ООП от Егора» и забыть, а в следующей проекте уже будет «ООП 2.0 от Егора», и так далее.
Есть ли у него код, которому, скажем, 5, 10 лет, и он ему все еще нравится? Есть ли реально большие и долгоживущие проекты, в котором «правильное ООП» показало себя на практике? Ну чтобы все было покрыто тестами, чтобы можно было спокойно менять устаревшие куски, чтобы глаза не болели? Как по мне, это недостижимый идеал.
Интересная идея, спасибо!
У меня в будущем стоит похожая задача: показывать, почему именно @PreAuthorize не сработал, какая часть выражения не пропустила.
Управление «кучками» реализовано на супербыстрых и экономичных по памяти LinkedHashSet, нам не важно значение, важно лишь в какой «кучке» какой ключ находится в данный момент. Это ключ к быстродействию.
Хотелось бы подробностей, почему именно LinkedHashSet, а не обычный HashSet.
LinkedHashSet используется тогда, когда важен порядок добавления, а вы пишете, что «важно лишь в какой «кучке» какой ключ находится в данный момент».
Но Facebook идёт на шаг впереди. Они не только разрабатывают отдельные приложения для конкретных задач, они предоставляют несколько конкурирующих приложений, предоставляющих схожую функциональность, и эти приложения не обязательно имеют общий бекенд.
Не могу сказать, что это так уж хорошо. ФБ-приложение было замечено в пожирании батареи, а тут целых два.
Вдобавок у Messenger не отключаются уведомления, только через системный запрет.
После «улучшения» я просто снес оба приложения :)
Официальное приложение имеет те же проблемы плюс новые: нельзя голосовать за карму, нельзя выделять текст (то есть нельзя скопировать ссылку, к примеру, если парсер ее не подсветил), постоянно просить заново вводить пароль. Одно неосторожное движение и огромный набранный комментарий куда-то исчезает. Не обновляются комментарии.
Мне интересно, почему нельзя голосовать за статьи недельной (??) давности? Читаю через RSS, часто с задержкой в неделю-две, но плюсовать уже нельзя. Серьёзно?
И соглашусь со многими, стало не очень интересно писать, когда знаешь, что получишь 2,5 комментария. Я больше фидбэка получу в своем мертвом гугл+.
UPD Для улучшения читаемости я всегда в пул реквестах рекомендую дробить методы на более мелкие, а во многих случаях дробить нужно классы.
Однако же мне это сильно напоминает мир Scala (не код, но, скажем, отличие от традиционного мира Java).
Свидетели Scala тоже говорят, что у них золотая таблетка, правильное ФП и вообще рай. Однако там точно такие же проблемы: высокий порог вхождения, сложность с поиском людей, сложность с чтением кода.
И получается, Request это лишь контейнер для данных. Почему он наружу свои данные выставляет? Это же нарушение инкапсуляции! :)
Вместо того, чтобы писать request.respond(outputStream), тут введен некий конвертер :)
Граница инкапсуляции есть всегда. И DTO есть в реальном мире (например, всяческие анкеты, фотографии, записи).
Тогда появится какой-то новый Егор, который будет ездить по конференциям и рассказывать, что «чистый ООП» — это ужасно, что все проекты плохие и что надо писать в процедурном стиле.
А так хорошо:
Особой разницы нет. Разница лишь в том, кто выполняет действие. Либо база сохраняет книгу, либо книга сохраняется в базу.
Конечно, если бы это был реальный мир, то книгу на полку ставил бы человек. Или робот :)
Тогда следует писать
Что логически приводит к ORM системам :)
Но не ясно — нравится ли ему тот код, который он пишет «правильно»? Дальше он упоминает, что концепция in progress, что код, ушедший в продакшн, уже не такой «правильный». То есть я не вижу каких-то радикальных плюсов по сравнению с другими концепциями.
Каков вообще средний возраст его проектов? Если они пишут под заказ, то, я предполагаю, нет долгоживущих проектов. Тогда да, можно нагородить «ООП от Егора» и забыть, а в следующей проекте уже будет «ООП 2.0 от Егора», и так далее.
Есть ли у него код, которому, скажем, 5, 10 лет, и он ему все еще нравится? Есть ли реально большие и долгоживущие проекты, в котором «правильное ООП» показало себя на практике? Ну чтобы все было покрыто тестами, чтобы можно было спокойно менять устаревшие куски, чтобы глаза не болели? Как по мне, это недостижимый идеал.
У меня в будущем стоит похожая задача: показывать, почему именно @PreAuthorize не сработал, какая часть выражения не пропустила.
А зачем вы делаете прокси? (newProxyInstance)
Хотелось бы подробностей, почему именно LinkedHashSet, а не обычный HashSet.
LinkedHashSet используется тогда, когда важен порядок добавления, а вы пишете, что «важно лишь в какой «кучке» какой ключ находится в данный момент».
Однако почему-то в килобайтах, а не в байтах. Так что сравнение и правда некорректное :)
Не могу сказать, что это так уж хорошо. ФБ-приложение было замечено в пожирании батареи, а тут целых два.
Вдобавок у Messenger не отключаются уведомления, только через системный запрет.
После «улучшения» я просто снес оба приложения :)
Warnings (0)
Окей…
А оно не умеет аггрегировать отчеты от подмодулей в Maven? Не очень удобно смотреть в каждом модуле, если модулей много.
И соглашусь со многими, стало не очень интересно писать, когда знаешь, что получишь 2,5 комментария. Я больше фидбэка получу в своем мертвом гугл+.