Что представляют классы?




По сути в системе бывают классы двух видов:[1] классы, которые прямо отражают понятия области приложения, т.е. понятия, которые использует конечный пользователь для описания своих задач и возможных решений; и[2] классы, которые являются продуктом самой реализации, т.е. отражают понятия, используемые разработчиками и программистами для описания способов реализации.Некоторые из классов, являющихся продуктами реализации, могутпредставлять и понятия реального мира. Например, программные иаппаратные ресурсы системы являются хорошими кандидатамина роль классов, представляющих область приложения. Это отражаеттот факт, что систему можно рассматривать с нескольких точекзрения, и то, что с одной является деталью реализации, сдругой может быть понятием области приложения. Хорошоспроектированная система должна содержать классы, которыедают возможность рассматривать систему с логическиразных точек зрения. Приведем пример: [1] классы, представляющие пользовательские понятия (например, легковые машины и грузовики), [2] классы, представляющие обобщения пользовательских понятий (движущиеся средства), [3] классы, представляющие аппаратные ресурсы (например, класс управления памятью), [4] классы, представляющие системные ресурсы (например, выходные потоки), [5] классы, используемые для реализации других классов (например, списки, очереди, блокировщики) и [6] встроенные типы данных и структуры управления.В больших системах очень трудно сохранять логическое разделениетипов различных классов и поддерживать такое разделение междуразличными уровнями абстракции. В приведенном выше перечислениипредставлены три уровня абстракции: [1+2] представляет пользовательское отражение системы, [3+4] представляет машину, на которой будет работать система, [5+6] представляет низкоуровневое (со стороны языка программирования) отражение реализации.Чем больше система, тем большее число уровней абстракции необходимодля ее описания, и тем труднее определять и поддерживать эти уровниабстракции. Отметим, что таким уровням абстракции есть прямоесоответствие в природе и в различных построениях человеческогоинтеллекта. Например, можно рассматривать дом как объект,состоящий из [1] атомов, [2] молекул, [3] досок и кирпичей, [4] полов, потолков и стен; [5] комнат.Пока удается хранить раздельно представления этих уровней абстракции,можно поддерживать целостное представление о доме. Однако, еслисмешать их, возникнет бессмыслица. Например, предложение"Мой дом состоит из нескольких тысяч фунтов углерода, некоторыхсложных полимеров, из 5000 кирпичей, двух ванных комнат и 13потолков" - явно абсурдно. Из-за абстрактной природыпрограмм подобное утверждение о какой-либо сложной программнойсистеме далеко не всегда воспринимают как бессмыслицу. В процессе проектирования выделение понятий из области приложенияв класс вовсе не является простой механической операцией. Обычноэта задача требует большой проницательности. Заметим, что самипонятия области приложения являются абстракциями. Например, вприроде не существуют "налогоплательщики", "монахи" или "сотрудники".Эти понятия не что иное, как метки, которыми обозначают беднуюличность, чтобы классифицировать ее по отношению к некоторойсистеме. Часто реальный или воображаемый мир (например, литература,особенно фантастика) служат источником понятий, которые кардинальнопреобразуются при переводе их в классы. Так, экран моего компьютера(Маккинтош) совсем не походит на поверхность моего стола, хотякомпьютер создавался с целью реализовать понятие "настольный" Ь,а окна на моем дисплее имеют самое отдаленное отношение кприспособлениям для презентации чертежей в моей комнате.Ь Я бы не вынес такого беспорядка у себя на экране. Суть моделирования реальности не в покорном следовании тому,что мы видим, а в использовании реальности как начала для проектирования,источника вдохновения и как якоря, который удерживает, когдастихия программирования грозит лишить нас способностипонимания своей собственной программы. Здесь полезно предостеречь: новичкам обычно трудно "находить"классы, но вскоре это преодолевается без каких-либонеприятностей. Далее обычно приходит этап, когда классы и отношениянаследования между ними бесконтрольно множатся. Здесь ужевозникают проблемы, связанные со сложностью, эффективностью иясностью полученной программы. Далеко не каждую отдельную детальследует представлять отдельным классом, и далеко не каждоеотношение между классами следует представлять как отношениенаследования. Старайтесь не забывать, что цель проекта - смоделироватьсистему с подходящим уровнем детализации и подходящим уровнемабстракции. Для больших систем найти компромисс между простотой иобщностью далеко не простая задача.

Иерархии классов

