Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Диаграма классов
|
|||
|---|---|---|---|
|
#18+
Привет. Диплом. Субд + толстый клиент=учет документооборота на предприятии(включает перемещения по складу). Все это разрабатываю. Строю диаграммы классов для: 1.Документов. 2.Пользователей. 3.Интерфейсов. Возник следующий вопрос. С полями классов все впринципе понятно: У пользователя - фио,подразделение,... У документа - номер документа, дата, ... У интерфейса (формы) - поле, список,... А вот как быть с методами классов? Сотрудник может редактировать документ, смотреть его, сохранять, ставить подпись на нем, заполнять поля, входить в систему... Но методы - редактировать документ, сохранять его, ставить подписи - это ведь методы работы с полями Документа. Значит их стоит описывать в составе класса документа а не в классе пользователь. Но пользовать же инициирует их? Правельно ли то что методы описаны в Документе? В классе Интерфейс решил перечислить поля - список, поле, кнопка...и два поля с типами Документ и Пользователь. И в этом же классе привести методы работы с этими полями (Документ и Пользователь). Так правельно? Подскажите пожалуйста структур для каждого из классов. Где должны распологаться методы? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2004, 19:47 |
|
||
|
Диаграма классов
|
|||
|---|---|---|---|
|
#18+
Не совсем "правельно". Должен быть отдельный класс Интерфейс, независимый от Документа и Пользователя. Между ними должен быть промежуточный прокси-класс. Соответственно класс Интерфейс взаимодействует с классами бизнес-логики через него. Тем самым мы обеспечиваем отделение бизнес-логики от представления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 09:17 |
|
||
|
Диаграма классов
|
|||
|---|---|---|---|
|
#18+
Впринципе понятно. Но все же как расположить методы - в каком классе какой метод. И связи какого типа будут между класами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:49 |
|
||
|
Диаграма классов
|
|||
|---|---|---|---|
|
#18+
Я бы разместил метод подписывания документа у пользователя,так как подпись документа - атрибут, определяемый именно пользователем, значение которого у Вас скорее всего представляет внешний ключ на пользователя. Кстати, имхо это даже не атрибут, а набор, так как у документа множество подписей. Это правильно и с точки зрения ООП: документ не может себя подписать- это делает пользователь.Но с другой стороны, ценители бы ООП для реализации подписывания сделали бы скорее всего так: Абстрактный класс ПОльзователь, абстрактный класс Документ+какая угодно структура классов/набор атрибутов для хранения подписей и, ключевой момент,абстрактный класс Алгоритм подписывания документов, в котором есть указатели на Документ, Пользователь.От этого класса и должны наследоваться различные алгоритмы подписывания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 14:06 |
|
||
|
Диаграма классов
|
|||
|---|---|---|---|
|
#18+
Я бы "подписать" в определил с сигнатурой в которой присутствует параметр содержащий идентификатор пользователя. Действие совершается над документом, а не над пользователем. Прокси-класс излишен, но вот интерфейс со списком методов работы с документом нужно создать. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 14:50 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=32842707&tid=1546123]: |
0ms |
get settings: |
13ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
3ms |
| others: | 263ms |
| total: | 432ms |
| 0 / 0 |
