Должен ли я называть все мои абстрактные классы AbstractFoo

Question

Является ли хорошей практикой убедиться, что все абстрактные классы имеют имена с префиксом «Абстрактные»?

Answer 1

Вы можете, но я стараюсь не делать этого, поскольку это деталь реализации.

Мне не нравится добавлять подробную информацию о реализации в имена типов и идентификаторов, поскольку такая информация может измениться в будущем. На мой взгляд, лучше всего назвать вещи такими, какие они есть, а не то, как они реализуются.

Answer 2

Это зависит от ваших правил кодирования.

Вы также можете назвать их FooBase или просто Foo, если у вас еще нет интерфейса Foo.

Answer 3

Если вы рассматриваете, как это делается в .NET Framework, нет. Возьмем, к примеру, абстрактный класс Stream. Ничто в названии класса не указывает, что оно фактически абстрактно.

Answer 4

Мне так полезно назвать классы таким образом. Он отправляет сообщение о том, что они предназначены для подкласса; не инстанцируется; содержат код, общий для подклассов и т. д.

Это не всегда необходимо. Большинство программистов, вероятно, идентифицируют «форму» как абстрактный класс и «квадрат», «круг» и т. Д. Как конкретные. Но если это не сразу понятно, это полезный намек.

Вы также должны руководствоваться местными соглашениями по программированию и руководствами по стилю.

Answer 5

Я думаю, отчасти это зависит от того, как вы будете использовать класс. Если он предназначен только для внутреннего использования, чтобы заставить производные классы соответствовать интерфейсу, добавив Abstract, прежде чем это может быть плохой идеей. Однако, если вы предоставляете фабрику Foo, которая будет предоставлять экземпляры Foo, которые на самом деле являются SpecializedFoo1 или SpecializedFoo2, то неудобно возвращать экземпляры AbstractFoo.

Answer 6

Я думаю, что это соглашение об именах используется только потому, что трудно найти другое доброе имя. Если у вас уже есть интерфейс под названием «Список», как можно назвать класс «AbstractList»? Это больше об избежании конфликтов имен, а затем о деталях реализации.

Answer 7

Kinda трудно объяснить, но я использую его только для того, чтобы избежать копирования и вставки одного и того же кода в функциональные классы, а не в нечто вроде объектов домена.

• AbstractServiceTestCase -> Конспект префикс кажется полезным
• AbstractAnimal -> Кажется странным и бесполезным

Вы должны конечно решить для себя, до тех пор, как же конвенции следует на протяжении всего проекта ,

Answer 8

Ответы до сих пор очень полезны и показывают ответственное распространение практики. Я склонен согласиться с тем, что имена не должны указывать на реализацию (Foo может быть абстрактным классом, который позже был перенесен в интерфейс). Однако это полезно для меня, когда кодирование имеет визуальные подсказки, которые мне необходимы для предоставления методов для производных классов.

В качестве примера у меня в настоящее время есть иерархия (не спрашивайте об обосновании имен, но они имеют смысл в контексте и отображают имена XML-элементов).Я использую Java, но я думаю, что большинство языков будут похожи:

public abstract class Marker {...} 
public class Template extends Marker {...} 
public class Regex extends Marker {...} 

Я сейчас тенденция к:

public abstract class Marker {...} 
public class TemplateMarker extends Marker {...} 
public class RegexMarker extends Marker {...} 

вместо

public abstract class AbstractMarker {...} 
public class Template extends AbstractMarker {...} 
public class Regex extends AbstractMarker {...} 

или

public abstract class AbstractMarker {...} 
public class TemplateMarker extends AbstractMarker {...} 
public class RegexMarker extends AbstractMarker {...} 

Я лично помню, что Marker - абстрактная функциональная концепция и что подклассы представляют собой конкретные реализации.

Answer 9

Я бы не стал называть абстрактные классы Абстрактным по следующей причине:

Каждых Прямоугольником является Формой. Всюду вы можете использовать фигуру, вы можете использовать прямоугольник. Код, который имеет дело с прямоугольником (но может также иметь дело с кругами) может выглядеть следующим образом:

Shape s = .....; 
s.drawTo(myGraphicsContext); 

Использование объекта (например, прямоугольник) в любом месте вы можете использовать обобщение этого (например, Shape) является важным часть объектно-ориентированной концепции и известная как Liskov Substitution Principle. (Также очевидно: какое предложение или логика будет делать заявления о фигурах, но тогда не применимы к прямоугольникам?)

Если вы назвали обобщение AbstractShape, этот принцип нарушен. Прямоугольник не является AbstractShape. Если что-нибудь, это «Бетонная форма»! Прямоугольник не абстрактный (в смысле «Я не знаю, какой тип формы это. Может быть прямоугольником, может быть что-то еще»). Код, использующий AbstractShape затем читает неправильно:

AbstractShape s = new Rectangle(...); 

Я с большим блоге мысли на эту тему here.