c. 160 Классы Тип Показателя и Показатель

Что означает такой конструктор?

public PhenomenonType (String name) {
 super (name);
}

Какой на самом деле объект создаётся? Какого типа? Родительского? Не верится что-то... Просто выполняется метод-конструктор родительского класса для того, чтобы задействовать методы родительского класса? Чтобы не обращаться к ним по-отдельности? Наверное, так. Как-то не очень хорошо я чувствую этот механизм.
-----
Метод setPhenomena (String[] names). В этом методе никак не учитываются диапазоны. Получится просто коллекция Показателей с названиями и указанием, к какому типу они относятся. Но как же сделать между ними количественное различие?
-----
public Enumeration phenomena(). Если Enumeration - это интерфейс, то какой объект, реализующий этот интерфейс, возвращает этот метод?
Лёнька подсказал, как это понимать. Реализующий интерфейс объект, конечно, есть, но он спрятан в коде, не моём коде, а где-то в каком-то пакете. А нам просто не нужно его знать, достаточно просто пользоваться предоставляемыми им методами.
-----
Это для меня новое - использовать this в конструкторе. Казалось бы, конструктор конструирует объект, то есть объект ещё не готов, а тут на тебе - this! Получается, что выдаётся ссылка на объект, который ещё не готов в этот момент. Не знал, что так можно. И вообще, интересный способ организации связи.
-----
Итак, при создании Показателя он сразу же ассоциируется с Типом Показателя. А вот обратного не наблюдается. Тип Показателя вполне может быть создан без связи с Показателями.
-----
Загадочное свойство типа QuantityRange. Пока нигде не задействовано. И потому Eclipse на него ругается...
-----
Ещё непонятно, зачем в DomainObject пустой конструктор прописан. С какой целью? Имеет ли это какое-то отношение к наследникам?
-----
Vector используется не параметризированный. Eclipse тоже на это ругается. Вероятно, это связано с разными версиями Java. И Enumeration хочет быть параметризированным. Кстати, всегда ли это возможно. Ведь Vector не должен содержать элементы только одного типа...
-----
А теперь буду писать свои классы, по своей диаграмме. Интересно, какие вопросы при этом возникнут.

c. 159 Переход к кодированию

"Некоторые разработчики испытывают трудности при работе с двунаправленными связями. Я не думаю, что могут возникнуть какие-либо проблемы, если обеспечить такую реализацию, при которой один класс несёт полную ответственность за поддержание данной связи в актуальном состоянии."
Что это означает?.. "... один класс несёт полную ответственность". Один из двух или каждый из двух? Взять, к примеру, мои Тип Показателя и Диапазон. Как поддерживать между ними двунаправленную связь? При создании нового Диапазона нужно сразу же внести его в список диапазонов соответствующего Типа Показателя? А если создаётся новый Тип Показателя, сразу же создавать совокупность Диапазонов?
А у Фаулера, соответственно, при создании Показателя нужно тут же рассказать о нём Типу Показателя, а при создании Типа Показателя нужно сразу же создать набор Показателей этого типа.
Так, что ли? Интересно будет посмотреть реализацию.

с. 158 Тип Показателя знает все свои Диапазоны

"

... новое Измерение должно установить, существует ли Показатель, который может быть для него назначен."
Это логично, что для Измерения можно подобрать соответствующий Показатель. Но то, что его может не быть, уже не так хорошо выглядит... Но так может быть, да...
На моей диаграмме выяснение такого соответствия опущено на один уровень вглубь. Для Количества может быть определён Диапазон. Но, опять же, какой класс занимается этим? И мне бы не хотелось, чтобы для какого-то Количества не было Диапазона.
"... Измерение может запросить ассоциированный с ним Тип Показателя, имеется ли соответствующий Показатель".
То есть подразумевается, что Тип Показателя знает все свои Показатели. В моём случае, Тип Показателя должен знать все свои Диапазоны.

 

В случае Измерения теперь результат может быть таким: "6 футов (средний рост)". 

с. 157 Момент последнего наблюдения

"... последние данные о сердечном ритме пациента".
Неважно, какие это будут данные - точное значение измерения или его обощенный результат. Важно только время. Нужны самые свежие данные.
"Найти последнюю Категорию Наблюдения..."
Странно, этого понятия на диаграмме уже нет...
Предлагаются следующие методы:

последнееЗначение(ТипПоказателя):Количество;
показатель(ТипПоказателя):Показатель.

То есть интересует не просто последнее наблюдение, а последнее классифицированное наблюдение. А какой в этом смысл? Допустим, последнее наблюдение для типа показателя "Сердечный ритм" было измерением, и оказалось, что результат равен "90 ударов в минуту", а вот предпоследнее наблюдение было определением показателя и результат был "высокий". И что нам выдадут методы? Несоответствующие друг другу результаты. Ладно, может быть, я не так понял. Но зачем два метода? Почему нельзя обойтись простым последнееНаблюдение(ТипПоказателя) ? Этот метод выдаст результат в зависимости от реального реализатора интерфейса Наблюдение: если это было Измерение, то будет "90 ударов в минуту", если Показатель, то "высокий".
Из конкретного измерения можно, в принципе, определить диапазон и, соответственно, Показатель. В обратную сторону такое не сработает. Но кто будет заниматься этим сопоставлением? Это тот самый кто-то, занимающийся обобщением для Показателя, но которого нет на диаграмме. Если он на ней появится, то в Измерении можно будет создать метод, запрашивающий диапазон, соответствубщий результату.

