Как представить абстрактный класс, который имеет отношение к классу интерфейса в диаграмме классов
Я должен сделать диаграмму с минимум одним абстрактным классом и интерфейсом. Хотя было бы неплохо реализовать класс интерфейса здесь. Моя таблица - это клиент, который является абстрактным классом. Класс интерфейса показывает методы, которые необходимо включить в два типа клиентов. Мой вопрос в том, как я представляю абстрактный класс, который связан с классом интерфейса. Должен ли я оставить класс клиента пустым? Неправильно ли использовать интерфейс с абстрактным классом?
Это моя диаграмма:
Ответы 2
interface не class. Ниже приведено определение из учебника Oracle:
В языке программирования Java интерфейс является ссылочным типом. подобно классу, который может содержать только константы, метод сигнатуры, методы по умолчанию, статические методы и вложенные типы. Метод тела существуют только для методов по умолчанию и статических методов. Интерфейсы не могут быть созданы — они могут быть реализованы только классами или расширен другими интерфейсами.
На той же странице упоминается,
В программной инженерии есть ряд ситуаций, когда важно, чтобы разрозненные группы программистов согласились на «контракт» это объясняет, как взаимодействует их программное обеспечение. Каждая группа должна быть в состоянии написать свой код, не зная, как другой Код группы написан. Вообще говоря, интерфейсы такие контракты.
Таким образом, в interface вы должны поместить сигнатуры методов (контракты), которые, как вы хотите, должны обязательно иметь все реализующие классы.
Ваш abstract class может реализовать некоторые из этих методов, и эти реализации служат реализацией по умолчанию для дочерних классов (то есть классов, которые extendabstract class). Этот класс может иметь дополнительные члены для наследования его дочерними классами.
@GEORGIDIMITROV - В своем ответе я упомянул, что ваш абстрактный класс может иметь дополнительные члены для наследования его дочерних классов. Другими словами, если вы хотите иметь что-то общее, что оба дочерних класса могут наследовать от этого абстрактного класса, поместите это в абстрактный класс. Не стесняйтесь комментировать в случае каких-либо дальнейших сомнений/вопросов.
Поскольку ваш вопрос касается моделирования UML, я предоставлю дополнительную, более ориентированную на UML информацию:
- Ваш «интерфейс» определяет контракт с тремя операциями (в java операции — это методы). Это означает, что все классы, реализующие этот интерфейс, должны обеспечивать три операции.
- Согласно вашему рассказу, абстрактный класс
Customerреализует интерфейс. Это должно быть представлено на диаграмме зависимостью «реализации», то есть пунктирной линией от класса к интерфейсу с простой пустой стрелкой. (Предупреждение: ваша диаграмма, похоже, представляет собой навигационную ассоциацию, и это будет иметь совершенно другое значение) - Но реализация не является наследованием: по умолчанию ничего не происходит с отношением реализации, и вы должны явно добавить все три операции для
Customer. Если некоторые операции остаются абстрактными на этом уровне, они должны быть отмечены как таковые (т. е. курсивом). Вы можете переопределить любую из этих абстрактных операций в специализациях (то есть унаследованных классах)Customer.
При этом абстрактный класс имеет смысл только в том случае, если он добавляет некоторую ценность, например, предоставляет реализацию по умолчанию для некоторых методов, добавляет некоторые дополнительные методы или свойства. Если это просто пустое поле, а дочерние классы все равно должны реализовать все, то вы можете удалить абстрактный класс из своего дизайна:
- Любой класс, наследующий абстрактный класс, вместо этого просто реализует интерфейс.
- Любой класс, связанный с абстрактным классом, будет затем связан с интерфейсом, который заменит любой класс, который его реализует.
Хорошо, я понимаю, что интерфейсы не являются классами, но должен ли я оставить абстрактный класс пустым?