2009-06-17 2 views
28

Мы имеем эту дискуссию в нашей команде о конвенциях кода для Java для:Java интерфейс, AbstractClass и Enum именования

  • interface: Foo или IFoo или FooInterface?

  • abstract: Foo или AbstractFoo?

  • Enums: Foo или FooEnum?

Я в основном пытаюсь отложить свои личные предпочтения :) поэтому причины для поддержки того или иного соглашения очень приветствуются.

ответ

28

В Java: Foo, AbstractFoo и Foo - хотя AbstractFoo может быть просто Foo.

Evidence:

  • java.util.List (интерфейс)
  • java.util.AbstractList (абстрактный класс)
  • java.util.Formatter.BigDecimalLayoutForm (перечисление)

Для интерфейсной части, см Naming Conventions раздел Java Coding Документы конвенций. Тем не менее, речь идет не о переписках и абстрактных классах.

+1

Интерфейсы, насколько мне известно, имеют соглашение об именах JavaBeans, которое диктует, что их следует называть как прилагательное, обычно заканчивающееся на 'able'. Поэтому, если 'Foo' было действием, интерфейс должен быть назван' Fooable'. –

+0

@ RudiKershaw: Не всегда ... и мой опыт в том, что со временем это уменьшилось. Контр-примеры включают «CharSequence», все коллекции, различные DOM-интерфейсы. –

+0

Соглашения JavaBeans применимы только для кода, написанного для программных компонентов многоразового использования плагинов, поэтому многие соглашения, как представляется, в значительной степени игнорируются в стандартных целях.Но мне нравится использовать «Fooable», именование, потому что это просто помогает мне отличить от обычных классов с первого взгляда. –

2

Моя условность:

  • Интерфейс:Foo;
  • AbstractFoo;
  • Enum: обычно Foo но в некоторых случаях FooType.

IFoo очень .Net, а не Java. FooInterface Я никогда не видел.

+0

IFoo также используется во всей кодовой базе Eclipse, которая очень Java, но они вполне могли бы ее поднять из .NET. –

+1

Хотя я указал, что он используется в Eclipse, я не рекомендую его. , Я предпочитаю Foo для IFoo. –

+0

Кроме того, несмотря на то, что Eclipse был написан на Java, это не означает, что они использовали стиль Java. – Cephalopod

3

Моя условность:

  • интерфейс: Foo
  • абстрактный: это зависит FooAdaptor или AbstractFoo или BaseFoo
  • перечисление: Foo или FOOS

я действительно не нравится использование I в именах интерфейсов или даже FooInt erface:

interface FooInterface { 

, как письма:

class FooClass { 

или даже:

abstract class AbstractFooClass { 

это просто многословной.

+0

prolix? – jrharshath

+0

многословный, утомительный и т. Д. – dfa

+0

Названия классов обычно должны быть существительными с особыми именами. Таким образом, Foos, вероятно, не является хорошим именем для перечисления (хотя Foo is). – James

17

интерфейсы: Foo

Причина: Ваш код не должен знать, что они имеют дело с интерфейсом. Написание «IFoo» делает именно это. Вместо этого Foo дает понять, что «Foo» является общим, а объектом позади него может быть «NumFoo» или «StrFoo». Коду действительно не нужно.

абстрактные классы: AbstractFoo

Причина: ваш код никогда не будет использовать этот класс напрямую. Вы всегда будете подклассифицировать этот класс, чтобы сделать любые классы, которые используются другим кодом. Поэтому программисту должно быть ясно, что класс является абстрактным. И какой лучший способ назвать его Abstract! Места, где вам нужно использовать ссылки типа AbstractFoo, вы должны пересмотреть вместо этого интерфейс. (Конечно, это невозможно в C++)

Enums: FooType или FooEnum. Лично FooType лучше, потому что Type более легко относится к «реальному миру», который делает Enum.

Cheers!

5

Никаких специальных соглашений.

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

Названия классов должны просто описывать роль класса, а также, возможно. Это может привести к «естественным» соглашениям об именах. Очень хорошим примером является соглашение об именах интерфейсов Java с суффиксом -able (Iterable, Comparable), но я не хочу представлять результат, если он был универсально применен и Список, Карта и т. Д. Должны были следовать за ним.

+1

, но что делать, если у вас есть много классных классов? конвенции освобождают вас от ненужных значащих имен. Для ветви классов Foo вы просто используете IFoo, AbstractFoo, F oo, ExtendedFoo и счастливы, а без, какие имена вы выберете? Foo, Foo2, Foo3, SuperFoo? – Imaskar

+1

Отсутствие соглашений не означает, что вы * не разрешены *, чтобы назвать такие классы, только чтобы вам не приходилось использовать такие имена повсюду. Но в вашем примере у меня бы был Foo как интерфейс, AbstractFoo необходим, поскольку интерфейсы и классы используют одно и то же пространство имен, но конкретные классы должны иметь отличительные имена, которые описывают их конкретный аспект. –

+2

Пример из Java: Map - это интерфейс, а затем есть AbstractMap, HashMap, TreeMap, LinkedHashMap и т. Д. –

1

О интерфейсах:

Я предпочитаю IFoo, потому что это говорящее имя, говорят вам, это inferface сразу. Во-вторых, для модулей и т. Д.где вы используете интерфейс только для одного класса, класс часто имеет то же имя, что и интерфейс. Затем вы можете использовать Foo extends IFoo. В противном случае вам нужно будет найти имя. Или используйте FooInterface или что-то еще ...

java.util.list как указано использует Foo. Это не проблема, так как классы с различными концепциями реализуют его, тем самым предлагая другое имя (ArrayList, LinkedList ...). Я не совсем уверен, действительно ли я предпочел бы там IList. Незнайка ...: P

+1

В большинстве ситуаций не имеет значения, является ли тип классом или интерфейсом; но ваш класс и интерфейс имеют одно и то же имя, это, вероятно, признак плохого дизайна. – Cephalopod

2

Что касается интерфейсов ввода Personaly как:

Fooable 
+0

Fooable - это foo (with) it, где 'foo' - это глагол. –

13

От my blog:

  • Foo - интерфейс в конечном счете, определяет концепцию, поэтому он должен иметь лучшее название.
  • AbstractFoo - Абстрактная реализация, предназначенная для использования в качестве основы иерархии классов.
  • BaseFoo - Реализация, предназначенная для использования в качестве основы иерархии классов, где базовый класс может использоваться сам по себе, если это необходимо.
  • DefaultFoo - Реализация «по умолчанию», которая подходит для большинства типичных случаев использования.
  • SimpleFoo - «Простая» реализация без неожиданных функциональных возможностей, возможно, в качестве примера или как макет. Простое POJO было бы хорошей «простой» реализацией.
  • Foo - Другие реализации должны описывать, что делает их уникальными.

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

0

Это convetion, используемый в моей команде DEV в ION.

Интерфейс

interface IMyInterface 

:::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::

abstract class MyAbstract 

::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::

enum EMyEnumeration 

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::

+0

Это в ION Trading Inc.? создатель MarketView? – endless