Должен ли я добавить префикс «Abstract» в мои абстрактные классы? [закрыто]


20

Предположим, у меня есть абстрактный класс с именем Task.

Есть ли стандарт или соглашение, которое предложило бы мне назвать его AbstractTaskвместо этого?


Соглашения об именах, перечисленные здесь: oracle.com/technetwork/java/codeconventions-135099.html предлагают «нет», хотя эта ссылка: stackoverflow.com/questions/1006332/… говорит, что вы могли бы, и если бы вы это сделали, это не было бы ужасно.
FrustratedWithFormsDesigner

В C # стандартным соглашением является суффикс с помощью * Base.
День

Ответы:


26

Согласно Эффективной Java Блоха (пункт 18) префикс Abstract является соглашением, используемым в особом случае.

Вы можете комбинировать достоинства интерфейсов и абстрактных классов, предоставляя абстрактный класс реализации скелета для каждого нетривиального интерфейса, который вы экспортируете. ... По соглашению, скелетные реализации называются AbstractInterface, где Interface - это имя интерфейса, который они реализуют.

Но Блох также указывает, что название SkeletalInterface имело бы смысл, но приходит к выводу, что

Абстрактное соглашение теперь твердо установлено.

Как указывалось в других ответах, в целом нет причин применять это соглашение об именах ко всем абстрактным классам.


15

Там нет конвенции. Это все о том, что поможет вам, как разработчику, быстрее и лучше писать код и помогать другим понимать ваш код.

Спросите людей, которые будут видеть и поддерживать код. Что бы они предпочли увидеть? Что облегчит им? Затем назовите его исходя из того, что они хотели бы.

С другой стороны, условные обозначения кода для языка программирования Java: 9. Условные обозначения не предлагают никаких требований:

Имена классов должны быть существительными, в смешанном регистре с заглавной первой буквой каждого внутреннего слова. Постарайтесь, чтобы названия ваших классов были простыми и наглядными. Используйте целые слова, избегайте сокращений и аббревиатур (если только аббревиатура не используется намного шире, чем полная форма, такая как URL или HTML).


13

Нет. Intellisense легко скажет мне, является ли он абстрактным, так что вы просто нарушаете DRY здесь.


21
-1 Добавление abstractк имени класса не нарушает СУХОЙ, и не все используют интеллигентность. Например, что вы делаете, если вы читаете код на веб-странице, или если он является частью патча, который вы просматриваете в текстовом редакторе или во внешнем инструменте сравнения?
Брайан Оукли

10
@ Брайан: Конечно, это нарушает СУХОЙ. abstract class AbstractName? Понятно имеет «абстрактный» дважды. И если вы не используете Intellisense, то это ваша проблема, все остальные используют вменяемые инструменты для просмотра кода.
DeadMG

13
"Everbody"? Большинство людей, которых я знаю, используют emacs и vi, а некоторые используют eclipse. Сказать что-то - «ваша проблема» - не совсем определение командной работы. Моя плохая точка зрения заключалась в том, что вы не можете просто установить общее правило и сказать, что это так. У разных команд разные требования, и не всем нужна помощь с intellisense. Кроме того, как я уже говорил, во многих случаях вы просматриваете код в каком-либо инструменте, кроме основного редактора или IDE.
Брайан Оукли

1
+1 однозначно нарушает СУХОЙ. Полагаться на Intellisense довольно сложно, но любой, кто использует базовый класс, должен хотя бы посмотреть, что они расширяют как часть SOLID.
Гэри Роу

8
@BryanOakley, почему бы не сделать публичным и окончательным? Имя класса тогда будет выглядеть как PublicAbstractPersonThatImplementsInterfaceHuman. Хм, не совсем уверен, что это хорошо. Но я согласен, что нет ничего такого, как универсальное соглашение - используйте все, что увеличивает коллективную производительность команды.
Апурв Хурасия

9

Это в некоторой степени вопрос предпочтения (но это плохая практика), но большинству людей не нравится видеть часть квалификаторов в названии класса.

Большинство IDE в любом случае сделают эту информацию легко доступной для вас, поэтому указывать ее имя не обязательно, и будет проще ее пропустить. Это напоминает венгерскую нотацию для именования переменных, и это, безусловно, считается плохой формой в наши дни. Я рекомендую просто позвонить Task.


9

В .NET часто используется «Base» в качестве суффикса для обозначения абстрактного базового класса. Я бы поспорил с другими ответами относительно того, является ли это обычной практикой в ​​Java.


1
+1 для суффиксов "Base" и "Impl". Они делают структурную точку (абстрактный класс будет основой для чего-то).
вс

7
@vski: нет, я категорически не согласен: это бесполезная боль в заднице. Как правило, совершенно нормально называть ваш интерфейс или базовый класс с общим именем, описывающим интерфейс, и вашу конкретную реализацию с более явными именами.
Хайлем

3
Я склонен использовать ... Base для базового класса за интерфейсом. Доброе имя уже занято интерфейсом, а базовый класс в любом случае не используется клиентским кодом.
звездный синий

