Как стать автором
Обновить
84.26

ООП *

Объектно-ориентированное программирование

Сначала показывать
Порог рейтинга

Я в прошлом разработчик. Поработал во многих ведущих ИТ-компаниях России. После того, как был разработчиком, работал системным аналитиком, продуктовым менедежром. Лет 12-15 назад начал увлекаться вопросами обучения детей математике. Писал даже года 3 назад на Хабре статью о том, как это мое хобби превратилось в профессию. Теперь это еще и область научных интересов: поступил в аспирантуру на мехмат МГУ на кафедру методики преподавания математики.

В нашем коллективе на мехмате существенная часть внимания сейчас прикована к явленим глубокого структурного изменения взглядов школьника на математику (например, осознание, что от числа можно перейти к переменной, или понимание, что уравнения и неравенства - это одно и то же, с точки зрения логики). У меня на этот счет есть своя теория, которую я частично заимствовал у своего научного руководителя и развил. Теория заключается в том, что задача начальной школы и первой части средней - это осваивать алгоритмы решения различных задач. Т.е. нужно уметь обосновывать каждый шаг алгоритма, но не обязательно уметь находить следующий шаг (достаточно помнить последовательность шагов). К середине средней школы алгоритмов накапливается критическая масса, и школьнику с организацией знаний на основании алгоритмов становится тяжело. Алгоритмы все больше и больше ветвятся, изменяют область своего применения и множатся. И в какой-то момент алгоритмы начинают рваться на шаги, а организация знаний начинает смещаться от алгоритмов к отношениям математических сущностей. Отношения - более оптимальная структура организации знаний. Она отлично работает там, где есть постоянные измнения структуры. Также она оптимальна для организации мышления исследователя. А очень часто дети в началке пропускают обоснование шагов алгоритма и, естественно, имеют проблемы с расчленением алгоритмов на части и формированием математических отношений. И, как следствие, им остается только все продолжать зубрить. Вот пост в моем тг-канале о том, как это прогрессирующее заболевание тянется и меняет представление об обучении.

Пример. Можно воспринимать примеры "2 + 3 = 5", "2 = 5 - 3" и "3 = 5 - 2" по отдельности, тогда знак равно будет знаком дейсвтия. А можно как одно отношение между числами 2, 3 и 5, например, 2 + 3 = 5. А вот тут теперь знак равно имеет смысл тождества.

Развивая теорию, которая могла бы описать такие переходы от алгоритмов к отношениям и которая могла бы быть основной для построения педагогических методик, я вдруг вспомнил, где я это все видел!!!! Функциональное программирование и ООП!!! У каждой из этих двух парадигм есть свои плюсы и минусы. Функциональная хороша для освоения, для быстрого создания чего-то небольшого, для кодирования чего-то большого, когда есть высокая степень определенности, а планируемые изменения не слишком велики. ООП - хорошо, когда планируются структурные изменения. По крайней мере, так было лет 10 назад. А структурные изменения - это именно то, что происходит при изучении математики в средней и старшей школе и далее.

Теги:
+3
Комментарии4

VK (видео)

📦 API for Any(thing) 2

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Библиотека работает на продакшене в приложениях:
Энергия
NFC Tool
КубГТУ

Во второй части доклада практическая реализация 💡

Хабр
Medium
GitHub

El-Machine.com Apps 🤖

Теория:
Часть 1

Теги:
Рейтинг0
Комментарии0

Доклад Особенности фреймворка $mol (+ слайды) с PiterJS #72.

О фичах $mol, которых нет в других фреймворках, и о том, зачем они нужны.

Автор - Станислав Яременко. Герой Hyper Dev, Синьор $mol-разработчик.

Писал на Vue, Svelte. Пробовал и другие фреймворки. Как-то раз я загуглил "лучший ui фреймворк", и на первом месте в выдаче оказался $mol. Конечно, я не поверил и начал разбираться...

Теги:
Всего голосов 12: ↑5 и ↓70
Комментарии14

YouTube (видео)

📦 API for Any(thing) 

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model

Хабр
Medium
GitHub

Первая часть доклада теоретическая. В поисках API для любого (Any) объекта

Во второй части доклада практическая реализация 💡

Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект

Часть 2

Теги:
Рейтинг0
Комментарии0

Я вот не понимаю, почему Го преподносится как  post-OOP язык, в то время как это явно пре-ООП язык, чисто императивный. Как Бейсик (который не Вижуал) или Паскаль.

И это явно не прогресс, а регресс в подходе к методологии.

Хотя, очевидно, он выигрывает у языков с управляемой средой, да. Управляемая среда (ВМ) требует слишком много ресурсов для старта и разогрева. А в микросервисах это вообще не нужно.

Теги:
Всего голосов 8: ↑4 и ↓4+2
Комментарии44

Реализация перераспределения целей (retarget) в играх RTS жанра

Учитывая предыдущую критику, что удобнее читать статьи, а не слушать видео, попробую вначале сделать акцент на тему, вынесенную в заголовок. Дело в том, что в статье концентрация информации больше, но широкий контекст обсуждения вопроса, остается за кадром. Поэтому для узконаправленной подачи информации собираюсь написать статью, а для более широкого понимания вопроса предлагаю ознакомится с представленным видео.

Задача выбора целей для атакующих NPC

В играх RTS жанра обязательно возникает задача, как выбрать для NPC цель. Мы хорошо знаем, когда игроки на их жаргоне говорят "заагрился", что означает, что некий юнит, обратил внимание на юнитов игрока, и будет их преследовать и атаковать. В ряде игр от заагрившегося юнита можно убежать, в других наоборот, он будет вас выслеживать "по запаху, остаткам крови", как это реализовано в JA3. Но как усложнится задача, когда агрессивных NPC в игре сотни, и у игрока аналогично их сотни, или тысячи. Можно ли раз и навсегда заагрится на какого то конкретного юнита? По какому принципу перераспределять цели между разными NPC? Все это не тривиальные задачи, но они имеют одно достаточно простое решение на базе алгоритма искусственного интеллекта, который своими корнями восходит к алгоритму градиентного спуска.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Global variable is not a field!

Глобальная переменная - это не поле для наследования ООП. Эта мысль посетила меня слишком поздно, поймите мою боль.
Я создал глобальную переменную, точнее даже глобальную переменную с локальной областью видимости (static). Эта переменная жила в методе. Я ожидал, что у каждого экземпляра класса будет свой метод (что верно) со своим экземпляром переменной (неверно).

void TClass::method(){
    static QByteArray globalVar; //will the same for all objects
}

Учите ООП, голубцы!

Всего голосов 8: ↑3 и ↓5-2
Комментарии5

Вклад авторов