Archive

Posts Tagged ‘State Machine’

мысли о программировании (тезисно)

October 2nd, 2009 No comments
  • ООП (и его реализация на С++) хорошо подходит для неоднородной команды, когда надо создавать ограничения на использование данных (объектов), чтобы более слабые программисты не натворили больших бед.
  • бездумное использование выделения памяти (операторы 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) – есть состояние программы, которое можно узнать проверяя значения переменных через функции и есть переходы от одного состояния в другое, при этом тип состояния можно легко узнать.
  • Графический интерфейс пользователя вообще неправильно разрабатывать используя объекты. Есть примитивы (могут быть и свои контролы). Есть состояния этих примитивов и переходы. Но в навороченных приложениях создают такую объектную модель, что два соседних контрола не могут взаимодействовать друг с другом напрямую и всё взаимодействие идёт через уровень логики.
  • Даже временные данные можно хранить в SQLite (надо проверить быстродействие) и тогда доступ к данным может быть осуществлён глобально, нет проблем с многопоточностью так как SQLite потокобезопасен и при этом сериализация может быть достигнута довольно простой операцией сохранения таблицы в файл.
  • Исключения ещё хуже чем бездумное выделение памяти – стэк забивают (так как нужно обрабатывать раскрутку исключения), а так же нарушают логику работы.
  • Про мультипоточное программирование вообще молчу. Для многих это сложно.

Qt State Machine Overview

September 24th, 2009 No comments