Что такое общее название для наследования, состава, агрегирования, делегации?
После того, как программа разделена на маленький объект, эти объекты должны быть соединены с каждым. Где различные типы соединения. Наследование, состав, агрегирование, делегация. Эти типы имеют много видов и шаблонов как слабая связь, плотное соединение, инверсия управления, делегации через интерфейсы и т.д. Что такое корректное общее название для упомянутых типов соединений? Я могу предположить, что их всех называют, 'связываясь', но я не могу найти хорошую классификацию в Google, поэтому возможно, я пытаюсь использовать неправильный термин? Возможно, кто-либо знает твердую, доверяемую классификацию, что я могу пользователь для терминологии?
6 ответов
Обычно их называют "отношениями".
Глоссарий Java и связанных с ним терминов
Взято из Object-Oriented Programming with Java: An Introduction by David J. Barnes:
has-a relationship
См. агрегирование.
is-a отношения
См. наследование.
наследование класса
Когда суперкласс расширяется подклассом, между ними возникает отношение наследования класса.
агрегация
Отношение отношения, в котором объект содержит один/более других подчиненных объектов как часть своего состояния.
делегирование
Процесс, посредством которого объект передает полученное им сообщение подчиненному объекту. Если наследование недоступно в языке программирования, делегирование является наиболее жизнеспособной альтернативой для избежания дублирования кода и содействия повторному использованию кода.
Я бы назвал их Associates , что может означать что угодно из композиции для наследования эти два объекта «связаны». Однако Отношения тоже работают, и я предполагаю, что большинство будет утверждать, что «Отношения» - лучший термин.
Простой ответ - это отношения между объектами в объектно-ориентированном программировании.
Наследование - отношения между двумя типами, которые подразумевают механизм для повторного использования состава поведения
- структурные отношения, подразумевающие отношения целое / часть и что часть не может существовать без совокупности целого
- структурные отношения, подразумевающие отношения целое / часть, и что часть может существовать без целого
делегирование - поведенческие отношения, при которых набор поведения предоставляется другим объектом для основного получателя сообщения.
Какое правильное общее название для упомянутых типов соединений?
Это отношения, но это разные виды отношений: наследование - это отношения между типами, отношения состава и агрегирования между объектами, а также делегирование поведенческих отношений. У вас могут быть все три вида ортогонально между одними и теми же двумя классами.
Я могу предложить, чтобы все они назывались «связью»
Каждый из них будет создавать (в терминологии UML) зависимость «использует» от пакета, содержащего клиента, к пакету, содержащему поставщика. При создании графов зависимостей между модулями в системе я считаю полезным разделить простые зависимости и использование классификатора (например, тип операции, параметр или свойство); для правильной работы вам необходимо импортировать классификаторы, используемые элементами, от которых вы зависите, но вам не нужны напрямую транзитивные зависимости или зависимости классификаторов.
Корпоративные шаблоны Должны содержать довольно много справочного материала и определять имена, наиболее часто используемые в отрасли.
UML - это общепринятый стандарт, который предоставляет некоторую терминологию, которую вы, возможно, захотите позаимствовать.
Из спецификации UML v2.3 ( http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/ ):
Ассоциация описывает набор кортежей, значения которых относятся к типизированным экземплярам. Экземпляр ассоциации называется ссылкой.
Другими словами, если я правильно это понимаю, ассоциация конкретно связывает экземпляры классов друг с другом. Агрегация и состав - это разновидности ассоциаций. Однако в формальном языке UML обобщения (наследования) и делегирования нет.
Как оказалось, UML также имеет концепцию отношения . Опять же, из спецификации:
Отношения - это абстрактное понятие, которое определяет какой-то вид отношений между элементами.
Я бы сказал, что это достаточно широко, чтобы охватить все ваши четыре термина.
Тем не менее, UML не обязательно является единственным арбитром при определении этих терминов. UML произошел от нескольких объектно-ориентированных методологий, в которых термины «ассоциация» и «отношения» в значительной степени взаимозаменяемы. С точки зрения общепринятой практики, я не думаю, что вы запутаете пользователей, используя одно или другое.