у тебя дверь состоит из петель и доски

плевались все

вот тебе классы внешние, и те которые внутри но с которыми никто непосредственно не работает

кроме самой двери

говорю из реального опыта работы с проектом, написанным таким образом

Блин, у тебя все действия состоят из маленьких действий. Реализуешь каждое из этих действий на своём уровне. Кода много, но всё понятно, так как за каждую част отвечает буквально 10-20 строчек.

Придумай пример, я тебе покажу как бы я его реализовал.

Блин, у тебя все действия состоят из маленьких действий. Реализуешь каждое из этих действий на своём уровне. Кода много, но всё понятно, так как за каждую част отвечает буквально 10-20 строчек.

если мне понадобятся действия из этого класса в другом месте?

где еще можно юзать дверные петли?

если мне понадобятся действия из этого класса в другом месте?

Проблем никаких. У тебя иерархические зависимости. Из-за чего всё ок.

Ладно дверь, а если лопата?

Нужны петли в двери, используй их в холодильнике.

черенок вполне себе отдельный класс

Привет. Вопрос касательно безопасности. Как лучше организовать вход в приложение с использованием смс аутентификации. 1. На сервере генерируется проверочный код и записывается в БД. Код шлется пользователю, затем пользователь снова шлет запрос на сервер с этим кодом, на сервере проверяется и возвращается ответ. 2. Код генерируется на самом устройстве и отправляется на сервер для отправки смс пользователю. Код приходит и проверяется на самом устройстве на соответствие. 3. Более умный вариант?

Методы одни и те же и несут один и тот же смысл.

Привет. Вопрос касательно безопасности. Как лучше организовать вход в приложение с использованием смс аутентификации. 1. На сервере генерируется проверочный код и записывается в БД. Код шлется пользователю, затем пользователь снова шлет запрос на сервер с этим кодом, на сервере проверяется и возвращается ответ. 2. Код генерируется на самом устройстве и отправляется на сервер для отправки смс пользователю. Код приходит и проверяется на самом устройстве на соответствие. 3. Более умный вариант?

на серваке генерь

Привет. Вопрос касательно безопасности. Как лучше организовать вход в приложение с использованием смс аутентификации. 1. На сервере генерируется проверочный код и записывается в БД. Код шлется пользователю, затем пользователь снова шлет запрос на сервер с этим кодом, на сервере проверяется и возвращается ответ. 2. Код генерируется на самом устройстве и отправляется на сервер для отправки смс пользователю. Код приходит и проверяется на самом устройстве на соответствие. 3. Более умный вариант?

Первое.

Методы одни и те же и несут один и тот же смысл.

ну т.е. мне тащить весь класс ради пары методов

такое себе

ну т.е. мне тащить весь класс ради пары методов

Эм, выдели подкласс. В чём проблема?

Эм, выдели подкласс. В чём проблема?

нахрена подкласс, если можно отдельный компонент, который производит действия?

зачем лепить эту лапшу из матрешек на пару тысяч строк

в серьезном проекте именно так и будет

зачем лепить эту лапшу из матрешек на пару тысяч строк

Зачем лепить эту матрёшку? Я тоже против этого. Используй DI, но у тебя должна быть строгая иерархия.

Зачем лепить эту матрёшку? Я тоже против этого. Используй DI, но у тебя должна быть строгая иерархия.

DI окей. что ты имеешь в виду под иерархией?

сейчас наоборот самый популярный способ проектирования декомпозировать классы так, чтобы каждый определенную функцию выполнял, есть модель, есть класс, который достаёт данные и маппит их на эту модель, есть класс который производит бизнес-логику над этим классом и т.д.

Одно другому не противоречит Btw хайп это слабый аргумент

Подклассы нужны чуть чаще, чем никогда

Агрегация

Подклассы нужны чуть чаще, чем никогда

вижу их в основном в алгоритмах и либах

а так редко

Ну и да, я открыт для переубеждения

Ща, сформулирую.

вижу их в основном в алгоритмах и либах

Еще когда наговнодизайнил, потом выкручиваешься

Во, у тебя не должно быть возможности влиять на чужой объект извне класса.

почему?

с чего такое мнение

Потому что это путает логику. Ещё спроси почему goto плох.

в смысле?

что путает?

Если ты извне можешь менять обёект, то ты позволяешь этот объект сломать.

А чем меньше свободы, тем лучше.

