Читаем Изучаем Java EE 7 полностью

Примечание

Типы явного доступа также очень полезны, когда речь идет о наследовании. По умолчанию листовые сущности наследуют тип доступа от своей корневой сущности. В иерархии сущностей доступ к каждой из них возможен по-разному из других классов в иерархии. Включение аннотации @Access фактически приведет к тому, что режим доступа по умолчанию для иерархии будет локально переопределен.

Отображение связей

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

Прежде всего, у ассоциации есть направление. Она может быть однонаправленной (один объект может осуществлять навигацию по направлению к другому объекту) и двунаправленной (один объект может осуществлять навигацию по направлению к другому и наоборот). В Java для навигации по объектам используется точечный (.) синтаксис. Например, если написать customer.getAddress(). getCountry(), то будет осуществляться навигация от объекта Customer к объекту Address, а затем — к объекту Country.

В унифицированном языке моделирования (Unified Modeling Language — UML) для представления однонаправленной ассоциации между двумя классами используется стрелка, указывающая направление. На рис. 5.5 Class1 (источник) может осуществлять навигацию по направлению к Class2 (цель), но не наоборот.


Рис. 5.5. Однонаправленная ассоциация между двумя классами


Для индикации двунаправленной ассоциации стрелки не используются. Как показано на рис. 5.6, Class1 может осуществлять навигацию по направлению к Class2 и наоборот. В Java это представляется как наличие у Class1 атрибута типа Class2 и наличие у Class2 атрибута типа Class1.


Рис. 5.6. Двунаправленная ассоциация между двумя классами


Для ассоциации также характерна множественность (или кардинальность). На каждом из концов ассоциации можно указать, сколько ссылающихся объектов вовлечено в нее. На UML-диаграмме, приведенной на рис. 5.7, показано, что Class1 ссылается на нуль или более экземпляров Class2.


Рис. 5.7. Множественность ассоциаций классов


В UML кардинальность — это диапазон между минимальным и максимальным числами. Таким образом, 0..1 означает, что у вас будет минимум нуль объектов и максимум один объект; 1 означает, что у вас один и только один экземпляр; 1..* означает, что у вас может быть один или много экземпляров, а 3..6 означает, что у вас может быть от трех до шести объектов. В Java ассоциация, представляющая более одного объекта, задействует коллекции типа java.util.Collection, java.util.Set, java.util.List или даже java.util.Map.

В случае со связью имеет место владение (то есть владелец связи). При однонаправленной связи предполагается владение: нет сомнения, что на рис. 5.5 владельцем является Class1, однако при двунаправленной связи, как показано на рис. 5.6, владельца нужно указывать явным образом. В таком случае вы показываете владельца, который определяет физическое отображение и противоположную сторону (не владеющую сторону).

В следующих разделах вы увидите, как отображать коллекции объектов с использованием аннотаций JPA.

Связи в реляционных базах данных

В реляционном мире дело обстоит по-другому, поскольку, строго говоря, реляционная база данных — это коллекция отношений (также называемых таблицами), то есть все, что вы смоделируете, будет таблицей. При моделировании ассоциации у вас не будет списков, наборов или отображений — у вас будут таблицы. В JPA при наличии ассоциации между одним классом и другим в базе данных у вас будет ссылка на таблицу. Эту ссылку можно смоделировать двумя способами: с помощью внешнего ключа (столбца соединения) или с использованием таблицы соединения. В контексте базы данных столбец, ссылающийся на ключ другой таблицы, называется столбцом внешнего ключа.

В качестве примера предположим, что у клиента имеется один домашний адрес. В листингах 5.33 и 5.34 мы моделировали эту связь как встраиваемый объект, однако теперь превратим ее в связь «один к одному». При использовании Java у вас имелся бы класс Customer с атрибутом Address. В реляционном мире у вас могла бы быть таблица CUSTOMER, указывающая на ADDRESS с помощью столбца внешнего ключа (или столбца соединения), как показано на рис. 5.8.


Перейти на страницу:

Похожие книги

C# 4.0: полное руководство
C# 4.0: полное руководство

В этом полном руководстве по C# 4.0 - языку программирования, разработанному специально для среды .NET, - детально рассмотрены все основные средства языка: типы данных, операторы, управляющие операторы, классы, интерфейсы, методы, делегаты, индексаторы, события, указатели, обобщения, коллекции, основные библиотеки классов, средства многопоточного программирования и директивы препроцессора. Подробно описаны новые возможности C#, в том числе PLINQ, библиотека TPL, динамический тип данных, а также именованные и необязательные аргументы. Это справочное пособие снабжено массой полезных советов авторитетного автора и сотнями примеров программ с комментариями, благодаря которым они становятся понятными любому читателю независимо от уровня его подготовки. Книга рассчитана на широкий круг читателей, интересующихся программированием на C#.Введите сюда краткую аннотацию

Герберт Шилдт

Программирование, программы, базы данных
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Нил Форд , Билл де Ора , Майкл Хайгард

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT