Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методичка для КР по ООП.doc
Скачиваний:
8
Добавлен:
18.04.2019
Размер:
2.47 Mб
Скачать

Кто строит конструктор умолчания

Конструктор умолчания (конструктор с пустым списком параметров) строится транслятором по умолчанию. Если класс не содержит явных объявлений конструкторов, именно этот конструктор берёт на себя работу по превращению области памяти в объект.

Class X

{

}

::::::::::

X x = new X(); // Работает конструктор умолчания.

Однако попытка объявления ЛЮБОГО варианта конструктора (с параметрами или без) приводит к тому, что транслятор перестаёт заниматься построением собственных версий конструкторов. Отныне в классе нет больше конструктора умолчания. Теперь всё зависит от соответствия оператора определения объекта построенному нами конструктору. Объявим в производном классе оба варианта конструкторов.

Class X

{

public X(int key){}

}

::::::::::

X x0 = new X(125); // Работает конструктор с параметрами.

X x1 = new X(); // Не дело! Конструктора умолчания уже нет!

Однажды взявшись за дело объявления конструкторов, разработчик класса должен брать на себя ответственность за создание ВСЕХ без исключения версий конструкторов. Таковы правила.

Class X

{

public X(int key){}

public X(){}

}

::::::::::

X x0 = new X(125); // Работает конструктор с параметрами.

X x1 = new X(); // Работает новый конструктор без параметров.

This в контексте конструктора

Конструктор не вызывается. Передача управления конструктору осуществляется при выполнении операции new.

Ситуация: сложная структура класс. Различные варианты конструкторов, специализирующиеся на создании и инициализации различных вариантов объектов вынуждены выполнять общий список регламентных работ по инициализации объектов.

Оставить ОДИН конструктор, выполняющий ВСЮ “черновую” работу по созданию объектов. “Тонкую” настройку объектов производить после выполнения кода конструктора, непосредственно вызывая соответствующие методы-члены. При этом вызываются методы именно ПОСЛЕ того, как отработает конструктор.

Определить множество специализированных конструкторов, после выполнения которых вызывать дополнительный метод инициализации для общей “доводки” объекта.

Некрасиво. Код получается сложный.

В C# реализован другой подход, который состоит в следующем:

Определяется множество разнообразных специализированных конструкторов.

Выделяется наименее специализированный конструктор, которому поручается выполнение обязательной работы.

Обеспечивается передача управления из конструктора конструктору.

Так вот this в контексте конструктора обеспечивает в C# передачу управления от конструктора к конструктору. Таким образом, программист освобождается от необходимости повторного кодирования алгоритмов инициализации для каждого из вариантов конструктора.

Следующий фрагмент программного кода демонстрирует объявление нескольких конструкторов с передачей управления “золушке”.

class Point2D

{

private float x, y;

public Point2D(float xKey, float yKey)

{

Console.WriteLine(“Point2D({0}, {1}) is here!”, xKey, yKey);

// Какой - нибудь сложный обязательный

// код инициализации данных-членов класса.

int i = 0;

while (i < 100)

{

x = xKey;

y = yKey;

i++;

}

}

// А все другие конструкторы в обязательном порядке предполагают

// регламентные работы по инициализации значений объекта - и делают при этом

// ещё много чего...

public Point2D():this(0,0)

{

int i;

for (i = 0; i < 100; i++)

{

// Хорошо, что значения уже проинициализированы!

// Здесь своих проблем хватает.

}

Console.WriteLine(“Point2D() is here!”);

}

public Point2D(Point2D pKey):this(pKey.x, pKey.y)

{

int i;

for (i = 0; i < 100; i++)

{

// Хорошо, что значения уже проинициализированы!

// Здесь своих проблем хватает.

}

Console.WriteLine(“Point2D({0}) is here!”, pKey.ToString());

}

}