1
@Haylem многие шаблоны проектирования Java используют интерфейсы только с одной ожидаемой реализацией. Impl - очень полезный суффикс в этих случаях.
funkybro

Что касается использования Impl, см. Default против Impl - держитесь подальше от Impl! Использование Base в качестве суффикса (например, TaskBase) подразумевает, что базовый класс является шаблоном, а не языковой конструкцией.
Гэри Роу

8

На мой взгляд, имя сущности должно содержать не информацию о его типовой структуре, а о его семантике. Поэтому не имеет смысла определять ваш класс как «AbstractSomething», если абстракция не является частью его цели времени выполнения. То, что это базовый абстрактный класс, видно программисту, и его не нужно отражать в названии.

Однако if делает идеальным называть реализацию абстрактной фабрики AbstractFactory, потому что это относится к намерениям класса.

В целом, придерживайтесь соглашения об именовании, которое поможет передать больше информации о цели вашего класса.

Точно так же, держитесь подальше от SomethingImpl. Нам все равно, что это реализация, а не базовый класс. Если ваша иерархия классов спроектирована правильно для наследования, то кто-то может наследовать от нее. Конечно, в них не было бы никакой ценности, добавляя больше суффиксов «Impl» или других артефактов. Также нет никакого смысла в добавлении суффикса «Interface» или префикса «I».

Рассмотреть возможность:

IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl

В отличие от:

Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
                                   <-- Ferrari
                                   <-- Trabi

Я предпочитаю последнее на сегодняшний день.


Это, в некотором отношении, подобно вопиющего злоупотребления в венгерской нотации , что последний дал ему свою плохую репутацию , так как люди ошибочно начали интерпретировать это как требование разработчикам префикс их переменных с индикатором типа переменной. Хотя иногда это может иметь свое применение (в основном, если вам лень искать определение типа), в большинстве случаев это бесполезно. Первоначальная идея Симони с Венгерской нотацией состояла в том, чтобы использовать ее как мнемонику, чтобы напомнить разработчику о возможностях объекта, а не о его типе.


3

Хорошее практическое правило - не включать свойства в имя, которые очевидны из синтаксиса. Поскольку в Java вам нужно пометить абстрактный класс метко названным abstractключевым словом, я бы не включил его в имя. Например, в C ++ этот случай не так однозначен, но по крайней мере компилятор сообщит вам, когда вы неправильно использовали абстрактный класс. В чем-то похожем на Python, явное именование абстрактного класса как такового - неплохая идея.

Обычное исключение из правила, когда имя неоднозначно. Если по какой-либо причине существует конкретный подкласс Task(в других примерах это может быть более разумным, но неважно), тогда обязательно используйте AbstractTask.


... или интерфейс, такой как Listи AbstractListкласс (который его реализует).

3
protected abstract SomeClass { }

Это говорит мне, что это абстрактный класс. Добавление префикса является тавтологией и анти-паттерном и не подходит в большинстве случаев, см. Ссылку, где говорится, например, об package localисключении.

В большинстве случаев Abstractклассы не должны быть частью общедоступного API, если это действительно есть веская причина, и веская причина должна содержать явно хорошее имя, отличное от AbstractSomeClass.

В большинстве случаев, если вы не можете придумать более описательное имя, вам, вероятно, нужно сделать редизайн.


0

Мои пять центов, возможно, у вас будут реализации этого абстрактного класса, и они будут называться SomeSpecificTask, TaskWithBubbles, StrangeTask и т. Д. Таким образом, между вашим абстрактным «Задачей» и ними не будет конфликта имен.

Кроме того, «абстрактное» слово относится к синтаксису языка, а не к сущностям бизнес-домена, поэтому я бы предпочел не использовать его как часть имени.

С другой стороны, в одном ответе здесь я увидел отрывок из J.Bloch Effective Java, в котором говорится, что использование «абстрактного» как части имени является общепринятой практикой. Это может быть так. Но в любом случае в официальных соглашениях по Java-коду ничего об этом нет.


public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E>- нельзя использовать Listв качестве имени для AbstractListкласса, потому что это имя интерфейса. Это хорошо зарекомендовавшая себя практика и часть официального кода Java, который используется, когда что-то, что реализует интерфейс, может расширять или не расширять абстрактный класс (который также реализует (некоторые из) интерфейс).

-1

Если вы работаете в команде, то вся команда должна решить, стоит ли вам добавлять префикс абстрактных классов к «Абстрактному».

Если вы работаете самостоятельно, то это полностью зависит от вас, а не от меня или кого-либо еще на этом сайте.



-2

Что если вы хотите написать абстрактный AbstractSyntaxTreeкласс? Или просто аннотация SyntaxTree?

Это не принято и может легко запутать людей.


-2

Я сделал это. Я добавил «Abstract» в качестве префикса к моему абстрактному классу с именем AbstractOperation. Причина, по которой я это сделал, была в том, что был еще один пакет с неабстрактным классом, названным Operation, и он помог моей команде и программистам, которые позже взялись за дело, избежать любой путаницы между ними.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.