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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В отличие от:

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

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

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

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

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

protected abstract SomeClass { }

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

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

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

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

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

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

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

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

Я не Java-разработчик (INAJD?) И не знаю стандартную номенклатуру для таких вещей, но я думаю Task, что это звучит достаточно абстрактно, чтобы он мог оставаться один как есть.

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

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

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