50x более быстрый код и меньше ошибок? Бросить классы
15 августа 2025 г.Не пройдет день, когда у меня нет разработчика DM, я спрашиваю: «Большой Йода, почему ты так ненавидишь занятия?» Я говорю: «Это легко: производительность и качество, что еще там?»
Спектакль, о котором никто не говорит
Comp Sci 101: Мы одержим со временем и сложностью пространства. Мы спорим о O (n) против O (log n). Мы сравниваем наши петли. Мы агонизируем коэффициенты нагрузки на таблицу хэш. Мы обсуждаем связанные списки против динамических массивов. Мы считаем каждый рекурсивный звонок. Мы оптимизируем наши алгоритмы сортировки. Мы беспокоимся о высоте наших деревьев. Мы рассчитываем точное количество сравнений. Мы минимизируем функциональные вызовы. Мы развертываем петли для этих драгоценных циклов. Мы спорим о хвостовой рекурсии. Мы профиляем каждый метод. Мы устраняем каждое ненужное распределение.
А потом мы разбросаем наши объекты по куче, как мусоровочный грузовик, теряющий свой груз на автостраде в час пик.
Я не знаю, кому это нужно услышать, но каждыйnew MyClass()это еще одна промаха кеша, ожидая, чтобы случиться. Ваш процессор имеет эти красивые линии кэша, 64 байта данных, которые он может захватить одновременно. Так что нам делать? Мы гарантируем, что ни один из наших объектов не находится рядом друг с другом в памяти.
Написать аCustomerкласс сList<Order>где каждыйOrderбылList<LineItem>Полем Следуя данным одного клиента означали преследование указателей по всей куче.
Замените его тремя массивами - клиенты, заказы, линейные предметы - и внезапно тот же алгоритм работает в 50 раз быстрее. Не 50%. ПятьдесятразПолем
Фабрика дефектов: теперь на 30% больше государственной коррупции!
Но производительность - это только закуска. Для основного блюда, вы едете ZE Bugs, которые обслуживают классы.
Каждый класс - это блюдо Петри для коррупции штата. У вас есть десять методов, касающихся пять полей. Быстро: скажите мне все возможные состояния, в которых может быть ваш объект. Вы не можете. Никто не может. Сложность мультипликативна:
- Метод A Устает поле x
- Метод B считывает поле x и устанавливает поле y
- Метод C читает y, но только после того, как A и B запустили
- За исключением иногда C бежит первым из -за резьбы
- Или b получают дважды
- Или кто -то забыл позвонить
С функциями? Вход входит, вывод выходит. Никаких загадок. Нет государства. Нет сюрпризов.
Параллелизм? Все будет хорошо ...
"Просто сделайте это безопасным,-сказали они.-Все будет хорошо »,-сказали они.
Конечно. Позвольте мне просто посыпать немногоsynchronizedКлючевые слова вокруг, как сказочная пыль. Помахай моей волшебной палочкой. Может быть, пожертвуйте козой богам параллелистики, пока я в этом.
Вот грязный секрет: вы не можете сделать государственный класс по-настоящему безопасным. Вы можете сделать отдельные методы безопасными. Нопоследовательностьметодов вызовов? Инварианты между несколькими полями? Удачи.
Я смотрел, как команда проводит шесть месяцев, пытаясь сделать свою доменную модель «безопасной веток». Они добавили замки повсюду. Они создали протоколы заказа блокировки. Они написали обширную документацию о том, какие замки приобрести, когда. У них было больше мутекса, чем тюрьма, имеет двери.
Легенда гласит, что сервер все еще заморожен, ожидая замков, которые никогда не придут.
Вы знаете, что не тупик? Чистые функции, работающие на неизменных данных.
Цель, что насчет-ИЗИМ
«Но Адам, - говорите вы, - как насчет объектов, которые моделируют реальные вещи? А как насчет инкапсуляции? А как насчет шаблонов дизайна?»
Справедливые вопросы. Я построил много систем с этими моделями. Фабрики, посетители, декораторы, весь каталог. У них есть свое место.
Но вот что я заметил: лучшие части этих моделей всегда являются функциональными частями. Худшие части всегда являются государственными частями.
Инкапсуляция? Это скрывает данные. Но чистая функция идеально скрывает свою реализацию - вы буквально не можете получить доступ к его внутренним органам. Наследование? Мы составляем поведение - функции делают это естественно. Полиморфизм? Это просто выбор, какую функцию вызовут.
Паттерны не ошибаютсякак таковойПолем Они просто функционируют в объектно-ориентированном сопротивлении.
Давайте будем разумными
Я не говорю, что никогда не используйте занятия. Если вы моделируете что -то по -настоящему Stateful - ручка файла, сетевое соединение, игровое сущность - прекрасно. Используйте класс. Но сделай это маленьким. Сделать это очевидным. Сделайте явные переходы состояния.
Для всего остального? Используйте функции.
Ваш код будет быстрее. У него будет меньше ошибок. Это будет легче проверить. Это будет легче понять. Это будет легче параллелизировать.
Но самое главное: это будет честно в том, что он делает.
Классы лгут. Они обещают инкапсуляцию, но обеспечивают сложность. Они обещают абстракцию, но обеспечивают запутывание. Они обещают повторное использование, но обеспечивают жесткие иерархии.
Функции говорят правду. Это входит, это выходит. Нет больше, не меньше.
Выберите правду. Выберите функции.
Занятия не являются абстракцией. Они являются признанием неудачи - неспособность найти функции, которые фактически решают вашу проблему.
Оригинал