2009-04-07 3 views
3

Мне кажется, что было бы полезно иметь возможность сказать с первого взгляда, что класс является абстрактным и не предназначен для непосредственного создания так же, как полезно, чтобы иметь возможность легко идентифицировать интерфейс.Префикс абстрактных классов с интерфейсами «A» с префиксом «I»?

Вопрос в том, почему «AFourLeggedAnimal: IAnimal» не улавливается? Это просто из-за возможной путаницы (которую я только заметил при написании), например, запутав ее как «четырехногий животное» вместо «абстрактного класса FourLeggedAnimal»? Или это нечто большее?

Начиная с Java в школе до C# на работе, я нашел, что соглашение об именах префикса «I» чрезвычайно полезно при просмотре списка классов, и мне кажется, что было бы удобно различать бетон и небетонные классы с первого взгляда, без необходимости смотреть на код.

+0

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

+0

Я предпочитаю суффиксы для классификации. Я все еще помню индекс в ссылке MFC. Записей почти не было, кроме раздела с буквой C, содержащего базиллион записей для классов: CDocument, CView, CWindow и т. Д. –

ответ

12

Используйте суффикс "Base", как отмечает Джоэл. Если у вас есть много в вашем проекте, это довольно легко отличить друг от друга:

public abstract AnimalBase 
{ 
    public AnimalType AnimalType { get; set; } 
} 

public abstract HorseBase : AnimalBase 
{ 
    public HoovesManufacturer HoovesManufacturer { get; set; } 
} 

public class Pony : HorseBase 
{ 
    public Pony() 
    { 
    } 
} 
+0

lol, я думаю, это один из тех моментов «духа». Я полностью забыл о суффиксе базы, хотя я знал это в какой-то момент. Маркировка считается принятой, так как вы даете хороший пример. – Davy8

+0

HoovesManufacturer? Это будет плотина и сир? – tvanfosson

+0

@tvanfosson: lol Я написал его на Opera Mobile, без проверки орфографии. – eduncan911

13

Я предпочитаю суффикс с «Основанием».

+0

Мой вопрос - зачем база? –

+0

Потому что почти всем учили ООП, используя «базовые» классы в терминологии. Это будут понимать другие программисты. –

+1

Но что, если это не базовый класс?Как и интерфейс, класс, реализующий интерфейс, и подкласс класса. Вы все еще префикс с базой? –

4

Потому что, честно говоря, уже принят шаблон для обозначения абстрактных классов ;-) Он имеет суффикс «Base», такой как MyControlBase или FooBase.

-Oisin

+0

Это подразумевалось в его вопросе. Он спрашивает о C#: «от java до C# ...» – x0n

2

В Java много «абстрактных» классов начинаются с «Abstract», например, - AbstractList т.д.

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

Я лично считаю префикс «I» для интерфейсов довольно уродливым. Я считаю, что не следует пытаться кодировать такие данные в имени класса. Я считаю, что, объединяя детали реализации с именем интерфейса, вы получаете действительно содержательные, но короткие имена. Прекрасным примером является Java-карта, HashMap и т. Д., Все это очень условно и красноречиво.

+1

Я нахожу, что это упрощает работу с кодовой организацией. В вашем примере с картой, не глядя ни на код, ни на консультацию с JavaDocs, я не могу сказать, что Map somemap = new Map() недействителен и что я должен искать класс, который реализует Map – Davy8

+0

Я его нахожу особенно полезно при попытке понять незнакомую базу кода, легче понять, как все сочетается. – Davy8

+0

Из названия, например «Карта», должно быть очевидно, что он описывает интерфейс и не является конкретным. «Хэш» в HashMap четко показывает стратегию реализации Карты. Используя комбинационную стратегию, когда имена ваших интерфейсов имеют более короткие имена, чем конкретные классы. Это прекрасно ... –

1

I префикс уродливый, но, к сожалению, это соглашение Microsoft. В идеальном мире мы все должны программировать интерфейсы. Конкретные классы имели бы суффикс Impl или что-то, что бы отличить их от интерфейса или абстрактного класса (и нам все равно, потому что наши контейнеры IoC будут обрабатывать это для нас!)

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

Но, увы, мы не живем в таком идеальном мире.

Смежные вопросы