@oop_ru
Sergei02.05.2017
20:47:26
20:47:26
"В итоге уменьшил зависимости до 4, но создал 2 доп класса, которые не имею смысла в отрыве от основного."
Google
Артур Евгеньевич02.05.2017
20:49:49
20:49:49
алгоритм такой был
- проверяем нет ли блокировки
- если нет то ставим
-созраняем в базу часть инфы
-сохраняем фалы аттачмента
-сохраняем в базу ссылки на аттачмент
-снимаем блокировку
это упрощенно конечно, там чуть больше действий и они в одном методе были почти все
F01134H
AlehSergei02.05.2017
20:51:56
20:51:56
не флудить
Sergey02.05.2017
20:53:00
20:53:00
Помогите разобратсья в ситуцации. Был класс сохряняющий емайлы, и там было 7 зависимостей инжектом(логгер, файлсистем, энтитиманагер и т.д короче в основном все служебные) я добавил 8(токенайзер). Ну естественно я решил что 8 зависимостей это перебор, и решил слегка разбить класс. В итоге вынес отдельно все дела для работы с файловой системой, и убрал логирование из основного класса, добавив обертку с помощью деокрирования. В итоге уменьшил зависимости до 4, но создал 2 доп класса, которые не имею смысла в отрыве от основного. То есть по факту я не уменьшил число зависимостей, а просто пробросил их на уровень выше. На ревью мне скзаали, что раз сделал можно и оставить, но смысла большого в этой моей работе нет. Так вот сосбтсвенно вопрос, как определить, что класс обладает слишком большим числом зависиомостей, и рефакторинг действительно необходим??
> То есть по факту я не уменьшил число зависимостей
на самом деле ты уменьшил количество зависимостей.декоратору нужена другая реализация, если ты логирование туда вынес то как бы у тебя нет никаких проблем с зависимостями
более того, возможно все эти штуки у тебя будут принадлежать чуть разным модулям
Артур Евгеньевич02.05.2017
20:54:11
20:54:11
ну там один бандл был
GoogleSergey02.05.2017
20:54:41
20:54:41
ну и как бы не вопрос, внутри бандла могут быть еще модули
тебя никто ни в чем не ограничивает
Артур Евгеньевич02.05.2017
20:55:02
20:55:02
а что под модулем понимается в данном контектсе?
Sergei02.05.2017
20:55:20
20:55:20
Sergey02.05.2017
20:56:00
20:56:00
а что под модулем понимается в данном контектсе?
модуль = элемент декомпозиции системы. Представь себе систему как граф больших модулей которые тоже состоят из модулей по меньше и тд."бандлы" - это тоже модули, которые можно делать не бандлами а просто модулями.
Sergei02.05.2017
20:56:37
20:56:37
алгоритм такой был
- проверяем нет ли блокировки
- если нет то ставим
-созраняем в базу часть инфы
-сохраняем фалы аттачмента
-сохраняем в базу ссылки на аттачмент
-снимаем блокировку
1,2 и последний пункт ты вынесешь в отдельный класс
Sergey02.05.2017
20:57:19
20:57:19
алгоритм такой был
- проверяем нет ли блокировки
- если нет то ставим
-созраняем в базу часть инфы
-сохраняем фалы аттачмента
-сохраняем в базу ссылки на аттачмент
-снимаем блокировку
вместо нескольких строк кода определенно нужно сделать мегаиерархиюSergey02.05.2017
20:57:25
20:57:25
это упрощенно конечно, там чуть больше действий и они в одном методе были почти все
есть мнение что можно сделать класс декларирующий всю эту логику (последовательность действий) и если там не будет if-ов то можно хоть 20 зависимостей туда пихать (хотя конечно меньше лучше)то есть в этом случае у тебя был бы один метод где записан эдакий "сценарий" чего делать. Дела уже будут делегироваться отдельным объектам
но зато всю бизнес логику, весь юзкейс был бы как на ладони
Артур Евгеньевич02.05.2017
20:58:11
20:58:11
по факту у меня тоже самое и вышло, только тут еще отдельно вынесен DBStorage. Как бы направление то я верное выбрал, но пока делал не покидала ощущение, что делаю что то бессмысленное, просто из одного горшка в другой перекладываю, только увеличивая число горшков
Sergei02.05.2017
20:58:29
20:58:29
Артур Евгеньевич02.05.2017
20:58:30
20:58:30
вместо нескольких строк кода определенно нужно сделать мегаиерархию
да именно на этой мысле я себя и поймал((Sergey02.05.2017
20:58:48
20:58:48
каждый стэп алгоритма - отдельные объекты которые легко тестить. И один позитивный интеграционный тест на весь юзкейс
штуки типа логирования действительно удобно в декораторы выносить
Sergey02.05.2017
20:59:49
20:59:49
это единственное что явно не относится к основной логике и этому не место будет в нашем классе-юзкейсу
GoogleSergey02.05.2017
21:00:24
21:00:24
2-3 зависимости на объект не больше. Иначе надо избавляться от логики в классе и выносить в другие объекты
(иногда можно наплевать на это и сделать жирные штуки с пометками "отрефакторить когда буду лучше понимать как это должно работать и как это будет использоваться")
Артур Евгеньевич02.05.2017
21:02:32
21:02:32
мне кажетс должен баланс все таки быть, в некоторых моментах все таки лучше чуть переборщить с зависимостями, чем городить многоступенчатую иерархию
пока так ка кто ощущаю
Sergey02.05.2017
21:05:18
21:05:18
да прибудит с вами high cohesion и low coupling
код все-таки должен быть читаемый, а прыгать из файла в файл что бы восстановить флоу так себе веселье, тем более что можно сделать все грамотно и без этого
Артур Евгеньевич02.05.2017
21:06:43
21:06:43
вообще у меня интересные ощущения сецчас, вроде много всего поначитался нахватался в плане архитектурных "бест практикс" но вот когда работаю с кодом, то ощущаю что четкого понимания и осознания нет, когда и как что лучше сделать
Sergey02.05.2017
21:07:04
21:07:04
Roman02.05.2017
21:07:11
21:07:11
Артур Евгеньевич02.05.2017
21:07:31
21:07:31
код все-таки должен быть читаемый, а прыгать из файла в файл что бы восстановить флоу так себе веселье, тем более что можно сделать все грамотно и без этого
ага, но вот это противоречит помоему утверждению, что все лучше максимлаьно дробить на маленькие классы?Sergey02.05.2017
21:07:31
21:07:31
и никак не решают проблему "прыжков"
Roman02.05.2017
21:07:37
21:07:37
Ну иерархия всеж
Артур Евгеньевич02.05.2017
21:07:46
21:07:46
Sergey02.05.2017
21:08:11
21:08:11
ага, но вот это противоречит помоему утверждению, что все лучше максимлаьно дробить на маленькие классы?
не "классы" а "объекты". И "маленькие" не по количеству кода (хотя часто оно так и выходит) а по ответственности которая на объектах лежит.просто интересно как другие люди трактуют
во всяком случае я так делаю и это так вполне удобно
а потом подумай нужны ли тебе модули состоящие из 10-ти уровней?
GoogleRoman02.05.2017
21:10:19
21:10:19
а потом подумай нужны ли тебе модули состоящие из 10-ти уровней?
Да я больше двух уровней вариантов не встречалSergey02.05.2017
21:10:41
21:10:41
или там App/Entity?
Roman02.05.2017
21:11:41
21:11:41
Видел код игрухи на джаве. Там 2 или 3 было
AdminERROR: S client not available
Артур Евгеньевич02.05.2017
21:12:11
21:12:11
не "классы" а "объекты". И "маленькие" не по количеству кода (хотя часто оно так и выходит) а по ответственности которая на объектах лежит.
Принципы расположения смысловых блоков кода в системе( по модулям, слоям, классам, компонентам и т.д) призванные сделать работу с этим кодом максимально понятной и удобной. Иными словами под работой над архитектурой я понимаю проектирвоание системы с расчетом на максимально простое развитие, модификацию и поддержкукак то криво сказал, но думаю суть моего взгляда понятна
Sergey02.05.2017
21:14:43
21:14:43
Принципы расположения смысловых блоков кода в системе( по модулям, слоям, классам, компонентам и т.д) призванные сделать работу с этим кодом максимально понятной и удобной. Иными словами под работой над архитектурой я понимаю проектирвоание системы с расчетом на максимально простое развитие, модификацию и поддержку
мой вариант - "архитектура - набор ограничений которые разработчики накладывают на разрабатываемую систему дабы добиться определенных характеристик этой системы". К примеру - нам нужно независимо деплоить куски системы - микросервисы, нам нужна возможность полной замены инфраструктуры - гексагональная архитектура. Ну и т.д.отсюда в зависимости от проекта и требований к нему могут сильно разниться такие понятия как "допустимый размер класса"
если у тебя нет четкого представления что ты хочешь получить от системы, или нет четких ограничений "чего ты не можешь делать" и тт.д то как бы и архитектуры нет
ну и с "размерами" тоже веселье - их нельзя мерять строками кода
куча субъективщины короче
и это делает все очень сложным
f4rt~02.05.2017
21:16:41
21:16:41
лучшее определение, что я читал)
GoogleSergey02.05.2017
21:17:01
21:17:01
я у Роя Филдинга стырил
f4rt~02.05.2017
21:17:09
21:17:09
@fes0r ты принял приглашение devconf или как его там?
Sergey02.05.2017
21:17:40
21:17:40
@fes0r ты принял приглашение devconf или как его там?
ну не то что бы "принял" - мне надо придумать что засылать на рассмотрениеf4rt~02.05.2017
21:17:53
21:17:53
с темой еще не определился?
Sergey02.05.2017
21:18:18
21:18:18
с темой еще не определился?
ну тип того, меня просто еще кое куда позвали и там временные рамки слишком плотные выходята на devconf попробую запихнуть знакомого
он харизматичнее меня)
f4rt~02.05.2017
21:18:52
21:18:52
харизма лишь малая часть)
Sergey02.05.2017
21:18:58
21:18:58
правда он скорее в pm-скую ветку пойдет жечь пуканы
харизма лишь малая часть)
ну насколько я понял уровень разработчиков на devconf чуть повыше, а мне хочется вещать на темы которые больше новичкам подходятf4rt~02.05.2017
21:20:17
21:20:17
ты прям идеальный ментор, на работе джуны поди в очередь собираются)
Sergey02.05.2017
21:20:25
21:20:25
нет джунов - нет проблем
ты прям идеальный ментор, на работе джуны поди в очередь собираются)
я пипец не терпеливый, так что врядлину то есть, если мне интересно - я терпилив. А если нет и кто-то тупит - я злюсь
f4rt~02.05.2017
21:21:32
21:21:32
ну погоди, ты же сам говоришь, хочешь дарить знания новичкам)
следовательно тебе самому это необходимо)
разве кто то выбирает ментора по духу?)
Sergey02.05.2017
21:22:04
21:22:04
ну погоди, ты же сам говоришь, хочешь дарить знания новичкам)
следовательно тебе самому это необходимо)
тут с другой стороны надо смотреть. Ты когда материал пытаешься донести другим - ты сам в этом прошариваешься. Для меня это повод переваривать информацию.f4rt~02.05.2017
21:22:14
21:22:14
это да
+ еще свежий взгляд, не всегда конечно от этого много пользы, но все равно)
Sergey02.05.2017
21:22:30
21:22:30
пойду чистить свой говнокод(
f4rt~02.05.2017
21:22:39
21:22:39
давай, сорре что отвлек)
da horsie02.05.2017
21:32:45
21:32:45
Я бы архитектуру в смысле software design определил как свойство системы (как совокупности программного кода) адаптироваться под изменяющиеся требования к ней, где источником требований являются потребители бизнес-процессов, которые реализует система. Если система адаптируется быстро и дешево - это хорошая архитектура. Если долго и при этом часто ломается (перестает соответствовать внешним требованиями) - плохая.
Открыть в Telegram