если я называю все свои абстрактные классы AbstractFoo
<br clear="all"/>
работы хорошо также. Преимущество для этого по использованию класса = "ясный" - то, что это просто работает, и Вы не должны устанавливать дополнительные правила в своей CSS для создания его так.
8 ответов
Можно, но я стараюсь этого не делать, поскольку это деталь реализации.
Мне не нравится добавлять подробную информацию о реализации в имена типов и идентификаторов, поскольку такая информация может измениться в будущем. На мой взгляд, лучше называть вещи тем, чем они являются, а не тем, как они реализованы.
Я думаю, что это соглашение об именах используется только потому, что трудно придумать другое хорошее имя. Если у вас уже есть интерфейс под названием «Список», как назвать класс «AbstractList»? Речь идет скорее о том, чтобы избежать конфликтов имен, а затем о подробностях реализации.
Это зависит от ваших соглашений о кодировании.
Вы также можете называть их FooBase или просто Foo, если у вас еще нет интерфейса Foo.
Если учесть, как это работает в .NET framework, нет. Возьмем, к примеру, абстрактный класс Stream. Ничто в названии класса не указывает на то, что он на самом деле абстрактный.
Трудно объяснить, но я использую его только для того, чтобы избежать копирования / вставки одного и того же кода в функциональные классы, а не в объекты типа предметной области.
- AbstractServiceTestCase -> Префикс Abstract кажется полезным
- AbstractAnimal -> Кажется странным и бесполезным
Вы, конечно, должны решить для себя, если на протяжении всего проекта соблюдается одно и то же соглашение.
Я считаю полезным называть классы таким образом. Он отправляет сообщение о том, что они предназначены для подкласса; не создан; содержат код, общий для подклассов и т. д.
Однако это не всегда необходимо. Большинство программистов, вероятно, определили бы «Shape» как абстрактный класс, а «Square», «Circle» и т.д. как конкретный. Но если это не сразу понятно, это полезный совет.
Вам также следует руководствоваться местными соглашениями по программированию и руководствами по стилю.
Я думаю, это частично зависит от того, как вы будете использовать класс. Если он предназначен только для внутреннего использования, чтобы заставить производные классы соответствовать интерфейсу, тогда добавление Abstract перед этим может быть неплохой идеей. Однако, если вы предоставляете фабрику Foo, которая будет предоставлять экземпляры Foo, которые на самом деле являются SpecializedFoo1 или SpecializedFoo2, тогда будет неудобно возвращать экземпляры AbstractFoo.
Пока что ответы очень полезны и продемонстрировать ответственное распространение практики. Я склонен согласиться с тем, что имена не должны указывать на реализацию ( Foo может быть абстрактным классом, который позже был перемещен в интерфейс). Однако при кодировании для меня полезно иметь визуальные подсказки, которые мне нужно предоставить методы для производных классов.
В качестве примера у меня в настоящее время есть иерархия (не спрашивайте об обосновании имен, но они имеют смысл в контекст и отображение на имена элементов XML). Я использую Java, но думаю, что большинство языков будут похожи:
public abstract class Marker {...}
public class Template extends Marker {...}
public class Regex extends Marker {...}
Сейчас я склоняюсь к: