Roman Murzakov
Для вас журнал регистрации состоит из неочевидных для реализации атрибутов и действий с ним, что приходится применять к нему абстракцию?
Думаю, что ваш первоисточник имел ввиду всё таки более сложные объекты, которые имеют в себе вложенные объекты и сложные поведения. А не просто журнал.
Не надо слишком буквально понимать рекомендации из книжек, особенно в сопровождении таких картинок.
1. В данном случае является т.к. журнал регистрации не подлежит абстракции - в нём всё важно для реализации (если конечно не обращать внимание на атомы из которых он состоит).
Абстракции подлежит предметная область, бизнес-процессы которой вы изучаете для автоматизации. А вот журналы и прочее - это артефакты предметной области.
2. Не путайте интервьюирование заинтересованных лиц и артефакты предметной области. Одним лицам какие-то артефакты нужны, а каким-то нет. А вы как аналитик, моделирующий автоматизацию конкретных бизнес-процессов должны выстроить цепочку действий и выявление необходимых артефактов, участвующих в этом бизнес-процессе.
Абстракция отсеивает моменты, которые не влияют на выполнение бизнес-процесса. Например семейное положение секретаря, который ведёт журнал регистрации почты или её стиль одежды/настроение/полка для журналов и т.п.
Заметьте, автоматизируются не объекты, а бизнес-процессы (деловая деятельность) заказчика.
Вопрос не совсем корректный т.к. вы опять не конкретизируете.
1. Если журнал как образец формы заполнения, то это аналог класса.
2. Если журнал, используемый в реальной работе, то это аналог экземпляра класса.
Встречный вопрос:
Чем являются регламентированные формы различных актов, бланков и т.п. в нормативных инструкциях?
3. Хорошо, пусть будет такая задача.
Тогда, есть несколько вариантов для журнала регистрации:
- Форма отчёта (экземпляр класса "Документ" или "Отчёт").
- Отношение (класс сущности) в БД.
- Визуальная форма для отображения на экране монитора (например html - страница).
Ещё раз по порядку:
1. Если речь об ЭДО, то надо это упомянуть явно.
2. Интерфейсы — это не классы. С помощью ключевого слова new нельзя создать экземпляр интерфейса. Ссылка (для примера объективности):
https://developer.alexanderklimov.ru/android/java/interface.php
Или вот:
Интерфейс - это именованный набор моделей поведения (и/или постоянных элементов данных), который должен обеспечить реализатор. Интерфейс определяет поведение реализации, но не то, каким образом оно достигается.
Как видите, определение интерфейса принципиально отличается от определения класса (которое вы можете найти сами).
3. Изучаемые объекты архитектуры не являются экземплярами класса, который вы проектируете (тот самый дом). Изучаемые объекты являются экземплярами других классов. Вы можете много чего изучать (хоть квантовую физику), но в результате исходным результатом будет класс сущности (проект дома), обладающей атрибутами (состоянием) и методами (поведением) своими уникальными. Причём заметьте, состоянием (конкретными значениями атрибутов экземпляра класса) обладают только инстансы класса (построенные дома по вашему проекту), которые уже инициализированы в работающей программе (строительной бригадой).
Статья путает начинающих аналитиков и тех, кто только подступается к основам ООП.
Например:
1. Объект другой системы это не исходящее, а входящее письмо.
2. Интерфейс это не специальный класс, а специальный метод или набор методов. Чтобы быть классом, надо обладать атрибутами (ко всему прочему). У интерфейса нет атрибутов, а только методы, зачастую абстрактные (без реализации).
3. Объяснять надо не от объекта к классу, а наоборот - от класса к объекту. Рассказать, что класс - это проект сущности. А объект - это его воплощение в реализации. По аналогии со строительством дома или коттеджа. Проект в единственном варианте, а его воплощений т.е. типовых домов/коттеджей может быть множество.
Ребята, не читайте такие статьи - запутаетесь на самой ранней стадии вхождения в ООП.
Да, такое бывает, но их тогда вообще не надо рассматривать как артефакт предметной области для изучения.
Тогда класс журнала становится родительским классом от которого должен наследоваться журнал с расширенными атрибутами.
По хорошему, родительским классом должен быть класс документа, форма которого устанавливается регламентирующими документами. А вот от него наследуются уже все остальные неформальные хотелки.
Современные СУБД умеют поддерживать наследование. Так что даже можно так в БД и отразить структуру наследованных и родительских классах. Вдруг потом заказчик захочет опять что-то изменить в свойствах класса.
Или же всё это хранить в json объектах.
Но расширение класса это не абстрагирование, скорее это похоже на принцип DTO.
Кстати, интерфейсы придумали для решения проблемы множественного наследования в объектных языках, в которых такое множественное наследование запрещено.