Метатред по серии "Автоматное программирование". Рассказываю тут про флаговое программирование, явно выделенное состояние, автоматы на бекенде, автоматы на фронтенде и кидаюсь кучей полезнях #FSM
1. Автоматы как способ моделировать процессы вокруг нас
Через час-два тред про функции. Многим кажется, что функции это просто, но нет. Хорошие функции выглядят просто, но реализовать их тяжело. Какими руководствоваться правилами? Об этом и поговорим. #functions
Поехали! Обычно, от функций ожидают сокращения дублирования кода. Да, функции устраняют дублирование, но лишь в дополнение к тому, зачем они нужны. Настоящий смысл функции – повышение уровня абстракции. Звучит немного абстрактно, поэтому раскроем подробнее =>
Мир сложная штука, но эта сложность спрятана за простыми и понятными вещами. Например, работать с клавиатурой может даже ребенок, но лишь потому что она хорошо спроектирована и прячет от нас детали реализации. Нам не нужно знать физических законов для ее использования
И так поехали тред про конечные автоматы (fsm, state machines). Одной из ключевых тем в разработке софта касающуюся всех программистов без исключения. Будет много примеров для разных языков. После этого треда вы, вероятно, увидите мир другими глазами. Лайк, шер, алишер, погнали!
Существует заблуждение что автоматы это что-то, из математики, не имеющее отношение к реальной жизни. Их используют в лексическом анализе для написания парсеров. Многие помнят лабы на си, где нужно было разбирать строчку. Да это тоже автоматы, но совсем другие.
Мы же поговорим об автоматах с точки зрения моделирования бизнес-процессов, которые мы программисты по большей части и программируем. Сразу предупрежу, что тема автоматов ну очень глубокая, они бывают совсем разные и к ним нужен разный подход. Поэтому что-то останется за кадром
Про TDD. Я часто пишу тесты до кода, но при этом не работаю по TDD. Почему? Небольшой тред
TDD подразумевает мелкое движение по функциям, которое во многом сфокусировано на внутренних модулях и юнит тестах. Такие тесты быстро приходят в негодность и требуют их постоянного переписывания, что, вообще говоря, мешает разработке, так как нужно постоянно их перерабатывать.
Что еще хуже. Фактически TDD, в таком виде, уводит от главной цели тестирования – максимально дешево убедиться в том что код выполняет свою задачу ради которой он вообще пишется. В итоге программист незаметно для себя начинает думать не о пользователях, а внутренних деталях
Сегодня последний тред из мифов в ООП #oopmyths Поговорим о том, что обычно считают ООП кодом и что влияет на его структуру больше всего. Какие вещи в ООП универсальны сквозь большинство языков. Включайтесь)
Ну и традиционно вопрос. Может ли код быть одновременно объектно-ориентирован и функционален?
Несмотря на любую теорию, на практике, многие программисты если не видят в коде конструкций вида something.do(data), то они не считают код объектно ориентированным. Проверял это много раз. Все это сопровождается философией в стиле "это поведение", а иначе нет.
Начинаем третий про наследование и отношения. Во второй части был опрос про отношения, на который правильно ответило только 29 процентов! И кажется что не все поняли первый тред. #oopmyths
Начнем как обычно с опроса. Вопрос: "Объяснять ООП надо через аналогию с реальным миром". Именно так делается в подавляющем большинстве источников и сервисах типа стековерфлоу.
Строго говоря, отношение частное-общее про типы, а не классы. В статье про сабтайпинг об этом написано внизу: en.wikipedia.org/wiki/Subtyping. И принцип лисков тоже не про классы. Наследование классов это всего лишь способ убрать дублирование кода. Один из худших способов.
Итак) Второй тред посвященный ООП и мифам вокруг него. По итогам первого треда уточню, что разбор ООП идет не с точки зрения систем типов, а с точки зрения организации кода и влиянии на архитектуру. Лайк, шер, будет много интересного, поехали!
Отношение общее-частное это:
В первом треде мы разобрали что под полиморфизмом в ооп понимают полиморфизм подтипов. Остальные виды полиморфизмов тоже важны, но они не играют определяющую роль с точки зрения парадигмы. Полиморфизм подтипов, если по простому, сводится к разным реализациям нужного поведения.
Под типами и подтипами часто понимаются интерфейсы (и их аналоги типа протоколов) и отношения между интерфейсами. Иногда говорят "наследование интерфейсов". Соответственно классы и наследование классов тут не причем. И принципов Лисков не имеет отношения к классам.