На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
Это только усложняет модель. И в большинстве случаев совершенно лишнее.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге").
Второй вариант - это не постановка задачи, а постановка вопроса. Перед выполнением надо решить, что такое "коллега", что в большинстве случаев не тривиально. (Для того задача построения путей коммуникации и существует, чтоб определить действие однозначно и убрать муки выбора)
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
При обнаружении не определённых в системе элементов, надо добавлять определение в систему, а не кормить её мусором. То есть задача "выполнить некую фигню" разбивается на две "определить какую именно фигню" (процесс постановки задачи/планирования) и "эту конкретную фигню выполнить" (выполнение задачи)
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Ограничение возможно только одно "Нельзя". Любые "слабые" ограничения имеют тенденцию размываться.
1. дизайн играет не последнюю роль (успех Эппл, например)
Эппл тем и отличается, что использует для создания интерфейсов не программистские модели, а те, что в голове у пользователя. Начиная от рабочего стола и мусорной корзины.
как мы знаем, построить идеальную модель все равно не получится
Строимая модель - это не конечная версия, а зародыш. Что вырастет - зависит от полевых испытаний.
И классы должны быть легко определимыми, а не абстрактными базовыми.
no subject
На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
Это только усложняет модель. И в большинстве случаев совершенно лишнее.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге").
Второй вариант - это не постановка задачи, а постановка вопроса. Перед выполнением надо решить, что такое "коллега", что в большинстве случаев не тривиально. (Для того задача построения путей коммуникации и существует, чтоб определить действие однозначно и убрать муки выбора)
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
При обнаружении не определённых в системе элементов, надо добавлять определение в систему, а не кормить её мусором. То есть задача "выполнить некую фигню" разбивается на две "определить какую именно фигню" (процесс постановки задачи/планирования) и "эту конкретную фигню выполнить" (выполнение задачи)
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Ограничение возможно только одно "Нельзя". Любые "слабые" ограничения имеют тенденцию размываться.
1. дизайн играет не последнюю роль (успех Эппл, например)
Эппл тем и отличается, что использует для создания интерфейсов не программистские модели, а те, что в голове у пользователя. Начиная от рабочего стола и мусорной корзины.
как мы знаем, построить идеальную модель все равно не получится
Строимая модель - это не конечная версия, а зародыш. Что вырастет - зависит от полевых испытаний.
И классы должны быть легко определимыми, а не абстрактными базовыми.