2017-10-25
2718Наследование классов в ООП
Важнейшим свойством классов в ООП и их принципиальным отличием от абстрактных типов данных (встроенных в язык программирования) является наследование. Наследование — это отношение между классами, при котором один класс разделяет структуру или поведение одного или нескольких других классов.
Наследование классов в ООП может быть многоуровневым.
Иерархию классов в ООП можно построить по-разному. Фактически иерархия классов является классификатором объектов.
Важно отметить, что в ООП существует особый тип классов — абстрактные классы. Абстрактные классы — это классы для которых не существует экземпляров, они лишь описывают общие характеристики классов-потомков.
Конкретные классы — это классы экземпляры которых могут существовать (или существуют) в системе в отличии от абстрактных классов.
Механизм абстрактных классов в ООП является чрезвычайно мощным понятием, которое широко используется. Назначением абстрактных классов в ООП является определение общих, наиболее характерных методов и атрибутов наследуемых из них классов. Чаще всего абстрактные классы используются для задания общего интерфейса иерархии конкретных классов, хотя и атрибуты, и реализация каких-либо методов могут присутствовать в абстрактных классах.
Рассмотренные до сих пор примеры показывали как класс в ООП может унаследовать методы и атрибуты одного базового класса. Такое наследование носит название одинарного или простого наследования. Наряду с ним существует и множественное наследование, при котором у одного класса имеется несколько базовых.
Множественное наследование в ООП позволяет объединять характеристики различных классов в одном.
Полиморфизм в ООП
Полиморфизм — это возможность взаимодействия с объектом, не зная, к какому конкретному классу он относится. Например, посылая сообщение любому счету мы используем полиморфизм всех счетов.
В данном случае полиморфизм является ограниченным. Если сообщение «снять» будет послано, например, клиенту, он не сможет его обработать, т.е. нам не важно какой конкретно счет обрабатывает сообщение, но тем не менее это должен быть счет, объект одного из классов, выделенных из базового класса «Счет».
В большинстве случаев используется именно ограниченный полиморфизм. Тем не менее, иногда любой объект системы может обработать некоторое сообщение. Например, в языке Java у всех объектов имеется метод toString, приводящий значение объекта к строковому виду, соответственно любому объекту независимо от его класса можно послать сообщение toString.
При использовании полиморфизма в ООП используется знание интерфейса объекта, однако поведение конкретного объекта в ответ на полученное сообщение может быть различно в зависимости от конкретного класса этого объекта. Соответственно посылающий сообщение объект точно не знает, что произойдет при вызове метода.
Отношения между классами
объекты находятся в определенных отношениях друг с другом. Один из типов таких отношений - это зависимость. зависимость возникает тогда, когда реализация класса одного объекта зависит от спецификации операций класса другого объекта. И если изменится спецификация операций этого класса, нам неминуемо придется вносить изменения и в зависимый класс.
Приведем простой пример, опять-таки взятый из нашей повседневности. Иногда к нам в руки попадают видеофайлы, воспроизвести которые "с лету" не удается. Почему? Правильно, потому что на компьютере не установлены соответствующие кодеки. То есть операция "Воспроизведение", реализуемая программой-медиаплеером, зависит от операции "Декомпрессия", реализуемой кодеком. Если спецификация операции "Декомпрессия" изменится, придется менять код медиаплеера, иначе он просто не сможет работать с каким-то кодеком и, в лучшем случае, завершит свою работу с ошибкой. А вот так зависимость между классами изображается в UML (рис. 3.10):
Рис. 3.10.
Стоит отметить, что зависимости на диаграммах изображают далеко не всегда, а только в тех случаях, когда их отображение является важным для понимания модели. Часто зависимости лишь подразумеваются, т. к. логически следуют из природы классов.
Другой вид отношений между объектами - это ассоциация. Это просто связь между объектами, по которой можно между ними перемещаться. Ассоциация может иметь имя, показывающее природу отношений между объектами, при этом в имени может указываться направление чтения связи при помощи треугольного маркера. Однонаправленная ассоциация может изображаться стрелкой. Проиллюстрируем сказанное примерами (рис. 3.11):
Рис. 3.11.
Кроме направления ассоциации, мы можем указать на диаграмме роли, которые каждый класс играет в данном отношении, и кратность, то есть количество объектов, связанных отношением (рис. 3.12):
Рис. 3.12.
И насчет ролей, и насчет кратности на этой диаграмме все понятно - человек может вообще не работать, работать в одной или более компаниях, а вот компании в любом случае нужен хотя бы один сотрудник. Кстати, о кратности. Ассоциация может объединять три и более класса. В этом случае она называется n-арной и изображается ромбом на пересечении линий, как показано на этой диаграмме, позаимствованной нами из Zicom Mentor (рис. 3.13):
Рис. 3.13.
Ранее мы говорили, что ассоциация - это "просто связь " между объектами. На самом деле, в реальности связи бывают "просто связями" крайне редко. Обычно при ближайшем рассмотрении под ассоциацией понимается более сложное отношение между классами, например, связь типа "часть-целое". Такой вид ассоциации называется ассоциацией с агрегированием. В этом случае один класс имеет более высокий статус (целое) и состоит из низших по статусу классов (частей). При этом выделяют простое и композитное агрегирование и говорят о собственно агрегации и композиции. Простая агрегация предполагает, что части, отделенные от целого, могут продолжать свое существование независимо от него. Под композитным же агрегированием понимается ситуация, когда целое владеет своими частями и их время жизни соответствует времени жизни целого, т. е. независимо от целого части существовать не могут. Примеры этих видов ассоциаций и их обозначений в UML можно увидеть на следующей диаграмме (рис. 3.14).
Рис. 3.14.
Примеры, как нам кажется, очень простые и понятные. Винчестер можно вынуть из компьютера и установить в новый компьютер или в USB-карман, т. е. существование жесткого диска с разборкой системного блока не заканчивается. А вот кнопки без окон обычно существовать не могут - с закрытием окна кнопки также исчезают.
И, наконец, еще одна важная вещь, касающаяся ассоциации. В отношении между двумя классами сама ассоциация тоже может иметь свойства и, следовательно, тоже может быть представлена в виде класса. Пример прост (рис. 3.15):
Рис. 3.15.
Действительно, перед началом трудовых отношений работник и работодатель подписывают между собой контракт, который имеет такие атрибуты, как, например, описание работ, сроки их выполнения, порядок оплаты и т. д.
А вот более сложный, но, опять-таки, взятый из реальной жизни пример моделирования отношений между классами, позаимствованный нами из Zicom Mentor (рис. 3.16):
Рис. 3.16.
диаграмма, описывающая предметную область сказки о Курочке Рябе
Рис. 3.17.
Выводы
· Инкапсуляция защищает внутреннее устройство объекта и реализуется путем ограничения доступа к атрибутам и операциям класса из других частей программы.
· Обобщение позволяет повторно использовать уже существующие решения, создавая новые классы путем наследования от имеющихся классов.
· Полиморфизм позволяет работать с группой разнородных объектов одинаковым образом, не задумываясь о различиях в реализации.
· Инкапсуляция, наследование и полиморфизм - три кита, на которых держится ООП.
· В любой системе между объектами существуют отношения разных типов.
· Отношение зависимости означает, что реализация одного класса зависит от спецификации операций другого класса.
· Ассоциация выражает отношение между несколькими равноправными объектами и может иметь направление, роли и кратность, а также изображаться в виде класса ассоциации.
· Композиция и агрегация используются, если между объектами существуют отношения типа "часть-целое", причем композиция предполагает, что части не могут существовать отдельно от целого.
