Константы - abstract class или interface?

@alskor · Регистрация: 24.08.2008

Студворк — интернет-сервис помощи студентам

требуется создать файл, который будет содержать только константы.
сейчас это сделано как
public abstract class ProjectConstants
(в этом классе переменные объявлены как public static final)

хотелось бы услышать аргументированное мнение, как лучше делать такие вещи - через abstract class или interface?

10.12.2008, 08:49

Это дело вкуса. Единственое преимущество интерфейсов что не надо добавлять public static final перед каждым объявлением константы.

@scroodge · 10.12.2008, 09:20

ИМХО использовать для project констант лучше интерфейс.
При этом ты любой класс в проекте сможешь объявить как implements ProjectConstants и юзать эти константы как свои ( не ссылаясь на интерфейс ).C абстрактным классом , сам понимаешь ,этот номер не всегда пройдёт.

10.12.2008, 09:54

Я бы не советовал использовать константы, подключая их к классу через implements. Во первых если константы брать из двух интерфейсов, то может возникнуть конфликт имен, кроме того непонятно откуда эта константа взялась. А во вторых класс, реализующий интефейс из одних констант IMHO абсурд. Хотя опять же кому как нравиться.

@alskor · 10.12.2008, 10:29 **[ТС]**

единственный разумный аргумент ЗА интерфейсы я слышал такой:
не надо использовать префикс перед именами констант, типа
ProjectConstants.CONSTANT1

@mr_dronski · 10.12.2008, 13:50

с другой стороны, с префиксом лучше: если я имею SessionConstants и ChartConstants, то для логики лучше оставлять класс-префикс. Попробуйте потом разобраться в проге через пару месяцев, а если еще и без IDE, а просто быстренько глянуть.

а так, в общем, пофиг.

11.12.2008, 22:03

Лучше интерфейс - их можно исполнять много, а класс наследовать можно только один.

@mr_dronski · 12.12.2008, 00:56

Уважаемый Ravil

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

просто пишется ClassWithConstanst.SOME_CONSTANT

все, и никаких implements или extends

12.12.2008, 01:16

И так можно конечно, не спорю. Но мне через интерфейс как-то правильнее кажется, хотя бы потому что впереди имя класса не надо ставить. А если в разных интерфейсах одна и та же константа встретится, об этом компилятор должен сообщить.

12.12.2008, 06:20

Я не пойму о чем тут спор идет?
Если у автора в проекте например предполагается наследование больше чем одного класса то тут и последнему идиоту понятно что надо реализовывать интерфейсы а Вы тут уважаемые программисты развели такую
дискуссию что классикам макрсизма - ленинизма отдыхать надо.
В чем смысл интерфейсов?Чтобы избежать множественного наследования объектов.ТО есть автору или надо быть архитектором проекта или обсудить с ним вопросы связанные с проектом.А потом уже решать что делать с константами.Я бы все таки остановился на интерфейсе потому как если это будет объект то можете сказать до свидания остальным объектам.

12.12.2008, 06:48

2 mr_donski
Ваше предложение хорошо когда у вас 2-3 константы для объекта.Но это не красиво когда необходимо исользовать константы проекта в целом для опрделенного количества классов.Напишите интерфейс и имплементриуйте скока нада(и скока не нада то же - щютка)

@mr_dronski · 12.12.2008, 16:11

2 mishgun

welcome back, guru

в отпуске был, что ли?

весело, на, казалось бы, пустом месте получили hot topic

) пообщаца хочется, чтобы не заскучать

а насчет темы, так давайте уже все константы для БОЛЬШОГО проекта хранить в базе данных. большому проекту - большие (и не всегда уместные, кстати) решения

)

cheers

@alskor · 14.12.2008, 06:28 **[ТС]**

2 mishgun:
а зачем все-таки интерфейс в таком случае?
итого - ЗА интерфейс:
не надо писать префикс типа ProjectConstantsClass.CONSTANT1

ЗА класс (мне кажется, самый весомый аргумент):
(цитата mr. dronski)
'с другой стороны, с префиксом лучше: если я имею SessionConstants и ChartConstants, то для логики лучше оставлять класс-префикс. Попробуйте потом разобраться в проге через пару месяцев, а если еще и без IDE, а просто быстренько глянуть'

15.12.2008, 04:24

Я по моему еаписал что в случае нитерфейса вы избавляетесь от возможной проблемы когда вам вдруг понадобится наследовать ещё один класс.
А почему бы вам не хранить это дело для проекта в properties файле?

@alskor · 15.12.2008, 05:58 **[ТС]**

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

import ProjectConstants;
...
x = ProjectConstants.AAA;

в упор не пойму, зачем его наследовать

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

@mr_dronski · 15.12.2008, 14:04

вдогонку, Properties не катят в J2EE проектах (по спецификации нельзя обращаться к файловой системе). С servlets, конечно, прокатит. Предвкушая ваши постинги: можно скомпилить пропертиз в ResourceBundle, и тут мы возвращаемся к тому месту, откуда начали

regards

@Danissimo · 15.12.2008, 19:39