Ещё один момент... Наблюдение на диаграмме Фаулера связано с Показателем. Однако Показателя для некоторого Наблюдения может и не быть (0...1). Тогда что это за наблюдение? Ни Показателя, ни Измерения. Смысл такого объекта Наблюдение?..

с. 156 Диаграмма уровня спецификации

Интересненько... Наблюдение всё-таки осталось. И это не интерфейс, а класс. Оно и было классом с самого начала. А у меня Наблюдение - это интерфейс.

А зачем Фаулеру вообще Наблюдение? В Наблюдении может быть Показатель, а может и не быть. А так как Измерение - наследник Наблюдения, то и в Измерении может быть Показатель. Вернее, Показатель ассоциирован с Измерением. Не знаю как кому, а мне такой вариант не нравится.
А как насчёт инкапсуляции? Каким образом в Пациенте реализовать доступ к значению Измерения? Ведь в Наблюдении таких данных нет. По идее, сделать в Пациенте можно только так:
(Измерение)Наблюдение.значение()
А просто для Наблюдения сделать пустой метод? В общем, по-любому в Измерении подобный метод должен переопределяться. И откуда вообще Пациент должен узнать, что он может использовать такой метод - значение() ?

с. 155 Оптимизация диаграммы

"В языке Java, как и в большинстве других языков программирования, можно определить только одну классификацию".
Что-то мне это непонятно. Что имеется ввиду? Что невозможно предложить такой интерфейс Наблюдение, который смогли бы реализовать и Измерение, и Категория Наблюдения? В принципе, на моей диаграмме одно несоответствие есть: в Измерении "результат" - это Количество, а в Категории Наблюдения - Показатель. Свойство "тип показателя" в Категории Наблюдения можно взять из Показателя, но это будет уже дублирование... Тогда можно сделать это не свойством, а методом "получить Тип Показателя()". А вот срезультатом нужно что-то придумывать.
"Я решил эту проблему, допустив, что любое Наблюдение должно иметь ассоциированный с ним Показатель, который позволяет классу Наблюдение эффективно реализовывать как понятие Наблюдение,  так и понятие Категория Наблюдения".
Какая-то здесь путаница, однако. Это что же, мне нужно каким-то макаром ассоциировать с Показателем Измерение? Но ведь Показатель ассоциирован с Диапазоном, который есть диапазон всё-таки, а у меня в Измерении указывается точное значение измерения в виде Количества. Подменять Количество Диапазоном плохо пахнет, как говорится. Кроме того, "... позволяет классу Наблюдение реализовывать..." Наблюдение - это интерфейс, а не класс, и потому он ничего реализовывать не может. Может быть, имеется ввиду класс Измерение, который должен теперь реализовывать понятия Наблюдение и Категория Наблюдения? Интерфейс долой? И как же мне нужно изменить свою диаграмму?

Ну что ж, пока диаграмма стала такой:

Однако это ещё не конец. Категорию Наблюдения нужно вообще убрать, Показателя будет вполне достаточно. А ещё было бы неплохо ассоциировать Тип Показателя с Единицей, чтобы невозможно было измерить "рост", к примеру, в "килограммах"...

Пришла в голову интересная идея...

Показатель определяется Диапазоном, однако для того, чтобы выбрать Диапазон, нужно ведь произвести какое-то измерение. То есть сначала что-то измеряем, находим значение, а затем смотрим, к какому диапазону это значение относится. Таким образом, любой Диапазон можно сопроводить Измерением, а любое Измерение можно сопоставить с некоторым Диапазоном. Что и этого следует?

Вариант первый. Ассоциировать Диапазон с Измерением. В этом случае любое Наблюдение будет Показателем. Однако любой показатель должен сопровождаться Измерением.

Вариант второй. Ассоциировать Измерение с Диапазоном. То есть каждое Измерение можно сопоставить с некоторым Диапазоном. В этом случае Показатель не должен иметь ввиду какое-то Измерение. Зато для каждого Измерения нужно искать свой Диапазон. И в чём тогда будет различие между Измерением и Показателем? Тем, что Измерение будет расширенным вариантом показателя, за счёт обладания точным значением измерения.

В любом случае, можно выделить такие классы: с измерением, с диапазоном и с обоими понятиями вместе. Последний класс расширяет первые два. Какую цепочку наследования выбрать?

Что на самом деле является расширением? Измерение расширяет диапазон или диапазон расширяет измерение? Что первично, а что вторично? Что уточняет другое? 38 градусов - это какая температура? А высокая температура - это сколько градусов?
Не хочется мне что-то уже ничего менять. Пускай остаётся так, как есть. Посмотрим, что из этого получится.

c. 154 Диаграмма объектов наблюдения

При построении диаграммы объектов (диаграммы экземпляров) возникли трудности с определением Диапазона для Типа Показателя "Группа крови". Для группы крови нельзя указать верхнюю и нижнюю границу, она просто "Первая", к примеру. В общем, получилось, что Диапазон может применяться только для исчисляемых величин, которые имеют единицы измерения и значение, определяемое в этих единицах. Для неисчисляемых величин нужно ввести новое понятие вместо Диапазона. Или просто пока принять, что обязательным полем для Диапазона является только "название". Может быть, в дальнейшем такая детализация и не понадобится. У Фаулера, по крайней мере, её нет.

А вот Фаулер и сам говорит про Диапазон. Его идея относительно Количественного Диапазона может быть решением проблемы, так как подразумевает возможность создания других типов диапазонов, реализующих общий интерфейс Диапазон.