- •Раздел 4. Разработка по Тема 4.1. Проектирование интерфейса с пользователем
- •4.1.1. Типы пользовательских интерфейсов.
- •4.1.2. Пользовательская и программная модели интерфейса.
- •4.1.3. Разработка диалогов.
- •4.1.4. Основные компоненты графических пользовательских интерфейсов.
- •Тема 4.2. Реализация графических пользовательских интерфейсов.
- •4.2.1. Диалоги, управляемые пользователем.
- •4.2.2. Диалоги, управляемые системой.
- •4.2.3. Использование метафор.
- •4.2.4. Технология Drag and Drop.
- •4.2.5. Интеллектуальные элементы.
- •4.3.1. Базовые типы данных.
- •Константы
- •Область действия имен
- •4.3.2. Указатели и адресная арифметика.
- •4.3.3. Составные типы данных. Структуры
- •Битовые поля
- •Определение типов
- •Перечислимые типы
- •4.3.4. Выражения и операции.
- •4.3.5. Управляющие конструкции. Условные операторы
- •Операторы циклов
- •4.4.1. Статические одномерные массивы.
- •4.4.2. Статические многомерные массивы.
- •4.4.3. Динамические массивы.
- •4.4.4. Массивы указателей.
- •4.5.1. Стеки.
- •4.5.2. Очереди.
- •4.5.3. Списки.
- •4.5.4. Бинарные деревья.
- •4.6.1. Объявление классов и экземпляров классов.
- •4.6.2. Инкапсуляция данных и методов.
- •4.6.3. Конструкторы классов.
- •Конструктор по умолчанию
- •Конструктор копирования
- •4.6.4. Деструкторы классов.
- •4.7.1. Разделы в описании класса.
- •4.7.2. Friend-конструкции.
- •4.7.3. Статические члены классов.
- •4.7.4. Использование описателя const в классах.
- •4.8.1. Вложенность классов.
- •4.8.2. Наследование данных и методов.
- •4.8.3. Типы наследования.
- •4.9.1. Полиморфизм раннего связывания.
- •4.9.2. Полиморфизм позднего связывания и виртуальные функции.
- •4.9.3. Абстрактные методы и классы.
- •4.10.1. Функции консольного ввода-вывода.
- •4.10.2. Функции файлового ввода-вывода.
- •4.10.3. Использование библиотеки классов потокового ввода-вывода.
- •4.11.1. Перегрузка операций.
- •4.11.2. Шаблоны функций.
- •4.11.3. Шаблоны классов.
- •4.11.4. Обработка исключений.
- •Тема 4.12. Com-технология.
- •4.12.1. Основные понятия.
- •4.12.2. Типы интерфейсов.
- •Свойства интерфейсов
- •Типы интерфейсов
- •4.12.3. Типы com-объектов.
- •4.12.4. Фабрика классов.
- •Тема 4.13. Построение com-сервера.
- •4.13.1. Язык idl.
- •Содержимое файла idl
- •4.13.2. Определение пользовательского интерфейса.
- •4.13.3. Реализация пользовательского интерфейса.
- •4.13.4. Создание тестового клиента.
- •Тема 4.14. Обзор платформы ms .Net.
- •4.14.1. Общая идея архитектуры .Net.
- •4.14.2. Достоинства и недостатки .Net.
- •4.14.3. Схема трансляции программ в .Net.
- •4.14.4. Язык msil.
- •4.14.5. Объектно-ориентированная модель .Net.
4.14.2. Достоинства и недостатки .Net.
Объектно-ориентированное программирование
Старый Windows API был написан на С и, следовательно, является полностью процедурным.
Это означает, что API состоит буквально из тысяч функций. Напротив, .NET и С# полностью основаны на принципах ООП. В частности, библиотека .NET является библиотекой классов, а не функций. Можно создавать экземпляры этих классов и во многих случаях производить наследование классов, а также вызывать их общие методы. Это позволяет создавать интуитивно понятный, хорошо структурированный и более надежный клиентский код, что невозможно сделать с помощью Windows API.
Хороший дизайн
Мнение о том, что является хорошим дизайном, субъективно, однако Microsoft в течение долгого времени обсуждала с разработчиками самые разные вопросы по поводу .NET и извлекла уроки из ошибок прошлого. В результате появилась библиотека базовых классов, которая разработана с чистого листа и сделана интуитивно понятной. В подавляющем большинстве случаев достаточно всего лишь взглянуть на определение метода, чтобы понять, что он делает и как его использовать. Безусловно, такого нельзя сказать о Windows API, функции которого не всегда понятны и зачастую требуют передачи параметров, которые необходимы для запутанной внутренней работы API или обеспечения обратной совместимости, а не для выполнения цели данной функции.
Языковая независимость
Хотя раньше СОМ-компоненты могли общаться друг с другом независимо от того, на каком языке они написаны, все же существовала большая пропасть между Visual Basic, Visual J++ и Visual C++. Типы данных различались, и создание СОМ-объекта, который должен быть доступен из других языков, означало наложение жестких ограничений на сигнатуры его методов, часто за счет ограничения производительности. И, конечно же, невозможно было смешивать различные языки а одном и том же блоке кода.
Теперь все изменилось. С применением платформы .NET любой язык, включая VB.NET, С# и управляемый C++, может компилироваться в общий промежуточный язык. Это означает, что языки совместимы на совершенно новом уровне. Например, в отладчике можно перешагивать с кода C++ прямо на код С#, а затем на код VB.NET без каких-либо проблем. Более того, все языки используют теперь общую среду разработки.
Важно понимать, что языковая независимость была достигнута не за счет приведения всех языков к наименьшему общему кратному по части функциональности,
Напротив, Microsoft осуществила этот переход путем добавления в каждый язык тех свойств, которые превосходно показали себя в других языках. VB.NET теперь содержит классы и наследование, ранее являвшиеся прерогативой C++. Если для программирования используется C++, то среда разработки поддерживает элементы управления drag-and-drop точно так же, как это было реализовано в VB. Тем не менее некоторые особенности языка C++, такие как множественное наследование и шаблоны, не поддерживаются в .NET и, следовательно, не могут использоваться в управляемом коде.
Отказ от применения DLL
Когда было объявлено о создании DLL (dynamic linked libraries), это было большим достижением по части экономии дискового пространства и памяти и позволяло различным процессам совместно использовать один и тот же код. Однако по мере работы с DLL стало понятно, что их применение приводит к появлению ряда проблем, в основном из-за отсутствия какой-либо формальной системы контроля над версиями и из-за того, что более новая версия DLL, как правило, затирает собой предыдущую версию.
Проблема в большинстве случаев заключается в том, что некоторое программное обеспечение перезаписывает разделяемую DLL новой версией. Обновленная версия оказывается не полностью совместимой с предыдущей, в результате чего обнаруживается, что некоторые программы, использующие ту же DLL, больше не работают на данной машине. Такие ошибки трудно отыскать. Платформа .NET лишена этого недостатка. .NET полностью изменила способ, с помощью которого код совместно используется приложениями, введя концепцию сборки (assembly), заменившей традиционную DLL. Сборки имеют встроенные средства контроля версий, а разные версии сборок могут сосуществовать одновременно.
Улучшенная безопасность
От того, как разработаны сборки, зависит безопасность системы. Каждая сборка может содержать встроенную информацию о безопасности, которая четко указывает, какой пользователь, группа пользователей или процесс может вызывать определенные методы того или иного класса. Это позволяет управлять использованием создаваемых сборок.
Простая установка (Zero Impact Installation)
Начиная с Windows 95, СОМ-объекты должны регистрироваться в реестре. Эта практика является хорошей в плане обеспечения централизованной информации о том, какие программы установлены в системе. Однако в результате использования системой СОМ-объектов библиотек типов появляются дополнительные проблемы из-за того, что информация о приложении хранится в разных местах. Например, код, который представляет собой компонент, может находиться в файле ЕХЕ или DLL, описания методов и интерфейсов будут храниться где-то еще в библиотеке типов, a GUID и т.п. будут описаны в реестре.
Разброс информации может привести к ее рассинхронизации. Многим разработчикам СОМ-компонентов в определенный момент приходилось заниматься поиском и исправлением несоответствий, возникающих в реестре. С .NET это перестает быть проблемой, так как сборки полностью описывают себя в этом плане.
В то же время различные эффективные и сложные алгоритмы хэширования обеспечивают во время выполнения проверку того, что сборка не была модифицирована. Можно также различать общие сборки, доступные для других приложений, и частные сборки, которые могут использоваться только тем приложением, которое их установило. Это решает еще одну проблему СОМ — проблему того, что реестр постепенно забивается информацией о тысячах компонентов, которые на самом деле не предназначены для совместного использования.
Поддержка web-служб
Web-службы, по мнению многих людей из ИТ-индустрии, являются тем, что будет иметь большое значение в течение следующих нескольких лет. Идея состоит в том, что различные методы объекта могут быть вызваны по Интернету при помощи стандартных web-протоколов. Это придает новый смысл технологии распределенных приложений: различные компании смогут предоставлять такие услуги, как прогнозы погоды, состояния счетов и проверки кредитных карт, с помощью этих методов, а клиенты смогут вызывать их по Интернету с помощью собственного программного обеспечения. Вплоть до настоящего времени Microsoft обеспечивала ограниченную поддержку web-служб посредством инструментария SOAP. .NET имеет полностью встроенную поддержку разработки web-служб, и создавать их теперь так же легко, как и любые другие типы приложений.