Категория: Создание ПО
Просмотров: 13098
    Индустрия программирования никогда не стоит на месте, постоянно предлагая нам что-нибудь новое, что-то что может сделать наши программы более быстрыми, более надежными, более качественными. С одной стороны это хорошо — никогда нельзя упускать случая научиться делать свою работу ещё лучше. С другой стороны люди ошибаются. Они могут ошибиться, пойдя на поводу у нового веяния в программировании, и начать внедрять остромодную парадигму там где это не нужно. Люди так же могут ошибиться в создании самой парадигмы. Помнится в PHP в свое время перлись от глобальных переменных, потом их не рекомендовали применять, а сейчас всячески шельмуют за одно только их упоминание. С другой стороны старые методологии даже среди технологического блеска новых парадигм не теряют своей актуальности.     Индустрия программирования никогда не стоит на месте, постоянно предлагая нам что-нибудь новое, что-то что может сделать наши программы более быстрыми, более надежными, более качественными. С одной стороны это хорошо — никогда нельзя упускать случая научиться делать свою работу ещё лучше. С другой стороны люди ошибаются. Они могут ошибиться, пойдя на поводу у нового веяния в программировании, и начать внедрять остромодную парадигму там где это не нужно. Люди так же могут ошибиться в создании самой парадигмы. Помнится в PHP в свое время перлись от глобальных переменных, потом их не рекомендовали применять, а сейчас всячески шельмуют за одно только их упоминание. С другой стороны старые методологии даже среди технологического блеска новых парадигм не теряют своей актуальности.

    Не потерял своей актуальности и процедурно-ориентированный подход, хотя он и стал меньше использоваться в программировании. В свое время, когда я уже плотно сидел на ООП и достаточно удачно (удачно для решения своих задач) его использовал, я нашел все-таки задачу для которой процедурно-ориентированное программирование оказалось лучшим выбором чем ООП. Это работа с базой данных. В большинстве случаев для операций с БД не нужны классы, более того они идеологически не подходят для этого. Ведь объект это что-то что существует достаточно долго, причем с течением времени изменяет свое состояние. При работе с БД такое бывает редко. Ведь как работает стандартная форма для отображения каких-либо сущностей БД? На счет «раз» форма запускается - в момент запуска считывается массив записей для отображения, эти записи отображаются, и массив тут же удаляется — он больше не нужен. Затем пользователь с умным видом изучает загруженные записи и на счет «два» тыкает мышкой в какую-нибудь запись, желая посмотреть её во всех подробностях. В ответ система запускает диалог для отображения этой записи, дергает функцию загрузки расширенной информации, распихивает информацию о записи по полям диалога и тут же выбранную из БД запись удаляет — она больше не нужна. На счет «три» пользователь изменяет запись и жмет «commit» - в ответ на это система вызывает функцию обновления записи. И все! Все операции слишком редки и несвязаны друг с другом чтобы хранить набор объектов-записей постоянно. ООП здесь выглядит слишком громоздко. Более громоздко выглядит только ООП решение из MFC где нам предлагали перегружать CRecordset и биндить поля этого класса на столбцы таблицы. Использование этого класса я стараюсь избегать т.к. происходит сплавка двух существенно разных понятий «курсор» и «запись». Поэтому при использовании рекордсетов постоянно приходится держать в голове, какой частью дуалистической сущности рекордсета в данный момент я пользуюсь? Курсором? Или записью? А может и тем и другим? Нафиг, нафиг.

    Вместо этого я разработал каскад функций для работы с БД. На самом нижнем уровне была общая функция QUERY( QueryString ), которая выполняла любой произвольный запрос и являлась DB Abstraction Layer'ом нивелируя различия в используемых СУБД (плюс функция логирования запросов так же была возложена на этот слой). На следующем уровне было уже 4 функции CREATE - создание записи, UPDATE — редактирование записи, DELETE — удаление записи, SELECT — выборка записи. Помимо необходимых для функционирования параметров (ну там названия таблиц, списки полей и значений) в эти функции передавались объекты, отвечающие за блокировки таблиц и транзакционное поведение. На третьем уровне были уже API методы для работы с конкретными сущностями БД. Так же на этот слой была возложена функция фильтрации входных параметров и защита от SQLinj. Подобная структура позволяла без проблем писать API методы в 99% случаев, потому что логирование, абстрагирование от используемой БД, транзакции и реакции на ошибки в процессе работы с БД были уже реализованы и оставалось только написать кусочек кода, реализующий решение поставленной задачи. Пожалуй, на всякий случай, напишу открытым текстом — все это было реализовано в виде функций. И заметьте — ни одного класса.