Константы - 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 заниматься делом, а не тратить рабочее время на эти необремененные смыслом постинги, хоть и веселые

Новые блоги и статьи Все статьи Все блоги /
сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и источниками (напряжения, ЭДС и тока). Найти токи и напряжения во всех элементах. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и. . .

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

	Константы - abstract class или interface? 10.12.2008, 07:51. Показов 7664. Ответов 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