AH
В общем я погуглил, там все примерно одинаково звучит в этом ценовом диапазоне, поэтому думаю смысл выбирать по приципу "красиво смотрятся"
Спасибо)
Size: a a a
2021 February 25
N👩
@boringdev будешь моим стилистом?)
haha davai
Вキ
Спасибо)
А хороший звук выходит где-то от 1000 долларов + подготовка помещения и прочие нюансы
VS
А хороший звук выходит где-то от 1000 долларов + подготовка помещения и прочие нюансы
VV
А хороший звук выходит где-то от 1000 долларов + подготовка помещения и прочие нюансы
на самом деле можно и до 1к долларов уложиться изи
Вキ
на самом деле можно и до 1к долларов уложиться изи
го, я бы послуал)
A
на самом деле можно и до 1к долларов уложиться изи
мне тоже интересно
VV
VV
Можно вечером создать клабхаус и потрындеть 😅
Вキ
Можно вечером создать клабхаус и потрындеть 😅
тогда давай перед этим создадим приватную комнату и настроим мне микрофон)
L
Кто-то делал колонку недель в матириале?
L
Чёт не могу найти в доке подобное
SS
Добрый день. Как считаете, нормальная ли практика - комбинировать похожие интерфейсы (в рамках одной сущности)? например вместо содержания CreateSomethingInterface, UpdateSomethingInterface, SomethingInterface, хочется все сложить в SomethingInterface, особенно когда различия незначительные + для создания и обновления используется как правило одна форма и не хотелось бы туда сюда мапить данные лишний раз
Вキ
Sergei Sergeevich
Добрый день. Как считаете, нормальная ли практика - комбинировать похожие интерфейсы (в рамках одной сущности)? например вместо содержания CreateSomethingInterface, UpdateSomethingInterface, SomethingInterface, хочется все сложить в SomethingInterface, особенно когда различия незначительные + для создания и обновления используется как правило одна форма и не хотелось бы туда сюда мапить данные лишний раз
Если планируется, что некоторые сущности могут реализовывать только один из интерфейсов, то лучше не объединять их
SS
Если планируется, что некоторые сущности могут реализовывать только один из интерфейсов, то лучше не объединять их
речь идет об интерфейсах вокруг одной сущности. Например:
Пирожок{ начинка:string;}
ИспечьПирожок{начинка:string; побыстрее:boolean}
Да, свойство "пирожок.побыстрее" выглядит не логично, но такая нагрузка пойдет только в метод созданияВキ
Sergei Sergeevich
речь идет об интерфейсах вокруг одной сущности. Например:
Пирожок{ начинка:string;}
ИспечьПирожок{начинка:string; побыстрее:boolean}
Да, свойство "пирожок.побыстрее" выглядит не логично, но такая нагрузка пойдет только в метод созданияЕсли это разные доменные сущности, то ты вправе их разделять
C
Sergei Sergeevich
речь идет об интерфейсах вокруг одной сущности. Например:
Пирожок{ начинка:string;}
ИспечьПирожок{начинка:string; побыстрее:boolean}
Да, свойство "пирожок.побыстрее" выглядит не логично, но такая нагрузка пойдет только в метод созданияМои любимые фишки:
и объеденение типов по необходимости
ПирожокResponseПирожокRequestПирожоки объеденение типов по необходимости
C
а если
побыстрее: boolean применимо не только к Пирожок но и к Хлебушек то можно сделать универсальнымSS
Мои любимые фишки:
и объеденение типов по необходимости
ПирожокResponseПирожокRequestПирожоки объеденение типов по необходимости
ты наследовал бы ResponseПирожок от Пирожок?
SS
мне расстраивает не столько большое количество похожих интерфейсов сколько неопределенность в компоненте создания/редактирования. При том что он получает на входе Пирожок (при редактировании) и на выходе отправляет данные в метод create или update