Вопрос исключительно идеологии создаваемого дизайна. Например, константы, определенные в javax.swing.WindowConstants, наследуются в визуальных компонентах. В то же самое время константы, характеризующие символы из java.lang.Character, размещены исключительно в самом классе.

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

На мой взгляд, ошибка -- константы целого проекта. Проект -- совокупность подсистем. Дирижер этими подсистемами -- клиент. Глобальный такой. У него свои константы. Каждая подсистема состоит из подсистем. И там тоже свой локально-глобальный клтент. Для него свои константы. Ну. и раздевай матрешку дальше.

16.12.2008, 04:36

Я что всезнающий господь Бог что бы знать что у вас проект разрабатывается для J2EE? Писать надо было в таком случае а не умничать потом

16.12.2008, 08:45

Тема исчерпала себя еще десять постов назад. Предлагаю для трепа создать новую, например: 'Нужны ли в Java Generics' или 'Как снизить пожераемость памяти в Swing программах'.

@mr_dronski · 16.12.2008, 15:00

или как заставить developers заниматься делом, а не тратить рабочее время на эти необремененные смыслом постинги, хоть и веселые

Новые блоги и статьи Все статьи Все блоги /
Отправка уведомления на почту при изменении наименования справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере изменения наименования типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .	SDL3 для Desktop (MinGW): Вывод текста со шрифтом TTF с помощью библиотеки SDL3_ttf на Си и C++ 8Observer8 24.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-text-sdl3-c. zip finish-text-sdl3-cpp. zip
Жизнь в неопределённости kumehtar 23.03.2026 Жизнь — это постоянное существование в неопределённости. Например, даже если у тебя есть список дел, невозможно дойти до точки, где всё окончательно завершено и больше ничего не осталось. В принципе,. . .	Модель здравоСохранения: работники работают быстрее после её введения. anaschu 23.03.2026 geJalZw1fLo Корпорация до введения программа здравоохранения имела много невыполненных работниками заданий, после введения программы количество заданий выросло. Но на выплатах по больничным это. . .	Контроль уникальности заводского номера Maks 23.03.2026 Алгоритм контроля уникальности заводского (или серийного) номера на примере нетипового документа выдачи шин для спецтехники с табличной частью, разработанного в конфигурации КА2. Данные берутся из. . .	Хочу заставить корпорации вкладываться в здоровье сотрудников: делаю мат модель здравосохранения anaschu 22.03.2026 e7EYtONaj8Y Z4Tv2zpXVVo https:/ / github. com/ shumilovas/ med2. git

@alskor 0 / 0 / 2 Регистрация: 24.08.2008 Сообщений: 119

	Константы - abstract class или interface? 10.12.2008, 07:51. Показов 7728. Ответов 25 Метки нет (Все метки) требуется создать файл, который будет содержать только константы. сейчас это сделано как public abstract class ProjectConstants (в этом классе переменные объявлены как public static final) хотелось бы услышать аргументированное мнение, как лучше делать такие вещи - через abstract class или interface? 0

Eugeny
	10.12.2008, 08:49
	Это дело вкуса. Единственое преимущество интерфейсов что не надо добавлять public static final перед каждым объявлением константы.

@scroodge 0 / 0 / 4 Регистрация: 14.08.2007 Сообщений: 307
	10.12.2008, 09:20
	ИМХО использовать для project констант лучше интерфейс. При этом ты любой класс в проекте сможешь объявить как implements ProjectConstants и юзать эти константы как свои ( не ссылаясь на интерфейс ).C абстрактным классом , сам понимаешь ,этот номер не всегда пройдёт. 0

Eugeny
	10.12.2008, 09:54
	Я бы не советовал использовать константы, подключая их к классу через implements. Во первых если константы брать из двух интерфейсов, то может возникнуть конфликт имен, кроме того непонятно откуда эта константа взялась. А во вторых класс, реализующий интефейс из одних констант IMHO абсурд. Хотя опять же кому как нравиться.

@alskor 0 / 0 / 2 Регистрация: 24.08.2008 Сообщений: 119
	10.12.2008, 10:29 [ТС]
	единственный разумный аргумент ЗА интерфейсы я слышал такой: не надо использовать префикс перед именами констант, типа ProjectConstants.CONSTANT1 0

@mr_dronski 4 / 4 / 1 Регистрация: 13.08.2008 Сообщений: 931
	10.12.2008, 13:50
	с другой стороны, с префиксом лучше: если я имею SessionConstants и ChartConstants, то для логики лучше оставлять класс-префикс. Попробуйте потом разобраться в проге через пару месяцев, а если еще и без IDE, а просто быстренько глянуть. а так, в общем, пофиг. 0

Dervish
	11.12.2008, 22:03
	Лучше интерфейс - их можно исполнять много, а класс наследовать можно только один.

@mr_dronski 4 / 4 / 1 Регистрация: 13.08.2008 Сообщений: 931
	12.12.2008, 00:56
	Уважаемый Ravil Если Вы мне объясните, нафига нужно наследовать класс, в котором только константы, я почерпну для себя немало нового в яве. просто пишется ClassWithConstanst.SOME_CONSTANT все, и никаких implements или extends 0

