random technical notes

• ООП (и его реализация на С++) хорошо подходит для неоднородной команды, когда надо создавать ограничения на использование данных (объектов), чтобы более слабые программисты не натворили больших бед.
• бездумное использование выделения памяти (операторы new/delete) и умных указателей – показатель не очень хорошей архитектуры. Если в API функции сказано, что надо за собой удалять объект (структуру), так будь любезен не ленись, а то напридумали всякие «помойки памяти» (garbage collection) для ленивых.
  • использование «умных указателей» может быть накладным: Smart Pointer Timings.  При этом класс «умный указатель» должен переопределить многие операторы (например, operator*(), operator=() и так далее) и тогда простая операция на самом деле будет не такой простой:
    smart1->setValue(smart2->getValue());
    При этом всё-таки надо проверять на наличие объекта (if(true == smart1.healthy())), так как возможна ситуация, когда кто-нибудь напишет так: smart1= NULL;
  • уж лучше использовать идею заложенную в IUnknown интерфейсе, когда для подсчёта ссылок используются явно вызываемые методы AddRef() и Release() (конструктор и деструктор у такого класса объявлены защищёнными, что предотвращает неправильный вызов операторов new/delete для этого класса)
  • бездумное объявление виртуальных функций тоже добавляет дополнительные расходы на доступ к методам класса. Смотри презентацию “Virtual Functions“. Для уменьшения накладных расходов, Microsoft даже добавила специальный атрибут при объявлении интерфейсов: __declspec(novtable).
• При декларации класса на языке C++ необходимо помнить о правиле «большая тройка».
  • При этом не очень подготовленные программисты забывают, что хоть класс состоит из методов и данных, но всё-таки это отдельные сущности и при создании класса память выделяется только для данных.
• как минимум «простые» приложения можно описать используя парадигму конечного автомата (state machine) – есть состояние программы, которое можно узнать проверяя значения переменных через функции и есть переходы от одного состояния в другое, при этом тип состояния можно легко узнать.
• Графический интерфейс пользователя вообще неправильно разрабатывать используя объекты. Есть примитивы (могут быть и свои контролы). Есть состояния этих примитивов и переходы. Но в навороченных приложениях создают такую объектную модель, что два соседних контрола не могут взаимодействовать друг с другом напрямую и всё взаимодействие идёт через уровень логики.
  • как вариант, Qt версии 4.6 реализован State Machine Framework.
• Даже временные данные можно хранить в SQLite (надо проверить быстродействие) и тогда доступ к данным может быть осуществлён глобально, нет проблем с многопоточностью так как SQLite потокобезопасен и при этом сериализация может быть достигнута довольно простой операцией сохранения таблицы в файл.
• Исключения ещё хуже чем бездумное выделение памяти – стэк забивают (так как нужно обрабатывать раскрутку исключения), а так же нарушают логику работы.
• Про мультипоточное программирование вообще молчу. Для многих это сложно.

PowerPoint 97-2003 Show (7-zip)