Почему структурное программирование для СПОПО НТУ и нанокомпилятора (САПР НЭ) лучше объектно-ориентированного программирования

Не ввязываясь в «религиозные программистские войны» автор по своему 20-ти летнему опыту программирования может заметить, что при всём своём энтузиазме не обнаружил хоть какого-либо преимущества объектно-ориентированного подхода по сравнению со старым добрым структурным программированием для разработки интерфейса пользователя. Библиотеки классов MFC от Microsoft и более ранние давно забытые библиотеки классов OWL от Borland были интересными исследовательскими проектами, которые долго агрессивно навязывались программистскому сообществу, однако они позволяли делать с ними долго и сложно, то, что можно было делать без них быстро и просто. Более того, объектно-ориентированные возможности научились реализовывать средствами структурного программирования на чистом C в стиле K&R C, без использования штатных объектно-ориентированных средств языка C++. Пример – библиотеки GTK+, которые используются для построения кроссплатформенных переносимых оконных интерфейсов (GNOME) для ОС Linux/UNIX, Microsoft Windows ME/NT/XP/Vista, Mac OS X. Объектно-ориентированный стиль окон и стандартных органов управления на основе виджетов (widget) реализован только на основе функций C. Так много внимания вопросу языка и стиля программирования уделено потому, что исходные тексты (коды) СПОПО НТУ и нанокомпилятора (САПР НЭ) должны быть переносимыми на все популярные платформы – как современные, так и будущие. Для обеспечения кроссплатформенной переносимости необходимо избегать сомнительных платформозависимых технологий типа MFC и держаться общих принципов разработки каркасов приложений, примерно совпадающих в ОС Linux/UNIX, Microsoft Windows ME/NT/XP/Vista, Mac OS X [134—148].

Наконец заметим, что исходные тексты, разработанные в технологии структурного программирования в стиле K&R C, во много раз легче тестировать для выявления и устранения неизбежных ошибок, чем исходные тексты, разработанные на основе объектно-ориентированной технологии C++. Возможность найти и устранить ошибки для исходных текстов (кодов) больших проектов типа САПР, критически важна – от этого завит принципиальная реализуемость проекта. Как правило, все ошибки сводятся к неправильной адресации динамически выделяемой и освобождаемой памяти, иногда из-за неправильно используемых и некорректно преобразуемых типов данных в цепочках логической и арифметической обработки данных и передаче управления от одного программного фрагмента (модуля) к другому. При использовании объектно-ориентированной технологии такие цепочки обработки данных и передачи управления получаются гораздо более запутанными, разветвлёнными и неочевидными, чем при технологии структурного программирования.

Автор отнюдь не является принципиальным противником объектно-ориентрованного программирования (ООП). ООП разрабатывалась как технология для имитационного моделирования больших сложных развивающихся во времени систем [151]. Исходной информацией о таких системах является поведенческое описание отдельных модулей системы и поведенческое описание разрешённого или известного порядка взаимодействия этих модулей друг с другом – их иерархических вертикальных и горизонтальных связей. Для этого используются ключевые понятия ООП – инкапсуляция, наследование, полиморфизм. Результатом имитационного моделирования является выявленное поведение сложной развивающейся во времени системы при изменяющихся входных данных. ООП идеально подходит для описания, моделирования и разработки цифровых схем – в нашем случае схемотехники наносхем. Именно поэтому все современные языки HDL-описания – полностью объектно ориентированные (http://vhdl-manual.narod.ru). Разработка схемотехники СБИС это и есть имитационное моделирование сложной развивающейся во времени системы при изменяющихся входных данных в чистом виде и использование ООП для этого полностью адекватно и единственно возможно. Однако использовать ООП для программной реализации стандартного оконного интерфейса пользователя – это «стрельба из пушки по воробьям». Инструмент должен быть адекватен задаче.

Итак, для построения оконного иерархического интерфейса пользователя в ОС Microsoft Windows ME/NT/2000/XP/Vista достаточно творчески и неформально владеть следующими нехитрыми приёмами. 

· Любое окно создаётся библиотечной функцией CreateWindow (…); или её расширенной модификацией CreateWindowEx (…); [134, 135].

· Классы используемых окон регистрируются библиотечной функцией RegisterClassEx(&WndClassEx); [134, 135]. При регистрации заполняется структура данных «WNDCLASSEX WndClassEx;», в которых указывается ссылки на подключаемые к окну ресурсы (пиктограммы, курсоры, цвет фона) и подключается функция цикла обработки сообщений для этого класса окон.

· Функция цикла обработки сообщений приходящих от данного класса окон строится на основе стандартных операторов множественного выбора «switch (message) {…}» и «case MESSAGE _ X: {…}».

· Диалоговые панели – это тоже окна со своими внутренними циклами обработки сообщений, которые приходят от органов управления, размещённых в этих диалоговых панелях – кнопок, радиокнопок, чекбоксов, счётчиков, ползунков (тракбаров), выпадающих списков, редактируемых полей, листбоксов. 

· Все используемые в API Microsoft Windows  органы управления, представления и ввода/вывода данных – окна предопределённых классов, которые создаются макросами, основанными на функции CreateWindow (…);. Поэтому эта ОС и называется по-американски прямолинейно без метафор: «Windows» – «Окна». Это слово надо понимать не в переносном смысле, а буквально [134, 135]. 

· Всё остальное делается штатными библиотечными функциями в стиле структурного программирования K&R C и их комбинациями.

· Для собственно содержательного дела – вычислений и управления аппаратурой – творчески используется вытесняющая многозадачность – вычислительные процессы и вычислительные потоки (нити и волокна) [134—139]. 

· «Не порождайте сущностей без необходимости» (Козьма Прутков). Принцип регулярной армии: «пусть безобразно, но однообразно», то есть, максимальная унификация разумно малого набора стандартных приёмов позволяет создавать легко тестируемый исходный текст (код) любого необходимого размера.