Ну, если вашим разработчикам плевать на типы и структуры данных, то медицина здесь бессильна. А если вы название каждого метода дополняете еще и типом возвращаемых данных, то мягко говоря непонятно зачем вы вообще используете языки со статической типизацией при разработке.
Настолько частый паттерн, что я не представляю, как на нем можно спотыкаться при чтении.
Частый паттерн для меня for(int i = 0; ..). Чем тут var лучше int? Компактнее, наверное?
Знание типа не имеет никакой ценности без знания контракта. Тут, возвращаясь к вашим словам немного выше, для получения какого-то эффекта от знания типа, потребуется закэшировать контракт.
В случае, если дело происходит в IDE — вообще без разницы. А с var читается легче.
Если вам без разницы Document[], List или вообще IEnumarable, то это печально. Мне лично до определенного момент все равно как получили коллекцию, но мне всегда важно какая именно это коллекция.
Вот честно, я бы ноги отрывал за повсеместное использование var. Когда разработчик читает код, ему прежде всего важен тип и название переменной, а потом уже каким образом она инициализируется. var забирает у нас информацию о типе и заставляет наш мозг вычислять эту информацию либо на основе названия, либо на основе компиляции мозгом на лету.
Это может быть не сильно болезненно только лишь разработчику, который недавно написал этот код и его мозг закэшировал типы данных переменных. Читателю кода со стороны это никак не может быть удобно, ибо требует существенно больших усилий со стороны мозга.
Есть всего несколько случае, когда var имеет смысл:
1. Анонимные типы
2. Очень длинное название типа/здоровенный дженерик в результате LINQ
3. Длинное название типа/здоровенный дженерик и его очевидная инициализация в правой части выражения с помощью конструктора
Все остальное вида:
1. for (var i = 0; ...) { };
2. var documents = repo.GetDocuments()
3. var number = «superNumber»;
4. var mySuperNumber = a / b + c;
порождает лично у меня адскую попоболь и ручки так и тянутся к решарперу, дабы массово разыменовать эти долбаные varы.
Создавать еще одну сущность (пусть и private nested) ради метода? о_О Это еще менее логично, чем просто private метод, который используется только один раз.
В первом случае мы «засоряем» интерфейс класса, пускай и в приватной части, во втором случае мы «засоряем» лишь метод. В случае ЛФ сразу видно где код используется, в случае приватных методов проще переиспользовать код.
Но в случае ЛФ сразу возрастает уровень вложенности, что тоже читабельности не добавляет.
Лично я пока вижу адекватный сценарий использования ЛФ только в виде описания небольшой логики (в пределах 5-10 строк), которая нигде за пределами метода использоваться не будет. И, наверное, не более одной ЛФ на метод.
Правила (условия) изменения состояния сущностей можно хранить в спецификациях, проверять их в сервисах, а собственно изменения производить в сущностях, вызывая их методы (не тупо сеттеры, а с семантикой бизнес-процессов, не order.setStatus(STATUS_CANCEL), а order.cancel()) из этих сервисов, при условии соответствия сущности спецификации.
Подскажите, а есть ли какая-нибудь адекватная механика экспорта данных из Kibana? Для задачи вида: есть у нас сохраненный поиск по индексу MyLogIndex с фильтром MySuperEvent и хочу я выгрузить все данные за вчера, например.
То, что вы написали мне прекрасно понятно, однако на практике бизнес может придумать такое количество интересных правил изменения состояния сущности, что держать их все в рамках самой модели есть нарушать все принципы.
И чем лучше передача стратегии с логикой изменения состояния чем просто изменение состояния извне? Или я неправильно понял про стратегии в данном контексте?
Т.е. вот у нас есть Order. Бизнес начинает придумывать разные хитрые правила изменения состояния заказа в зависимости от погоды, дня недели и цвета чулок Марьиванны. Куда мы пихнем эти правила? Куда-то наверх. При этом модель будет анемичной, IOrderProcessingService будет являться фасадом, а внутрях у ней неонка с фабриками, стратегиями, репозиториями марьиванн, хитрыми пайплайнами и прочими классными шаблонами.
Веб-не веб в том разница, что в веб приложении мы вряд ли будем использовать какую-то событийную модель и реакции одних сущностей на изменения состояния других. Т.е. в вебе пайплайн.
Хмм а что мешает иметь еще слои абстракции над анемичной моделью, но под «сервисами»? Все же, я лично воспринимаю «сервисы» как фасады, реализующие некоторый контракт. Ничто не мешает иметь под капотом ООП по госту.
Кстати, рассказать как увидеть контракт, когда не используется var?
Document[] documents = repo.GetDocuments();
внеееезапно контракт:
Document[] IDocumentRepository.GetDocuments();
а вот c var вы вообще не поймете что там за контракт. Пока у IDE не спросите, конечно.
Частый паттерн для меня for(int i = 0; ..). Чем тут var лучше int? Компактнее, наверное?
Если вам без разницы Document[], List или вообще IEnumarable, то это печально. Мне лично до определенного момент все равно как получили коллекцию, но мне всегда важно какая именно это коллекция.
Прочее вообще комментировать смысла не вижу.
Это может быть не сильно болезненно только лишь разработчику, который недавно написал этот код и его мозг закэшировал типы данных переменных. Читателю кода со стороны это никак не может быть удобно, ибо требует существенно больших усилий со стороны мозга.
Есть всего несколько случае, когда var имеет смысл:
1. Анонимные типы
2. Очень длинное название типа/здоровенный дженерик в результате LINQ
3. Длинное название типа/здоровенный дженерик и его очевидная инициализация в правой части выражения с помощью конструктора
Все остальное вида:
1. for (var i = 0; ...) { };
2. var documents = repo.GetDocuments()
3. var number = «superNumber»;
4. var mySuperNumber = a / b + c;
порождает лично у меня адскую попоболь и ручки так и тянутся к решарперу, дабы массово разыменовать эти долбаные varы.
Я кончил и закурил.
P.S. Тут я про C#, но вас тоже это ждет.
Простите братья джависты, вырвалось.
Но в случае ЛФ сразу возрастает уровень вложенности, что тоже читабельности не добавляет.
Лично я пока вижу адекватный сценарий использования ЛФ только в виде описания небольшой логики (в пределах 5-10 строк), которая нигде за пределами метода использоваться не будет. И, наверное, не более одной ЛФ на метод.
Наверное имелось в виду, что yield return не используют.
С этим подходом согласен
И чем лучше передача стратегии с логикой изменения состояния чем просто изменение состояния извне? Или я неправильно понял про стратегии в данном контексте?
Т.е. вот у нас есть Order. Бизнес начинает придумывать разные хитрые правила изменения состояния заказа в зависимости от погоды, дня недели и цвета чулок Марьиванны. Куда мы пихнем эти правила? Куда-то наверх. При этом модель будет анемичной, IOrderProcessingService будет являться фасадом, а внутрях у ней неонка с фабриками, стратегиями, репозиториями марьиванн, хитрыми пайплайнами и прочими классными шаблонами.
Веб-не веб в том разница, что в веб приложении мы вряд ли будем использовать какую-то событийную модель и реакции одних сущностей на изменения состояния других. Т.е. в вебе пайплайн.