Это если рефакторинг в отдельной задаче. Если в этой же, то никаких проблем нет. Задачу нужно загрузить в голову и она грузится в процессе написания, пусть даже не самого лучшего код, потом рефачишь, потом делаешь сефл ревью, потом отдаёшь пул рек.
Кому надо? Мне проще за зиму несколько раз повернуть трёхходовой, чем мутить автоматику. Автоматика у меня для отопления радиаторами на втором этаже: отключается насос по достижению заданной температуры.
У меня тёплые полы (90квм), не заметил каких-то фатальных перегревов или охлаждений. Инерция где-то часов 6. Единственное что замечаю, сам пол может стать слишком тёплым, когда с -30 до -5 температура поднялась на улице. Температуру регулирую сам, но почти всю зиму в этом нет необходимости.
Рекомендую Антихрупкость, там точно такие же рассуждение, только ещё больше.
послание к Гарсия
Самостоятельность это хорошо, но уж больно всё категорично. Типа менеджемент дал приказ, сотрудник без лишних вопросов пошёл и сделал. Лучше спросить очевидное, чем сделать не то.
Например? проще править класс, чем делать его закрытым для изменения и открытым для расширения. Или не во все места стоит вставлять инвертированные зависимости.
Вот принцип подстановки нужно соблюдать неукоснительно, ибо когда наследник нарушает контракт, это фу-фу-фу и код становится сложнее.
Вообще, хорошо зная принципы разработки, можно обосновать любой код.
Спасибо за ответ. Но я бы не сказал, что эти шаблоны во всех отношениях лучше чем энум, по ситуации нужно действовать. Основной недостаток - это тяжеловесность. Где-то профиты от шаблоны перекрывают её, где-то овчинка не стоит выделки.
Впрягусь: юзинги без скобок нужны, когда их много, чтобы код не сдвигался слишком сильно вправо. Ещё часто ресурс создаётся в начале и уничтожается в конце функции. Тут юзинги без скобок тоже подходят.
Я использовал подобный подход и по итогу запросы из репозитария расползаются по всей программе и реализованы немного по разному. За этим нужно следить.
В итоге использую всевозможные построили запросов только внутри репозитария. Это внутреннее дело репы, как оно там всё хранится и как строить запросы. Но у меня своя специфика в виде даппера.
Чтобы справиться с комбинаторным взрывом использую концепцию фильтров, когда null обозначает отсутствие фильтра. Например: GetEmployees(Sex? sexFilter = null, int? minAgeFilter = null, ...). При вызове явно указываю названия использованных фильтров, чтобы не было GetEmployees(false, 24).
Ситуации, когда нужно много и хитро фильтровать у меня возникают редко, обычно делаю выборки по включению значений или диапазону. Т.е. нет необходимости как-то хитро, а главное разнообразно делать выборки в прикладном коде, хватает небольшого количества методов репозитария.
У меня довольно мало случаев, когда маппинг 1 к 1: либо названия меняются, либо нужно преобразование с подтягиванием каких-то данных делать. Чисто теоретически, сложилось ощущение, то автомаппинг настраивать надо и это как-то не сильно выгоднее, чем присвоить поле руками.
В каких реальных кейсах помогает автомапинг? есть примеры кода?
Мне не чтобы докопаться, мне чтобы работу свою облегчить.
Я люблю использовать обёртки структуры над элементарными типам. Например, если в бд есть число наличия товара и 0 - обозначает "под заказ", то обёртка "доступное количество" будет содержать метод для проверки под заказ ли этот товар, чтобы по коду не расползалисьavailableQuantity == 0. Ну или ноль в специальной константе находится, но сути это не меняет. Т.е. знание о том, что значит 0 находится ровно в одном месте и это хорошо.
На самое интересное, что структура над интом в результате компиляции исчезает из ассемблерного кода: по функциям путешествует обычный инт, а функции инлайнятся. Прямо zero cost abstraction.
Вместо перемапливания создаём класс или структуру суть которой сводится к public int Id => person.Id;. Я так даже делал когда генерировал отчёт и обёртка уходила в генератор экселины.
А бесплатность была про то, что код маппинга всё равно писать и без разницы будет это обёртка или копирование в отдельный объект.
Я же главную проблему с обёртками вижу в связи обёртки с оборачиваемым типом. В ситуации, когда зависимая библиотека выставляет контракт и ничего не знает про наши типы, обёртку в неё можно будет передать только как наследника интерфейса. В дикой природе такое не встречается и обычно либы принимают какие-то свои ДТОхи.
Это если рефакторинг в отдельной задаче. Если в этой же, то никаких проблем нет. Задачу нужно загрузить в голову и она грузится в процессе написания, пусть даже не самого лучшего код, потом рефачишь, потом делаешь сефл ревью, потом отдаёшь пул рек.
Кому надо? Мне проще за зиму несколько раз повернуть трёхходовой, чем мутить автоматику. Автоматика у меня для отопления радиаторами на втором этаже: отключается насос по достижению заданной температуры.
У меня тёплые полы (90квм), не заметил каких-то фатальных перегревов или охлаждений. Инерция где-то часов 6. Единственное что замечаю, сам пол может стать слишком тёплым, когда с -30 до -5 температура поднялась на улице. Температуру регулирую сам, но почти всю зиму в этом нет необходимости.
Да, именно это я и имел ввиду.
Рекомендую Антихрупкость, там точно такие же рассуждение, только ещё больше.
Самостоятельность это хорошо, но уж больно всё категорично. Типа менеджемент дал приказ, сотрудник без лишних вопросов пошёл и сделал. Лучше спросить очевидное, чем сделать не то.
Например? проще править класс, чем делать его закрытым для изменения и открытым для расширения. Или не во все места стоит вставлять инвертированные зависимости.
Вот принцип подстановки нужно соблюдать неукоснительно, ибо когда наследник нарушает контракт, это фу-фу-фу и код становится сложнее.
Вообще, хорошо зная принципы разработки, можно обосновать любой код.
Работая с джунами, я понимаю, что это нифига не шутки: бывают просто не могут связно мысль сформулировать. При этом могут прилично кодить.
Спасибо за ответ. Но я бы не сказал, что эти шаблоны во всех отношениях лучше чем энум, по ситуации нужно действовать. Основной недостаток - это тяжеловесность. Где-то профиты от шаблоны перекрывают её, где-то овчинка не стоит выделки.
А какие шаблоны лучше во всех отношениях чем enum?
Впрягусь: юзинги без скобок нужны, когда их много, чтобы код не сдвигался слишком сильно вправо. Ещё часто ресурс создаётся в начале и уничтожается в конце функции. Тут юзинги без скобок тоже подходят.
var нужен для анонимных типов. А анонимные типы нужны были Linq, а без linq шарп не шапр.
Запуск без Main, глобальные юзинги и обобщённая математика нужны для ML. Догоним и перегоним питон типа. Мне ML никуда не упёрся, но и не мешает.
А свич кейсы лично мне нравятся, стало удобнее.
У нас в компании нет менеджеров, но я полностью согласен, что
Я использовал подобный подход и по итогу запросы из репозитария расползаются по всей программе и реализованы
немного по разному. За этим нужно следить.В итоге использую всевозможные построили запросов только внутри репозитария. Это внутреннее дело репы, как оно там всё хранится и как строить запросы. Но у меня своя специфика в виде даппера.
Чтобы справиться с комбинаторным взрывом использую концепцию фильтров, когда null обозначает отсутствие фильтра. Например:
GetEmployees(Sex? sexFilter = null, int? minAgeFilter = null, ...). При вызове явно указываю названия использованных фильтров, чтобы не былоGetEmployees(false, 24).Ситуации, когда нужно много и хитро фильтровать у меня возникают редко, обычно делаю выборки по включению значений или диапазону. Т.е. нет необходимости как-то хитро, а главное разнообразно делать выборки в прикладном коде, хватает небольшого количества методов репозитария.
А как понять что она выше по приоритету? В предложенной схеме то что справа выше всего, не зависимо от приоритета карточки, как я понял.
Вот пример где DTO и геттер - не sealed. Один фиг не получится поле заоверрайдить, если оно не виртуальное.
Если не прав, жду ссылку на код.
У меня довольно мало случаев, когда маппинг 1 к 1: либо названия меняются, либо нужно преобразование с подтягиванием каких-то данных делать. Чисто теоретически, сложилось ощущение, то автомаппинг настраивать надо и это как-то не сильно выгоднее, чем присвоить поле руками.
В каких реальных кейсах помогает автомапинг? есть примеры кода?
Мне не чтобы докопаться, мне чтобы работу свою облегчить.
А какие есть варианты лучше, именно с точки зрения поддержки?
Кажись нет: не получится оверрайдить не виртуальные функции и после каста к исходной дто, значения будут читаться из исходных полей.
Я люблю использовать обёртки структуры над элементарными типам. Например, если в бд есть число наличия товара и 0 - обозначает "под заказ", то обёртка "доступное количество" будет содержать метод для проверки под заказ ли этот товар, чтобы по коду не расползались
availableQuantity == 0.Ну или ноль в специальной константе находится, но сути это не меняет. Т.е. знание о том, что значит 0 находится ровно в одном месте и это хорошо.На самое интересное, что структура над интом в результате компиляции исчезает из ассемблерного кода: по функциям путешествует обычный инт, а функции инлайнятся. Прямо zero cost abstraction.
Вместо перемапливания создаём класс или структуру суть которой сводится к
public int Id => person.Id;. Я так даже делал когда генерировал отчёт и обёртка уходила в генератор экселины.А бесплатность была про то, что код маппинга всё равно писать и без разницы будет это обёртка или копирование в отдельный объект.
Я же главную проблему с обёртками вижу в связи обёртки с оборачиваемым типом. В ситуации, когда зависимая библиотека выставляет контракт и ничего не знает про наши типы, обёртку в неё можно будет передать только как наследника интерфейса. В дикой природе такое не встречается и обычно либы принимают какие-то свои ДТОхи.