мысли о программировании (тезисно)
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).
- использование «умных указателей» может быть накладным: Smart Pointer Timings. При этом класс «умный указатель» должен переопределить многие операторы (например, operator*(), operator=() и так далее) и тогда простая операция на самом деле будет не такой простой:
- При декларации класса на языке C++ необходимо помнить о правиле «большая тройка».
- При этом не очень подготовленные программисты забывают, что хоть класс состоит из методов и данных, но всё-таки это отдельные сущности и при создании класса память выделяется только для данных.
- как минимум «простые» приложения можно описать используя парадигму конечного автомата (state machine) – есть состояние программы, которое можно узнать проверяя значения переменных через функции и есть переходы от одного состояния в другое, при этом тип состояния можно легко узнать.
- Графический интерфейс пользователя вообще неправильно разрабатывать используя объекты. Есть примитивы (могут быть и свои контролы). Есть состояния этих примитивов и переходы. Но в навороченных приложениях создают такую объектную модель, что два соседних контрола не могут взаимодействовать друг с другом напрямую и всё взаимодействие идёт через уровень логики.
- как вариант, Qt версии 4.6 реализован State Machine Framework.
- Даже временные данные можно хранить в SQLite (надо проверить быстродействие) и тогда доступ к данным может быть осуществлён глобально, нет проблем с многопоточностью так как SQLite потокобезопасен и при этом сериализация может быть достигнута довольно простой операцией сохранения таблицы в файл.
- Исключения ещё хуже чем бездумное выделение памяти – стэк забивают (так как нужно обрабатывать раскрутку исключения), а так же нарушают логику работы.
- Про мультипоточное программирование вообще молчу. Для многих это сложно.
C/C++, Design, dev, Security, State Machine, UI, Unit Testing, UX
