При разработке программного обеспечения (например, диаграммы UML) и объектов реального мира.Разработка программного обеспечения UML (в частности, абстрактные классы)
Как определить подходящий случай для абстрактного класса?
Например, если у нас были [Сотрудник] и [Пожарный] и [paidFireman] и [unpaidFireman] ... У меня возникли проблемы с тем, должен ли Fireman или Employee быть абстрактным и почему?
Абстрактные классы являются одной из тех более эзотерических конструкций в UML. Поскольку классы уже являются абстракцией реальных вещей, абстрактный класс даже на один уровень выше. Абстрактные классы не могут быть созданы (поскольку предполагается, что они что-то пропускают для реальной жизни). Если вы говорите, что Fireman является абстрактным, а платные/неоплаченные - нет, это чистая точка зрения и должна быть аргументирована в конкретном домене.
Как правило, оставляйте абстрактные классы из дверей, пока не дойдете до точки, где вы чувствуете настоятельную необходимость в ней. Введение абстрактности ограничивает вашу модель (и может помочь избежать некоторых искаженных результатов). Но без этих ограничений модель остается в силе до тех пор, пока архитектор придерживается правил здравого смысла.
Существует много применений для абстрактного класса. Абстрактный класс - это тот, который не может иметь прямых экземпляров.
В разработке программного обеспечения это один из способов описания интерфейса. Некоторые из заявленных операций могут быть реализованы в суперклассе. Любые оставшиеся реализации должны быть указаны в подклассах. Независимо от того, где существуют реализации, абстрактный класс означает, что не может быть никаких прямых экземпляров, только экземпляров некоторого не абстрактного подкласса.
В анализе домена абстрактный класс является способом моделирования абстракции. Например, подумайте об абстракции Role. Полезно сказать, что Person воспроизводит номер Roles. Тем не менее, нет примера Role, который имеет смысл, без него также более конкретный вид Role, такой как Employee, Fireman или Teacher. Для этой ситуации вы не только хотите, чтобы Role был абстрактным, вам также нужен covering axiom. Подробнее об этом, пожалуйста, читайте https://stackoverflow.com/a/35950236/2596664.
В основном это зависит от ваших функциональных требований.
Если это имеет смысл в вашем приложении просто иметь простые работники (без назначения их в качестве пожарных, полицейских, или мастеров), то класс не может быть абстрактным, поскольку приложение будет создавать экземпляры только из класс Employee.
Если это не имеет смысла, то есть занятие каждого из ваших сотрудников должно быть известно во время создания, учитываются абстрактные классы. Но все же они не нужны в каждом случае. Самый простой способ убедиться, что оккупация известна, - это моделировать ее как обязательный атрибут. Введение подкласса имеет смысл только в том случае, если существует специализированное поведение для каждого из этих подклассов. Если, например, зарплата пожарных рассчитывается как 50$ * count of the fires he exstinguished, но зарплата полицейских составляет 1000$ + 50 * rank, то вы моделируете абстрактную операцию getSalary() в классе Employee, которая будет конкретно определена и реализована в каждом из подклассов.
Поскольку концепция интерфейса также упоминается в одном из ответов, интерфейс описывает обязательство реализовать определенные операции во всех классах, реализующих этот интерфейс. Это почти то же самое, что абстрактная операция в абстрактном классе. Но абстрактный класс может содержать гораздо больше, чем интерфейс: атрибуты и не абстрактные операции.
Таким образом, эмпирическое правило: для понятий вашего домена, для которых интерфейс и поведение могут быть полностью описаны, используйте не абстрактные классы. Для понятий, для которых могут быть описаны только интерфейсы и поведение, используйте интерфейсы. Для понятий, для которых интерфейсы и часть поведения могут быть описаны, используйте абстрактные классы.
