
- •1. Понятие информационной системы (ис). Корпоративные ис. Структура ис.
- •2. Понятие информационной системы (ис). Корпоративные ис. Классификация ис.
- •3. История развития ис.
- •4. .Net Framework. Общеязыковая среда исполнения (clr). Управляемые модули и сборки.
- •5. .Net Framework. Общая система типов (cts) и Общеязыковая спецификация (cls).
- •6. .Net Framework. Механизм сборки мусора.
- •7. C#. Объявление класса.
- •8. Java. Объявление класса.
- •9. C#. Делегаты.
- •10. C#. События.
- •11. C#. Наследование: правила, синтаксис. Сокрытие имен.
- •12. Java. Наследование: правила, синтаксис. Сокрытие имен.
- •13. Правила наследования типов. Принцип «Open-Closed Principle».
- •14. Правила наследования типов. Принцип «Liskov Substitution Principle».
- •15. C#. Приведение типов. Операторы as и is.
- •16. C#. Виртуальные и невиртуальные методы. Статические методы.
- •17. C#. Абстрактные и конечные методы.
- •310 Часть I. Язык с#
- •18. Java. Абстрактные, виртуальные, конечные и статические методы.
- •19. C# и Java. Интерфейсы.
- •20.C#. Структуры.
- •21. C#. Перечисления.
- •22.C#. Упаковка и распаковка объектов значимых типов.
- •23.C# и Java. Исключения. Механизм исключений.
- •24.C# и Java. Исключения. Классы исключений.
- •25.C# и Java. Исключения. Основные принципы использования механизма
- •26.C#. Обобщения: понятие и синтаксис. Ограничения обобщений.
- •27. Java. Обобщения: понятие и синтаксис.
- •28.C#. Коллекции.
- •29.Java. Коллекции.
- •30.C#. Dispose Pattern.
- •31. .Net Framework 3.0, 3.5, 3.5 sp1: общая характеристика.
- •32. C# 3.0, linq: обзор.
- •Источники данных
- •SqlMetal
- •33. Понятие жизненного цикла ис (жц ис). Каскадная модель жц ис.
- •34. Понятие жизненного цикла ис (жц ис). Спиральная модель жц ис.
- •35. Анализ требований. Функциональные и нефункциональные требования.
- •36 Требования и прецеденты. Формат описания прецедента. Структура прецедента.
- •37 Требования и прецеденты. Взаимосвязь прецедентов.
- •38 Модель предметной области. Концептуальные классы. Ассоциации и атрибуты.
- •39 Язык uml. Способы использования. Model Driven Architecture. Executable uml. ДиаграммыUml.
- •40 Диаграмма прецедентов.
- •41. Диаграмма классов. Обозначение классов. Отношение ассоциации.
- •42.Диаграмма классов. Обозначение интерфейсов. Отношение обобщения и зависимости.
- •43.Диаграмма объектов.
- •44.Диаграмма пакетов.
- •45.Диаграмма состояний.
- •46.Диаграмма развертывания.
- •49.Диаграмма коммуникации.
- •50.Паттерн: понятие, структура, классификация.
- •1) Понятие паттерна
- •2) Структура и Классификация паттернов
- •51. Проектирование на основе обязанностей. Принципы grasp.
- •52.Grasp: принцип Low Coupling.
- •53.Grasp: принцип High Cohesion.
- •54.Grasp: принцип Information Expert.
- •55. Grasp: принцип Creator.
- •56.Grasp: принцип Pure Fabrication.
- •57. Grasp: принцип Indirection.
- •59.Grasp: принцип Protected Variations.
- •60.Grasp: принцип Controller.
17. C#. Абстрактные и конечные методы.
Использование абстрактных классов
Иногда полезно создать базовый класс, определяющий только своего рода "пустой
бланк", который унаследуют все производные классы, причем каждый из них запол-
нит этот "бланк" собственной информацией. Такой класс определяет "суть" методов,
которые производные классы должны реализовать, но сам при этом не обеспечивает
реализации одного или нескольких методов. Подобная ситуация может возникнуть,
когда базовый класс попросту не в состоянии реализовать метод. Этот случай был
проиллюстрирован версией класса TwoDShape (из предыдущей программы), в которой
определение метода агеа() представляло собой "заглушку", поскольку в нем пло-
щадь фигуры не вычислялась и, естественно, не отображалась.
В будущем, создавая собственные библиотеки классов, вы убедитесь, что отсутст-
вие у метода четкого определения в контексте своего (базового) класса, не является
чем-то необычным. Описанную ситуацию можно обработать двумя способами. Один
из них, который продемонстрирован в предыдущем примере, — вывод предупреж-
дающего сообщения. И хотя такой подход может быть полезным в определенных об-
стоятельствах (например, при отладке программы), все же он не соответствует уровню
профессионального программирования. Существует и другой способ. Наша цель —
заставить производные классы переопределить методы, которые в базовом классе не
имеют никакого смысла. Рассмотрим класс Triangle. Им нельзя пользоваться, если
не определен метод area (). Необходимо иметь средство, благодаря которому произ-
водный класс обязательно переопределит все необходимые методы. Этим средством в
С# является абстрактный метод.
Абстрактный метод создается с помощью модификатора типа a b s t r a c t . Абстракт-
ный метод не содержит тела и, следовательно, не реализуется базовым классом. По-
этому производный класс должен его переопределить, поскольку он не может исполь-
зовать версию, предложенную в базовом классе. Нетрудно догадаться, что абстракт-
ный метод автоматически является виртуальным, поэтому и нет необходимости в
использовании модификатора v i r t u a l . Более того, совместное использование моди-
фикаторов v i r t u a l и abstract считается ошибкой.
Для объявления абстрактного метода используйте следующий формат записи.
abstract ТИП ИМЯ(список_параметров) ;
Как видите, тело абстрактного метода отсутствует. Модификатор a b s t r a c t можно
использовать только применительно к обычным, а не к static-методам. Свойства
также могут быть абстрактными.
Класс, содержащий один или несколько абстрактных методов, также должен быть
объявлен как абстрактный с помощью спецификатора abstract, который ставится
перед объявлением class. Поскольку абстрактный класс нереализуем в полном объе-
ме, невозможно создать его экземпляры, или объекты. Таким образом, попытка соз-
дать объект абстрактного класса с помощью оператора new приведет к возникновению
ошибки времени компиляции.
Если производный класс выводится из абстрактного, он может реализовать все аб-
страктные методы базового класса. В противном случае такой производный класс
также должен быть определен как абстрактный. Таким образом, атрибут abstract на-
следуется до тех пор, пока реализация класса не будет полностью достигнута.
Используя абстрактный класс, можно усовершенствовать определение класса
TwoDShape. Поскольку для не определенной заранее двумерной фигуры понятие
площади не имеет смысла, в следующей версии предыдущей программы метод
area () в классе TwoDShape объявляется как абстрактный, как, впрочем, и сам класс
TwoDShape. Безусловно, это означает, что все классы, выведенные из TwoDShape,
должны переопределить метод area ().
// Создание абстрактного класса.
using System;
abstract class TwoDShape {
double pri_width; // Закрытый член,
double pri_height; // Закрытый член,
string pri_name; // Закрытый член.
// Конструктор по умолчанию,
public TwoDShape() {
width = height = 0.0;
name = "null";
}
// Конструктор с параметрами.
public TwoDShape(double w, double h, string n) {
width = w;
height = h;
name = n;
}
// Создаем объект, у которого ширина равна высоте,
public TwoDShape(double x, string n) {
width = height = x;
name = n;
// Создаем объект из объекта,
public TwoDShape(TwoDShape ob) {
width = ob.width;
height = ob.height;
name = ob.name;
}
// Свойства width, height и name,
public double width {
get { return pri_width; }
set { pri_width = value; }
}
public double height {
get { return pri_height; }
set { pri_height = value; }