Dervish
	12.12.2008, 01:16
	И так можно конечно, не спорю. Но мне через интерфейс как-то правильнее кажется, хотя бы потому что впереди имя класса не надо ставить. А если в разных интерфейсах одна и та же константа встретится, об этом компилятор должен сообщить.

mishgun
	12.12.2008, 06:20
	Я не пойму о чем тут спор идет? Если у автора в проекте например предполагается наследование больше чем одного класса то тут и последнему идиоту понятно что надо реализовывать интерфейсы а Вы тут уважаемые программисты развели такую дискуссию что классикам макрсизма - ленинизма отдыхать надо. В чем смысл интерфейсов?Чтобы избежать множественного наследования объектов.ТО есть автору или надо быть архитектором проекта или обсудить с ним вопросы связанные с проектом.А потом уже решать что делать с константами.Я бы все таки остановился на интерфейсе потому как если это будет объект то можете сказать до свидания остальным объектам.

mishgun
	12.12.2008, 06:48
	2 mr_donski Ваше предложение хорошо когда у вас 2-3 константы для объекта.Но это не красиво когда необходимо исользовать константы проекта в целом для опрделенного количества классов.Напишите интерфейс и имплементриуйте скока нада(и скока не нада то же - щютка)

@mr_dronski 4 / 4 / 1 Регистрация: 13.08.2008 Сообщений: 931
	12.12.2008, 16:11
	2 mishgun welcome back, guru в отпуске был, что ли? весело, на, казалось бы, пустом месте получили hot topic ) пообщаца хочется, чтобы не заскучать а насчет темы, так давайте уже все константы для БОЛЬШОГО проекта хранить в базе данных. большому проекту - большие (и не всегда уместные, кстати) решения ) cheers 0

@alskor 0 / 0 / 2 Регистрация: 24.08.2008 Сообщений: 119
	14.12.2008, 06:28 [ТС]
	2 mishgun: а зачем все-таки интерфейс в таком случае? итого - ЗА интерфейс: не надо писать префикс типа ProjectConstantsClass.CONSTANT1 ЗА класс (мне кажется, самый весомый аргумент): (цитата mr. dronski) 'с другой стороны, с префиксом лучше: если я имею SessionConstants и ChartConstants, то для логики лучше оставлять класс-префикс. Попробуйте потом разобраться в проге через пару месяцев, а если еще и без IDE, а просто быстренько глянуть' 0

mishgun
	15.12.2008, 04:24
	Я по моему еаписал что в случае нитерфейса вы избавляетесь от возможной проблемы когда вам вдруг понадобится наследовать ещё один класс. А почему бы вам не хранить это дело для проекта в properties файле?

@alskor 0 / 0 / 2 Регистрация: 24.08.2008 Сообщений: 119
	15.12.2008, 05:58 [ТС]
	mishgan, прошу прощения, но мне кажется, ты не очень внимательно прочитал предыдущие сообщения. для того, чтобы использовать константы из класса, скажем, ProjectConstants, этот класс совсем не обязательно наследовать. вполне достаточно сказать в своем классе import ProjectConstants; ... x = ProjectConstants.AAA; в упор не пойму, зачем его наследовать ну разве чтобы избавиться от префиксов, но про это уже говорили в связи с интерфейсами. 0

@mr_dronski 4 / 4 / 1 Регистрация: 13.08.2008 Сообщений: 931
	15.12.2008, 14:04
	вдогонку, Properties не катят в J2EE проектах (по спецификации нельзя обращаться к файловой системе). С servlets, конечно, прокатит. Предвкушая ваши постинги: можно скомпилить пропертиз в ResourceBundle, и тут мы возвращаемся к тому месту, откуда начали regards 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	15.12.2008, 19:39
	Вопрос исключительно идеологии создаваемого дизайна. Например, константы, определенные в javax.swing.WindowConstants, наследуются в визуальных компонентах. В то же самое время константы, характеризующие символы из java.lang.Character, размещены исключительно в самом классе. Мое убеждение, константы должны быть привязаны к моделируемой сущности. Если ситуация, похожая на Swing, то и поступать надо, как в Swing. На мой взгляд, ошибка -- константы целого проекта. Проект -- совокупность подсистем. Дирижер этими подсистемами -- клиент. Глобальный такой. У него свои константы. Каждая подсистема состоит из подсистем. И там тоже свой локально-глобальный клтент. Для него свои константы. Ну. и раздевай матрешку дальше. 0

mishgun
	16.12.2008, 04:36
	Я что всезнающий господь Бог что бы знать что у вас проект разрабатывается для J2EE? Писать надо было в таком случае а не умничать потом

Eugeny
	16.12.2008, 08:45
	Тема исчерпала себя еще десять постов назад. Предлагаю для трепа создать новую, например: 'Нужны ли в Java Generics' или 'Как снизить пожераемость памяти в Swing программах'.

@mr_dronski 4 / 4 / 1 Регистрация: 13.08.2008 Сообщений: 931
	16.12.2008, 15:00
	или как заставить developers заниматься делом, а не тратить рабочее время на эти необремененные смыслом постинги, хоть и веселые 0