Подчеркнутая защищенность

Инкапсуляция - одна из основ ООП. Мы договариваемся использовать только часть функциональности класса, а взамен получаем возможность работать с самыми разными типами, даже с теми, которые будут написаны после окончания работы над текущим кодом.

Компилируемые языки реализуют инкапсуляцию методом принуждения. Программист отмечает методы и поля как личные или защищенные, а компилятор играет в большого брата и проверяет что все используется в корректном контексте. На моей памяти война за способ использования private/protected минимум пару раз принимала нешуточный оборот.

Попадая в питон С++/Java-программисты начинают искать замену родным private/protected в этом мире безудержного эксгибиционизма. И, как правило, быстро находят два подчеркивания. Не совсем то, что хотелось бы, но довольно сильно похоже на private. В итоге нижнее подчеркивание быстро становится самым популярным символом в коде.

Я попробую показать, что:

• '__' - не эквивалент private и решает совсем другие задачи;
• Можно отлично жить без private/protected/friend. Оружие массового запрещения не единственный способ реализовать инкапсуляцию;
• При желании можно написать аналог private/protected и даже более гибкий контроль доступа для python (в следующем посте)

Функциональный стиль в питоне

Пост чисто философский

Периодическое чтение кусков кода, написанных при обострении хаскеля головного мозга, выработало у меня четкую ассоциацию: функциональный стиль - это нечитаемо. Точнее стиль с множеством map/filter/zip. Вот немного облагороженный пример такого кода (автор считает, что с кодом все ок):

Контейнеры внедрения зависимостей для python

Начнем издалека - создание объекта инстанцированием класса плохо совместимо с идеями ООП. Они гласят, что код должен зависеть от интерфейсов, а не от реализаций. До тех пор пока на вход нашему коду приходят готовые объекты - все хорошо. Он будет с готовностью принимать любые типы, реализующие требуемый интерфейс, но как только мы начинаем создавать новые объекты ситуация меняется. Теперь код зависит от конкретного класса, что усложняет следующие задачи:

• Изменение класса на другой, хоть и реализующий тот же интерфейс. Приходится вручную менять все точки инстанцирования, и, возможно, перекомпилировать код;
• Выбор конкретного класса на основе внешних условий или точки инстанцирования;
• Использование уже готового объекта - взятого из пула или какого то конкретного (синглетон);
• Построение объекта с большим количеством зависимостей - приходиться передавать в точку конструирования все данные для построения множества взаимосвязанных объектов;
• Не классическая проблема для ICC, но из той-же области:

Python, processor affinity или как существенно ускорить некоторые программы, ничего не делая

Всем, кто увидел первую версию поста - цифры были кривые из-за turbo boost

Возьмем простой пример tcp клиента и сервера на python. Сервер создает пул из N потоков и ждет соединений с клиентом. Получив соединение передает его на обработку в пул. На каждом соединении сервер ждет от клиента строку данных и имитирует некую обработку. При получении 'bye\n' сервер завершает обработку клиента.

Клиент открывает N соединений с сервером и генерирует на них нагрузку. Общий объем нагрузки за один запуск клиента фиксирован.