А если уйти от противоречий того, что я пишу, и написать как нужно? То есть вы поддерживаете способ изменения интерфейса и реализации? int DoSomething(int input1, int input2);наdouble DoSomething(int input1, int input2);
Допустим вчера у нас был интерфейс и реализация, в которой мы получаем результат умножения.
public interface IWorker
{
int DoSomething(int input1, int input2);
}
public class Worker : IWorker
{
public int DoSomething(int input1, int input2)
=> input1 * input2;
}
// TEST
А сегодня нам бизнес сказал, что нужно не умножать, а делить и получать результат деления. И это всё так же должен быть тот же самый метод, в котором нам нужно изменить интерфейс и реализацию?
public interface IWorker
{
// Меняем интерфейс
double DoSomething(int input1, int input2);
}
public class Worker : IWorker
{
// Меняем реализацию
public double DoSomething(int input1, int input2)
=> input1 / input2;
}
// Меняем тесты
Я склоняюсь к тому, что теперь должна быть ещё одна реализация.
public interface IWorker
{
int DoSomething(int input1, int input2);
double DoSomething2(int input1, int input2);
}
public class Worker : IWorker
{
// начальная реализация
public int DoSomething(int input1, int input2)
=> input1 * input2;
// Добавляем реализацию
public double DoSomething2(int input1, int input2)
=> input1 / input2;
}
// Добавляем TEST2
И если завтра нам нужно будет вернуть умножение, то в самой программе, мы просто изменим вызов worker.DoSomething2(4, 2) на worker.DoSomething(4, 2), и даже тесты не придётся править, и кстати все тесты, что сегодня, что завтра будут успешны.
Но, если в код добавилась новая ветка или вызов какого-то сервиса – нам надо править и тестирование, ветку надо обработать в существующих тестах и/или написать под нее отдельный тест, а новые вызовы надо замокать.
Есть функция, которая получает какие-то значения на входе, и возвращает какое-то значение на выходе, которое мы сравниваем с ожидаемым - это и есть тест.
Если у нас появилась необходимость изменить поведение функции, то есть на входе/выходе у нас теперь не то, что мы ожидали раньше, то нам нужно создавать новую функцию, которая будет работать по-другому, и под неё добавить ещё один тест.
Есть контракт (интерфейс) и если логика изменилась, то это будет нарушение контракта, так что его просто нужно расширить, а изменяя поведение старых функций, мы нарушаем принципы SOLID.
А деньги китайцы любят: чаще всего на восточный новый год можно услышать поздравление 恭喜发财 (gōngxǐ fācái), которое переводится как «желаем богатства и процветания»!
Ну так себе показатель. ?
Мы и на ДР друг другу желаем этого. Мы тогда ещё больше любим деньги ?
А если уйти от противоречий того, что я пишу, и написать как нужно?
То есть вы поддерживаете способ изменения интерфейса и реализации?
int DoSomething(int input1, int input2);наdouble DoSomething(int input1, int input2);
Допустим вчера у нас был интерфейс и реализация, в которой мы получаем результат умножения.
А сегодня нам бизнес сказал, что нужно не умножать, а делить и получать результат деления.
И это всё так же должен быть тот же самый метод, в котором нам нужно изменить интерфейс и реализацию?
Я склоняюсь к тому, что теперь должна быть ещё одна реализация.
И если завтра нам нужно будет вернуть умножение, то в самой программе, мы просто изменим вызов worker.DoSomething2(4, 2) на worker.DoSomething(4, 2), и даже тесты не придётся править, и кстати все тесты, что сегодня, что завтра будут успешны.
Есть функция, которая получает какие-то значения на входе, и возвращает какое-то значение на выходе, которое мы сравниваем с ожидаемым - это и есть тест.
Если у нас появилась необходимость изменить поведение функции, то есть на входе/выходе у нас теперь не то, что мы ожидали раньше, то нам нужно создавать новую функцию, которая будет работать по-другому, и под неё добавить ещё один тест.
Есть контракт (интерфейс) и если логика изменилась, то это будет нарушение контракта, так что его просто нужно расширить, а изменяя поведение старых функций, мы нарушаем принципы SOLID.
Интересно кто плюсов наставил? (на момент написания текущего коммента было 9)
Спасибо!
Продолжайте, буду читать.
Возможно, но я всё-таки дочитал )
Может year это дата основания/открытия ресторана
Ну так себе показатель. ?
Мы и на ДР друг другу желаем этого. Мы тогда ещё больше любим деньги ?
Странно столько наминусовали.
У человека на фото яблоко, он значит знает, что говорит )
Патентовать тогда нечего )
Ну когда уже дойдём до DI?
Что-то я не понял, у французов 2.75 дней, это 2 часа? )))
Вот тут они как по мне достаточно доступно объяснили ценообразование https://youtu.be/IeFvaGmoHZs
Никакого отношения к Яндекс не имею, только как пассажир.
Реальная эффективность. Как подняться на новый уровень.
Но ответа нет.
Успешный успех
Понятно что не сработает, но будет видно по стоимости, кто как переживает за данные.
У "рога и копыта" 0р, а у "копыта и рога" 1000р. Значит иду в ту которая больше изображает волнение цифрами.
P. S. "Главное, перейти от поэзии" - очень красиво!
Про бумажки Пример 2 как доедет до номера отеля? Рядом с бумажкой в чехле телефона или рядом с бумажкой в чемодане?
Идея отличная.