Нельзя менять непосредственно внутренний стейт, Андрей имеет в виду. Только через api

Пошёл учится объяснять свои мысли.

Sysyarp sysyarp = new Sysyarp(); sysyarp.setRating(-100000); sysyarpRepo.attach(sysyarp);

И сет гет это не api, это прямой инжект в поля

Sysyarp sysyarp = new Sysyarp(); sysyarp.setRating(-100000); sysyarpRepo.attach(sysyarp);

Это говно.

вот мой пример - это нельзя, да, Андрей?

вот мой пример - это нельзя, да, Андрей?

Да, сделай конструктор

вот мой пример - это нельзя, да, Андрей?

Сделать ты это можешь, но какашка получается.

почему?

конкретно

примеры и проблемы

Да, сделай конструктор

Кстати, насчёт геттеров я против не имею, но сеттеры - зло.

В рантайме кто-то сетает в бегущий объект и * радуга*

примеры и проблемы

Ты уверен, что объект не сломается, если ты засетишь туда определённое значение?

в смысле кто-то? ты сам определяешь логику

в смысле кто-то? ты сам определяешь логику

Ты не пользуешься чужими библиотеками?

Ты как дядя боб

Ты уверен, что объект не сломается, если ты засетишь туда определённое значение?

что за долбаебизм, конечно уверен

Ты доверяешь коду, который писал 3-4 года назад?

причем тут чужие библиотеки, вы наслушались Егора или еще кого, а мысли свои выразить не можете

ни 1 аргумента по делу

пиздец

в смысле кто-то? ты сам определяешь логику

Так мы дойдем до того, что налл сэйфети как в котлине и расте не нужны

ERROR: S client not available

это лишь инструмент

Причем тут Егор вообще

Sysyarp sysyarp = new Sysyarp(); sysyarp.setRating(-100000); sysyarpRepo.attach(sysyarp);

еще раз, вот пример

еще раз, вот пример

Отлично. Ты уверен, что у тебя ограничения по рейтингу нет?

Или в доку за этим лезть надо?

Ну страдай, не делай поля final, не пользуйся concurrency аннотациями, стреляй себе в ногу -- мне не жалко

И что такое рейтинг?

Отлично. Ты уверен, что у тебя ограничения по рейтингу нет?

если бы они были, я бы это описал в слое сервиса - очевидно

Ну страдай, не делай поля final, не пользуйся concurrency аннотациями, стреляй себе в ногу -- мне не жалко

final пользую

Егора я кстати не поддерживаю, ооп говно ящитаю. Пишу на смеси императива, ооп и функциональщины

ладно, чтобы водичку не разводить, переделайте мой пример кода, как вы считаете

и разойдемся

В конструктор

ладно, чтобы водичку не разводить, переделайте мой пример кода, как вы считаете

Sysyarp sysyarp = new Sysyarp(); sysyarpRepo.attach(sysyarp, -1000000);

No silver bullet, максимум, что мы можем, это следовать best practices, набранных из опыта

Sysyarp sysyarp = new Sysyarp(); sysyarpRepo.attach(sysyarp, -1000000);

вот это пиздец

+

с конструктором согласен

но то, что показали, блеванул

а если у тебя 10 полей модель?

а если вложенная модель?

Нахер ты смешал в одном методе независимые вещи?

и после этого мне Андрей будет про жизненный опыт затирать, круто че

Теперь еще и непонятно, что за аргумент, число какое-то

Sysyarp sysyarp = new Sysyarp(); sysyarpRepo.attach(sysyarp, -1000000);

Нихя, это ж не репо, а менеджер получается.

мне такого опыта не надо, спасибо

Ладно, может, он поторопился просто

И на каждый чих городить менеджера, дичь какая-то

и да, в паттерне репо, ты работаешь подобно с коллекцией элементов, у тебя там простые атомарные операции, собираешь объект, передаешь, происходит аттач к контексту/флаш, возвращается объект

и да, в паттерне репо, ты работаешь подобно с коллекцией элементов, у тебя там простые атомарные операции, собираешь объект, передаешь, происходит аттач к контексту/флаш, возвращается объект

Вот честно, я не знаю названий паттернов, кроме самых простых. Я предположил, что там хранятся по какому-то признаку элементы. Вот я и храню по рейтингу. Когда мы забираем объект, то, мы возвращаем другую структуру, где этот рейтинг указывается.