- •2 Выделение объектов проблемной области: объектно-ориентированная модель задачи, информационная и математическая модели объектов Пример. Представление доски в аудитории в виде объекта
- •Выводы:
- •3 Концептуальная модель класса объектов
- •4 Инкапсуляция атрибутов и методов в классе объектов Понятие инкапсуляции
- •Инкапсуляция в концептуальной модели ооп
- •Реализация членов-функций
- •Указатель this: назначение и использование
- •Проблема защиты членов-данных класса
- •Защита на уровне уровня доступа
- •Защита на уровне значений
- •10 Защита членов-данных, заданных указателями и ссылками
- •11 Защита членов-данных объекта, передаваемого в качестве параметра функции или возвращаемого функцией
- •Реализация и семантика (смысл) чдодвоКов
- •2.11.2 Инициализация чдодвоКов
- •14 ??? Использование членов класса, общих для всех объектов класса, для учета и идентификации объектов класса.
- •15 ??? Использование членов класса, общих для всех объектов класса, для обеспечения тестирования и отладки оо программ
- •2.12.1 Свойства ctorов, предназначенные для реализации модели ооп
- •Автоматический вызов ctorа
- •18 ??? Создание объектов прямым заданием значений членов-данных
- •19 ??? Создание объектов копированием и преобразованием
- •20 ??? Создание объектов класса, использующего объекты других классов в качестве членов-данных
- •22 Проектирование класса по контракту
- •23 Отношение наследования в концептуальной модели ооп.
- •25 Управление доступом в производном классе к членам базового класса
- •27,28 Создание объектов производного класса и задание их начальных состояний
- •29 Назначение виртуальных функций
- •Назначение вф
- •30 Задание виртуальных функций
- •31 Вызов виртуальных функций.
- •32 Виртуальные деструкторы
- •33 Организация вычислений в концептуальной модели ооп
- •Преимущества и недостатки множественного наследования
- •38 Понятие "полиморфизм" в модели ооп. Виды полиморфизма
- •Виды полиморфизма
27,28 Создание объектов производного класса и задание их начальных состояний
1) Основные вопросы, на которые требуется получить ответы:
а) Нужны ли конструкторы пк?
б) Если они нужны, то каково их назначение?
в) Должен ли программист определять ctor производного класса?
г) Как связаны между собой ctorы пк и бк?
д) Сколько ctorов пк можно сделать? И чем это определяется?
е) Зависит ли число ctorов пк от числа ctorов бк?
ж) Может ли ctor пк инициализировать подобъект бк, и если да, то как?
2) Создание объектов пк осуществляется ctorами пк.
3) ctor пк должен создать объект пк, и задать значения членов-данных пк.
4) ctor пк должен создать подобъект бк, входящий в состав объекта пк, и задать его начальное состояние.
5) Язык C++, в общем случае, не требует от программиста создания конструктора пк.
6) Если программист не определил свой конструктор пк, язык предоставляет по умолчанию свой конструктор, который только выделяет память и наделяет ее правилами системы типов.
7) В связи с этим вопросы:
а) Какой будет (и будет ли?) вызван конструктор бк, если конструктор пк предоставлен компилятором по умолчанию?
б) Если программист решил определить один или несколько конструкторов пк, сколь-ко он может их определить?
в) Как должны быть связаны конструкторы пк с имеющимися в бк?
8) Рассмотрим связь конструкторов пк и бк на типовых примерах.
9) Ситуации, в которых программист должен определить конструктор или конструкторы пк, определяются следующими факторами:
а) необходимость инициализации объекта пк — в концепции ООП это абсолютная необходимость;
б) структура пк;
в) свойства конструкторов бк.
10) Источником ситуаций могут быть свойства конструкторов бк:
а) бк не имеет собственных конструкторов, определенных программистом — это прямое нарушение концепции ООП;
б) бк имеет конструкторы, которые могут быть вызваны без параметров;
в) бк имеет конструкторы, которые не могут быть вызваны без параметров.
11) Ситуация 1. бк не имеет конструкторов, определенных программистом, пк — тоже. В пк нет собственных членов-данных. Пример:
class Point {
double x;
double y;
public:
void setXY( double newX, double newY );
void getXY( double ¤tX, double ¤tY );
};
// прыгающая точка
class JumpingPoint: public Point {
public:
void jumpToPoint( const Point &destination );
};
Вывод: JumpingPoint можно использовать только при условии корректного использования объекта destination класса Point. Пример гадкий. Никогда так не делайте — данные должны быть инициализированы. А то точка может прыгнуть в неизвестно ку-да, если destination не имеет состояния в момент вызова ф-ции jumpToPoint(). Задача: путем совершенствования класса JumpingPoint обеспечить корректное исполь-зование объектов этого класса. Решение: удовлетворительное решение невозможно. Требуется совершенствовать класс Point.
12) Ситуация 2. бк имеет конструктор, определенный программистом, который может быть вызван без параметров. пк не имеет конструктора, определенного программистом. пк не имеет собственных членов-данных.
В ситуации 1 добавим ctor в класс Point:
Point( double newX = 1.0, double newY = 2.0 ) : x( newX ), y( newY ) { }
Вывод: созданный объект бк всегда имеет состояние, но оно может не удовлетворять требованиям контекста содержания или применения.
13) Ситуация 3. бк имеет конструктор, определенный программистом, с параметрами, ко-торый не может быть вызван без параметров. пк не имеет конструктора, определенно-го программистом.
В ситуации 1 добавим ctor в класс Point:
Point( double newX, double newY ) : x( newX ), y( newY ) { }
Тогда при компиляции класса JumpingPoint возникнет ошибка. Конструктор, предос-тавляемый компилятором по умолчанию, не сможет найти конструктор бк, который может быть вызван без параметров. А параметры для конструктора, который не может быть вызван без параметров, компилятору неоткуда взять.
Вывод: конструктор пк в этом случае должен вызывать существущий конструктор бк и передать ему необходимые параметры. Конструктор пк должен быть реализован про-граммистом. Например: JumpingPoint( double newX, double newY ) : Point( newX, newY ) { }
Рекомендация: для пк всегда разрабатывать конструктор или конструкторы со списком инициализации. Их должно быть, как минимум, не меньше, чем конструкторов базового класса (и они должны иметь те же сигнатуры). Иначе мы рискуем не предусмотреть в пк те ситуации использования, которые были допустимы для объектов базового класса.
14) Ситуация 4. бк имеет конструкторы, все из которых не могут быть вызваны без пара-метров. пк не имеет собственных членов-данных.
Вывод: если в пк предполагается использовать возможности всех конструкторов бк, то необходимо разработать в пк конструкторы, каждый из которых соответствует конструктору бк и обеспечивает передачу конструктору бк требуемого им набора параметров.