К
Size: a a a
2020 January 01
К
Интерфейсы не содержат логику. Если без дефолтной реализации
давай про дефолтную реализацию теперь, неочевидно же
B
И необходимости переопределять get/set у меня не возникало уже несколько лет. И, пожалуй, если бы она сейчас возникла - я бы постарался найти способ обойтись без этого
Ну если класс - DTO, то необходимости и впрямь нет. А если там стейтфул с инвариантами?
IB
допустим
и как часто у вас наступает это позже?
и как часто у вас наступает это позже?
судя по частоте применения, это практически стандарт - все публичное только в пропертях, поля наружу не выставлять кроме как статические иногда.
RN
давай про дефолтную реализацию теперь, неочевидно же
Даю. Спорная штука, нужна в отдельных случаях
RN
Так... Да, очевидно
RN
Лан, сорри, я сливаюсь, тон беседы странный выходит :)
OM
интерфейсы не юзаешь?
имхо интерфейсы надо проектировать через методы и геттеры
условный SomeLogic или AddSomething или еще чего
в разы лучшее, чем публичный сеттер, от которого вообще неизвестно что ожидать глядя на интерфейс
условный SomeLogic или AddSomething или еще чего
в разы лучшее, чем публичный сеттер, от которого вообще неизвестно что ожидать глядя на интерфейс
OM
да и геттер сомнительно тоже
К
имхо интерфейсы надо проектировать через методы и геттеры
условный SomeLogic или AddSomething или еще чего
в разы лучшее, чем публичный сеттер, от которого вообще неизвестно что ожидать глядя на интерфейс
условный SomeLogic или AddSomething или еще чего
в разы лучшее, чем публичный сеттер, от которого вообще неизвестно что ожидать глядя на интерфейс
ну это логично, зачем юзать свойства так чтобы они вызывали жжение в пятой точке?
AT
А можно я влезу с мнением, что публичный set - штука, которой стоит скорее избегать? А просто публичное readonly поле это нормально и get/set едва ли понадобятся
Поле передать на свойство без перекомпиляции зависимых сборок не выйдет, если вдруг в сеттер надо будет внедрить логику
IC
так твой интерфейс это публичный гет/сет, что аналогично полю
от того, что тебе легко разъебать этот контракт не звучит как плюс
что изменение модификаторов доступа, что внезапная вставка логики, на которую не расчитывали
от того, что тебе легко разъебать этот контракт не звучит как плюс
что изменение модификаторов доступа, что внезапная вставка логики, на которую не расчитывали
Чем аналогичен? В get; set; я могу добавить логику, к публичному полю нет.
AT
Не сказал бы, что это плохая практика - скорее трейдофф. Например, навешивание дополнительной логики на get/set, как по мне - это спорная идея, которая уменьшает понятность кода и увеличивает вероятность случайной ошибки, трудной для отладки
Если ты колбасишь анемичную модель - это аргумент, но со своим сроком годности: оно тоже при измерении стреляет больно
AT
И необходимости переопределять get/set у меня не возникало уже несколько лет. И, пожалуй, если бы она сейчас возникла - я бы постарался найти способ обойтись без этого
Дтошки гоняешь?
OM
Чем аналогичен? В get; set; я могу добавить логику, к публичному полю нет.
лучше пусть рекомпильнутся, чем получать чейнджы в участках там, где они не ожидались