Рассмотрим моделирование транспортного потока в городе, цель которогодостаточно точно определить время, требующееся, чтобы аварийные движущиесясредства достигли пункта назначения. Очевидно, нам надо иметьпредставления легковых и грузовых машин, машин скорой помощи,всевозможных пожарных и полицейских машин, автобусов и т.п.Поскольку всякое понятие реального мира не существует изолированно,а соединено многочисленными связями с другими понятиями,возникает такое отношение как наследование. Не разобравшись в понятияхи их взаимных связях, мы не в состоянии постичь никакое отдельноепонятие. Также и модель, если не отражает отношения междупонятиями, не может адекватно представлять сами понятия. Итак, внашей программе нужны классы для представления понятий, но этогонедостаточно. Нам нужны способы представления отношений между классами.Наследование является мощным способом прямого представленияиерархических отношений. В нашем примере, мы, по всей видимости,сочли бы аварийные средства специальными движущимися средствамии, помимо этого, выделили бы средства, представленные легковыми игрузовыми машинами. Тогда иерархия классов приобрела бы такой вид: движущееся средство легковая машина аварийное средство грузовая машинаполицейская машина машина скорой помощи пожарная машинамашина с выдвижной лестницейЗдесь класс Emergency представляет всю информацию, необходимую длямоделирования аварийных движущихся средств, например: аварийнаямашина может нарушать некоторые правила движения, она имеетприоритет на перекрестках, находится под контролем диспетчераи т.д.На С++ это можно задать так: class Vehicle { /*...*/ }; class Emergency { /* */ }; class Car: public Vehicle { /*...*/ }; class Truck: public Vehicle { /*...*/ }; class Police_car: public Car, public Emergency { //... }; class Ambulance: public Car, public Emergency { //... }; class Fire_engine: public Truck, Emergency { //... }; class Hook_and_ladder: public Fire_engine { //... }; Наследование - это отношение самого высокого порядка, которое прямопредставляется в С++ и используется преимущественно на раннихэтапах проектирования. Часто возникает проблема выбора: использоватьнаследование для представления отношения или предпочесть емупринадлежность. Рассмотрим другое определение понятия аварийногосредства: движущееся средство считается аварийным, если ононесет соответствующий световой сигнал. Это позволит упроститьиерархию классов, заменив класс Emergency на член классаVehicle: движущееся средство (Vehicle {eptr}) легковая машина (Car) грузовая машина (Truck)полицейская машина (Police_car) машина скорой помощи (Ambulance) пожарная машина (Fire_engine) машина с выдвижной лестницей (Hook_and_ladder)Теперь класс Emergency используется просто как член в тех классах,которые представляют аварийные движущиеся средства: class Emergency { /*...*/ }; class Vehicle { public: Emergency* eptr; /*...*/ }; class Car: public Vehicle { /*...*/ }; class Truck: public Vehicle { /*...*/ }; class Police_car: public Car { /*...*/ }; class Ambulance: public Car { /*...*/ }; class Fire_engine: public Truck { /*...*/ }; class Hook_and_ladder: public Fire_engine { /*...*/ }; Здесь движущееся средство считается аварийным, если Vehicle::eptrне равно нулю. "Простые" легковые и грузовые машины инициализируютсяVehicle::eptr равным нулю, а для других Vehicle::eptr должно бытьустановлено в ненулевое значение, например: Car::Car() // конструктор Car { eptr = 0; } Police_car::Police_car() // конструктор Police_car { eptr = new Emergency; } Такие определения упрощают преобразование аварийного средства вобычное и наоборот: void f(Vehicle* p) { delete p->eptr; p->eptr = 0; // больше нет аварийного движущегося средства //... p->eptr = new Emergency; // оно появилось снова } Так какой же вариант иерархии классов лучше? В общем случае ответ такой:"Лучшей является программа, которая наиболее непосредственно отражаетреальный мир". Иными словами, при выборе модели мы должны стремитьсяк большей ее"реальности", но с учетом неизбежных ограничений,накладываемых требованиями простоты и эффективности. Поэтому,несмотря на простоту преобразования обычного движущегося средства ваварийное, второе решение представляется непрактичным.Пожарные машины и машины скорой помощи - этодвижущиеся средства специального назначения со специальноподготовленным персоналом, они действуют под управлением команддиспетчера, требующих специального оборудования для связи. Такоеположение означает, что принадлежность к аварийным движущимся средствам -это базовое понятие, которое для улучшения контроля типов иприменения различных программных средств должно быть прямопредставлено в программе. Если бы мы моделировали ситуацию, в которойназначение движущихся средств не столь определенно,скажем, ситуацию, в которой частный транспорт периодически используетсядля доставки специального персонала к месту происшествия, а связьобеспечивается с помощью портативных приемников, тогда мог быоказаться подходящим и другой способ моделирования системы. Для тех, кто считает пример моделирования движения транспортаэкзотичным, имеет смысл сказать, что в процессе проектированияпочти постоянно возникает подобный выбор между наследованиеми принадлежностью. Аналогичный пример есть в $$12.2.5, гдеописывается свиток (scrollbar) - прокручивание информации в окне.


Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: