Your SlideShare is downloading. ×
0
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
OO Design with C++: 0. Intro
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

OO Design with C++: 0. Intro

461

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
461
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Курс лекций по C++ : введение Дмитрий Штилерман, Рексофт
  • 2.
    • Чему можно научить тех, кто сам завтра станет неактуальным старпером?
    • Модест Колеров «О сокращении пребывания в настоящем»
  • 3. Тенденция: сравнительные затраты на HW/SW 100 80 60 40 20 0 1955 1970 1985 Hardware Software И сследование US Air Force, цит. по “Software Economics”, Barry Boehm, Software Pioneers Conference, June 29, 2001
  • 4. Минимизация стоимости разработки: стратегии
    • Минимизация размера продукта ( economy of scale)
      • Языки и технологии
      • Методы проектирования и в изуальное моделирование
      • Повторное использование (reuse) и компоненты
      • Архитектурные решения
    • Оптимизация процессов
    • Увеличение эффективности команды
    • Автоматизация (development environments)
    • Walker Royce, “Software Project Management: A Unified Framework”
  • 5. Минимизация стоимости разработки: требования к ЯП
    • Полнота/мощность (решение любых задач)
    • Легкость обучения (learning curve)
    • Поддержка современных методов проектирования (на уровне концепций)
    • Поддержка повторного использования
      • Разделяемый исходный код ( copy-paste )
      • Библиотеки
      • Компоненты
    • Легкость автоматизации и создания сред разработки
  • 6. Основные классы ПО
    • Клиентское ПО: пользовательский интерфейс, бизнес-логика
    • Серверное ПО: бизнес-логика, хранение данных
    • Системное ПО: управление на низком уровне
    • Встроенное (embedded) ПО : сродни системному, но в условиях ограничений по ресурсам и производительности
  • 7. Основные классы ПО: п риоритетные требования
    • Клиентское ПО
      • Скорость разработки
      • Гибкость
      • Производительность
    • Серверное ПО
      • Скорость разработки
      • Надежность
      • Гибкость
    • Системное ПО
      • Надежность
      • Производительность
      • Гибкость
    • Встроенное ПО
      • Производительность
      • Надежность
      • Гибкость
  • 8. Основные классы ПО: требования к языкам и технологиям
    • Скорость разработки
      • Простота
      • Reuse
      • Автоматизация
    • Гибкость
      • Функциональная полнота
      • Концептуальная полнота
    • Производительность
      • Компиляция
      • Оптимизация
      • Низкоуровневые средства
    • Надежность
      • Зрелость
      • Стандартизация
  • 9. Сильные и слабые стороны C++
    • Сильные стороны
    • Гибкость
      • Функционально богат
      • Хорошо поддерживает любые стили дизайна
    • Производительность
      • Компилируемый язык
      • Низкоуровневая семантика
      • Минимальные накладные расходы
    • Слабые стороны
    • Скорость разработки
      • Сложен для изучения (высокий входной порог)
      • Reuse затруднен, т.к. невозможно основать к омпонентную модель прямо на средствах языка
      • Автоматизация затруднена (сверх уровня code browsers)
  • 10. Предпосылки слабых сторон C++
    • Низкоуровневая семантика
    • Отсутствие поддержки метаинформации (RTTI не в счет)
    • Чрезмерное разнообразие способов решения той или иной проблемы
  • 11. Слабые стороны C++ : низкоуровневая семантика (1) Корень зла - доступ к физической памяти и свобода смешивания указателей и целых ! (int)pObject a.k.a. reinterpret_cast<int>(pObject)
  • 12. Слабые стороны C++ : низкоуровневая семантика (2)
    • SomeObject* p = new SomeObject;
    • // Создали объект в куче
    • long n1 = long(p) & 0x0000FFFFUL;
    • long n2 = long(p) & 0xFFFF0000UL;
    • p = 0;
    • // Теперь ни один указатель не
    • // ссылается на выделенную память!
    • // Сборщик мусора мог бы удалить объект.
    • p = (SomeObject*) (n1 | n2);
    • // Опаньки!
    Пример проблемы: невозможность создания полноценного сборщика мусора
  • 13. Слабые стороны C++ : отсутствие метаинформации
    • Метаинформация - информация о свойствах конструкций языка, доступная в самом языке.
    • Пример: по указателю на объект получить все методы класса данного объекта
    • Что нельзя/трудно реализовать без метаинформации?
      • Инструментальные средства
      • Компонентные архитектуры
      • Сериализация объектов и объектные БД
      • Передача объектов по значению
      • Средства обеспечения безопасности
  • 14. Ответ Java на слабые стороны C++
    • Невозможность опасных низкоуровневых манипуляций - ссылку на объект ни во что непристойное не преобразуешь и с физической памя т ью напрямую не поработаешь.
    • Java Reflection API - богатейшая поддержка метаинформации, являющаяся частью стандартной библиотеки.
  • 15. Reuse и уровни совместимости реализаций
    • Разделяемый исходный код
      • Уровень совместимости: исходный код
      • Объект стандартизации: синтаксис/семантика
    • Разделяемый объектный код: библиотеки
      • Уровень совместимости: объектный код
      • Объект стандартизации: Application Binary Interface (ABI)
    • Компоненты
      • Уровень совместимости: компонентная архитектура
      • Объект стандартизации: протоколы управления компонентами
  • 16. Примеры уровней совместимости: ANSI C
    • Исходный код
      • Официальный стандарт языка и библиотеки
    • ABI
      • Стандартизован в пределах практически каждой основной платформы (формат объектного файла, работа линкера etc.)
    • Компонентные архитектуры
      • COM: можно и на C...
      • CORBA: стандартное отображение (IDL to C mapping)
  • 17. Примеры уровней совместимости: ANSI/ISO C++
    • Исходный код
      • Официальный стандарт языка и библиотеки (наконец-то...)
    • ABI
      • Отсутствие стандартного ABI
      • Работа в пределах C ABI с помощью name mangling
    • Компонентные архитектуры
      • COM: почти родной
      • CORBA: стандартное отображение (IDL to C++ mapping)
  • 18. Примеры уровней совместимости: Java
    • Исходный код
      • Общепринятый стабильный стандарт языка (элементы официальности в виде JCP)
      • Эволюционирующий стандарт библиотеки (версии JDK 1.0  1.1  1.1.8  1.2.2  …)
    • ABI
      • Общепринятый стабильный стандарт ABI (JVM, class file)
    • Компонентные архитектуры
      • Специфичные для языка: JavaBeans, J2EE
      • CORBA: стандартное отображение (IDL to Java mapping) , CORBA и J2EE - близнецы-братья
  • 19. Компонентные модели: два уровня
    • 1. « Доступ »
    • Уровень объекта
    • Как получить указатель на объект и вызвать метод?
    • Как предоставить клиентам доступ к объекту?
    • COM, RMI, CORBA
    • 2. « Упаковка »
    • Уровень компонента
    • Как упаковать объекты в компонент?
    • Как добавить компонент в систему?
    • ActiveX, JavaBeans, J2EE, CORBABeans
  • 20. Основные классы ПО: сравнительная адекватность ЯП Highly subjective
  • 21. The End

×