Тест кода — военнослужащий отдела технического контроля – готов по тревоге выполнить приказ.
Отказ от тестов выглядит как отказ от мобилизации.
Чтобы получить выгоды (времени, денег, нервов) от тестов:
— код нужен простой и «тупой», чтобы тесты были такими же, чтобы их можно было автоматически создавать.
— повторять себя — создавать сложные сценарии общением уже протестированных простых объектов, методов.
— на новые сложные сценарии придумывать простые, дешёвые тесты.
На каких-то участках кода придётся использовать спецназ — креативных, дорогих.
Но большая часть армии тестов: дешёвые, малообученные наёмники.
Признайте, что Красная Армия это хорошее изобретение гражданской войны и я закрою глаза на Вашу странную попытку перевести обсуждение в военное искусство.
Я узнал Вас!
Тот, кто за деревьями не видит леса.
Я не обсуждал механизмы отмены ДП. Я дал ссылку.
Если я не собираюсь с Вами обсуждать механизмы отмены ДП, это не значит, что не было ни механизмов отмены ДП, ни самой ДП.
В войне участвует больше одной стороны, в гражданскую войну Россия и не порадовала мир изобретениями, но Вы можете погуглить про изобретения других участников войны.
Значит Хрущёв отменил, то чего не было?
Нет. И по ссылке выше найдёте про установление диктатуры.
Про обещание Хрущёва построить коммунизм мне понравилась версия Фалеева Алексея (RIP)
Мне нравится Ваш задор!
«И мы когда-то были рысаками».
Объектное мышление, отличное от процедурного появилось не случайно, а вынужденно.
Пара случаев: 1963 СССР: «При внесении исправлений в транслятор мы столкнулись со своеобразным принципом «кибернетической неопределенности», состоящим в том, что существует такой критический предел сложности некоторой системы, за которым любая попытка исправить некоторую ошибку вносит в систему новые ошибки из-за невозможности точно учесть все последствия какого бы то ни было изменения в системе. Пока что нам удавалось не переступать этот предел, однако не раз случалось, что исправление пустяковой ошибки надолго выводило из строя АЛЬФА-транслятор».
1985 США: "Дэвид Lorge Парнас ушёл из Группы SDIO по вычислениям ..., утверждая ..., что программы требуемые стратегической оборонной инициативе не могут быть сделаны, чтобы быть надежными и, что такая система неизбежно будет ненадежна"
А потом пришёл маркетинг и начали изучать ООП процедурно.
Игнорируется назначение ООП — решать задачи, которые НЕ решаются процедурно.
ООП появилось не взамен процедурному, не чтобы его уничтожить, а для расширения возможностей программистов — решения задач не решаемых процедурно.
Не в один день, не самые глупые программисты обнаружили, что часть задач, не решаемых процедурно, решаются общением объектов, имеющих память.
Обобщили, абстрагировали и теперь в случаях, когда разработчик не может алгоритмами решить задачу — он придумывает объекты, организовывает из взаимодействие и надеется, чтобы решение и способ решения совпадёт с расчётными, радуется, когда получилось лучше ожидаемого и переделывает свои объекты и свою модель взаимодействия объектов).
Надеется, потому что заранее неизвестно, к чему приведёт общение объектов — в коде решение не прописано, оно может лишь проявится.
Если вы описали в коде хорошее решение — хорошо — Вы хороший программист, процедурный.
Один из способов облажаться с иллюзией знания ООП:
Выбирается задача, которая запросто решается и без ООП, затем из-за неумения мыслить объектно, решается сложно, избыточно, используя ПседвоООП и делается вывод, «Не используйте ООП. Никогда. Это ошибка.»
Мы обычно хорошо мы манипулируем неодушевлёнными объектами, с неодушевлёнными сложнее.
В случае появления одушевлённых объектов в задаче, мы можем лишь подготовить условия для происхождения каких-то событий, оно они не обязательно произойдут — даже в нашем собственном коде.
В живом ООП кошка не обязана есть — неизвестны состояния объектов.
Нужно придумать и написать код, который будет нам давать знания о состоянии животного и код, который будет корректировать наше поведение в зависимости от поведения других объектов.
В задаче «человеку покормить кошку, воспользовавшись кормушкой» есть допущение, что это неизбежно произойдёт, и она «элегантно» решается алгоритмически: в мясорубку-функцию закинем кошку и кормушку. У Вас кошка не объект живой, а предмет. Кто тут с кем общается?
Пусть задача сложная, важная, нужная, но если она решается и без общения объектов, алгоритмически, решите понятным Вам способом.
Объектное мышление придёт на помощь, когда полезное, нужное процедурное мышление упрётся в свои границы.
numb появился не вместо x, а вместо someOutputIntGreaterThanInputInt.
Объясняю метафору про фрукты — у некоторых реально непереносимость фруктов — не повезло им. А в нашем случае у некоторых непереносимость контекстнооудобных имён переменных, методов, объектов — они не замечают накопления когнитивного стресса вызванного когнитивной сложностью — не повезло им.
Стресс сложности накроет их несколько позже, а причину они не увидят (они же не знают о вреде однобуквенных названий).
О! Однобуквенный беспредел :-)
Инкапсуляция придумана скрывать «как делать», а не скрывать что она вернёт.
Компьютер Ваш код понимает — нам хочется его понять, минимизируя когнитивные усилия.
Однобуквенной вакханалией вы усложняете понимание Вашего кода.
Не упрёк.
С людьми не гуляем, с животными гуляем.
Породистые животные правят людьми.
Тест кода — военнослужащий отдела технического контроля – готов по тревоге выполнить приказ.
Отказ от тестов выглядит как отказ от мобилизации.
Чтобы получить выгоды (времени, денег, нервов) от тестов:
— код нужен простой и «тупой», чтобы тесты были такими же, чтобы их можно было автоматически создавать.
— повторять себя — создавать сложные сценарии общением уже протестированных простых объектов, методов.
— на новые сложные сценарии придумывать простые, дешёвые тесты.
На каких-то участках кода придётся использовать спецназ — креативных, дорогих.
Но большая часть армии тестов: дешёвые, малообученные наёмники.
IT = «Информационные технологии'.
В статье описываются случаи воздействия информации на реальную жизнь.
Указаны технологии:
В статье упомянут телеграф,
телеграф связан с кодами.
14 государств.
Самое заметное изобретение гражданской войны — Красная армия. Если Вы и про неё ничего не нагуглите…
Тот, кто за деревьями не видит леса.
Я не обсуждал механизмы отмены ДП. Я дал ссылку.
Если я не собираюсь с Вами обсуждать механизмы отмены ДП, это не значит, что не было ни механизмов отмены ДП, ни самой ДП.
Значит Хрущёв отменил, то чего не было?
Нет. И по ссылке выше найдёте про установление диктатуры.
Про обещание Хрущёва построить коммунизм мне понравилась версия Фалеева Алексея (RIP)
«И мы когда-то были рысаками».
Объектное мышление, отличное от процедурного появилось не случайно, а вынужденно.
Пара случаев:
1963 СССР: «При внесении исправлений в транслятор мы столкнулись со своеобразным принципом «кибернетической неопределенности», состоящим в том, что существует такой критический предел сложности некоторой системы, за которым любая попытка исправить некоторую ошибку вносит в систему новые ошибки из-за невозможности точно учесть все последствия какого бы то ни было изменения в системе. Пока что нам удавалось не переступать этот предел, однако не раз случалось, что исправление пустяковой ошибки надолго выводило из строя АЛЬФА-транслятор».
1985 США: "Дэвид Lorge Парнас ушёл из Группы SDIO по вычислениям ..., утверждая ..., что программы требуемые стратегической оборонной инициативе не могут быть сделаны, чтобы быть надежными и, что такая система неизбежно будет ненадежна"
А потом пришёл маркетинг и начали изучать ООП процедурно.
Игнорируется назначение ООП — решать задачи, которые НЕ решаются процедурно.
ООП появилось не взамен процедурному, не чтобы его уничтожить, а для расширения возможностей программистов — решения задач не решаемых процедурно.
Не в один день, не самые глупые программисты обнаружили, что часть задач, не решаемых процедурно, решаются общением объектов, имеющих память.
Обобщили, абстрагировали и теперь в случаях, когда разработчик не может алгоритмами решить задачу — он придумывает объекты, организовывает из взаимодействие и надеется, чтобы решение и способ решения совпадёт с расчётными, радуется, когда получилось лучше ожидаемого и переделывает свои объекты и свою модель взаимодействия объектов).
Надеется, потому что заранее неизвестно, к чему приведёт общение объектов — в коде решение не прописано, оно может лишь проявится.
Если вы описали в коде хорошее решение — хорошо — Вы хороший программист, процедурный.
Один из способов облажаться с иллюзией знания ООП:
Выбирается задача, которая запросто решается и без ООП, затем из-за неумения мыслить объектно, решается сложно, избыточно, используя ПседвоООП и делается вывод, «Не используйте ООП. Никогда. Это ошибка.»
Мы обычно хорошо мы манипулируем неодушевлёнными объектами, с неодушевлёнными сложнее.
В случае появления одушевлённых объектов в задаче, мы можем лишь подготовить условия для происхождения каких-то событий, оно они не обязательно произойдут — даже в нашем собственном коде.
В живом ООП кошка не обязана есть — неизвестны состояния объектов.
Нужно придумать и написать код, который будет нам давать знания о состоянии животного и код, который будет корректировать наше поведение в зависимости от поведения других объектов.
В задаче «человеку покормить кошку, воспользовавшись кормушкой» есть допущение, что это неизбежно произойдёт, и она «элегантно» решается алгоритмически: в мясорубку-функцию закинем кошку и кормушку. У Вас кошка не объект живой, а предмет. Кто тут с кем общается?
Пусть задача сложная, важная, нужная, но если она решается и без общения объектов, алгоритмически, решите понятным Вам способом.
Объектное мышление придёт на помощь, когда полезное, нужное процедурное мышление упрётся в свои границы.
Даже есть некоторая иллюзия понимания кода.
Это же Haskell?
Код Вас устраивает?
Для устранения ошибок опытным путём нашли разные способы. Один из них я Вам предложил.
И не от многих букв, а от имён, упрощающих понимание.
Объясняю метафору про фрукты — у некоторых реально непереносимость фруктов — не повезло им. А в нашем случае у некоторых непереносимость контекстнооудобных имён переменных, методов, объектов — они не замечают накопления когнитивного стресса вызванного когнитивной сложностью — не повезло им.
Стресс сложности накроет их несколько позже, а причину они не увидят (они же не знают о вреде однобуквенных названий).
А у нас тут две крайности не хотят прийти к балансу — однобуквенные против когнитивностранных имён.
Инкапсуляция придумана скрывать «как делать», а не скрывать что она вернёт.
Компьютер Ваш код понимает — нам хочется его понять, минимизируя когнитивные усилия.
Однобуквенной вакханалией вы усложняете понимание Вашего кода.