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

Question

Это хорошая практика, чтобы убедиться, что все абстрактные классы имеют имена с префиксом "Abstract"?

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

AbstractShape s = new Rectangle(...);

Я написал в блоге больше мыслей на эту тему здесь .

Answer 5

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

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

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

Answer 6

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

Answer 7

Ответы до сих пор очень полезны и показывают ответственное распространение практики. Я склонен согласиться с тем, что имена не должны указывать реализацию (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 8

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

Answer 9

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

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

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