- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
package ololo.cdn.util;
/**
*
*/
public interface AnswerCodes
{
public static final int CODE_OK = 0;
public static final int CODE_NO_AUTH = 1;
public static final int CODE_NO_ACTION_DONE = 2;
public static final int CODE_ERROR_PARAMETERS = 4;
public static final int CODE_NO_RIGHTS = 8;
public static final int CODE_NOT_UNIQ_PARENT = 16;
public static final int CODE_NOT_EXIST_COLUMNS = 32;
public static final String ANSWER_NO_AUTH = "{\"result\":\"error\",\"code\":\"" + CODE_NO_AUTH + "\"}";
public static final String ANSWER_NO_RIGHTS = "{\"result\":\"error\",\"code\":\"" + CODE_NO_RIGHTS + "\"}";
public static final String ANSWER_NOT_UNIQ_PARENT = "{\"result\":\"error\",\"code\":\"" + CODE_NOT_UNIQ_PARENT + "\"}";
public static final String ANSWER_NOT_EXIST_COLUMNS = "{\"result\":\"error\",\"code\":\"" + CODE_NOT_EXIST_COLUMNS + "\"}";
public static final String ANSWER_OK = "{\"result\":\"ok\",\"code\":\"" + CODE_OK + "\"}";
public static final String ANSWER_NOTHING_DONE = "{\"result\":\"ok\",\"code\":\"" + CODE_NO_ACTION_DONE + "\"}";
}
* JSON из одного поля
* Нужно отдавать этот ответ миллионам пользователей и это реально боттлнек.
Я почему-то уверен что тут ни то ни другое, и скоро этот интерфейс погрязнет в копипасте, а автом запутается в палочках и заболеет синдромом зубочистки.
И кстати constant only interface был взвешен на весах, и найден антипаттерном еще Блохом в первой "effective java".
JSON только пишется, парсить его не надо, ответы простые, не требуют особого экранирования.
В этом случае проблемы с подключением либы перевешивают преимущества. Особенно, если пишешь на C или C++.
Я как-то писал сервис на крестах, который отдавал статистику в json/yaml по http, возня с подключением сторонних либ была оверкиллом.
Про интерфейсы с константами согласен, нинужны.
> Про интерфейсы с константами согласен, нинужны.
Эта борьба ведётся именно с интерфейсами (из-за недопустимости наследования констант по какой-то причине или ещё из-за чего) или с любыми попытками объединить много констант с общим доступом под крылом неймспейсоподобной конструкции?
Немного напоминает крестовый using namespace std;
Хотя это вот очень хорошо показывает что джава не права утверждая что "всё класс". Не всё класс!
Во многих языках (от пайтона до сей) можно хранить константы прямо в модулях, например)
пишутся переменные, которые ты бы не хотел, чтобы люди меняли
fixed
А апперкотом можно?
Сегфолт тебе не даст поменять константу, увы.
_ВСЕ_ можно поменять.
Просто есть контракт: нарушишь контракт (поменяешь константу) -- получишь неверно работающую систему: сегфолт или багу -- не важно.
http://legacy.python.org/dev/peps/pep-0008/#constants
Существует теория что со временем фундаментальные физические константы могут меняться с течением времени и пространства. Для постоянной тонкой структуры вроде даже доказали. По крайней мере это объясняет тонкую подстройку вселенной.
Гость м.б. и прав в том плане что вся наша вселенная мутабельная, в ней нет констант.
Т.е. если мы уж один раз представили Пи, то это навсегда. Даже если эта вселенная перестанет существовать. :)
Так это ж не физическая константа из реального мира, а математическая.
С другой стороны есть теоретические физики, которые думают что мир он так неспроста, а что за всем этим стоит математика, и тогда в мире не окажется никакого а постериори знания, о нем все будет доподленно известно от начала и до конца, без возможности что-либо поменять, без свободы воли... В последнем случае, не будет разницы между математическими константами и физическими, это будет одно и то же.
И нам вообще повезло что у нас такие константы, иначе и жизнь бы не зарадилась, и говнокода-бы тогда никакого не было!
Тсс! Сейчас какой-нибудь питонщик залезет в модуль universe и заманкипатчит что-нибудь.
Я их тут защищаю во-всю, а они :(
Хотя с точки зрения названий имеет место быть несоответствие, это как искусственный естесственный язык: то что выражение является переменной освещает другой аспект этого выражения, нежели тот, о котором говорится в том, что оно - постоянная.
Не только логические. ЛЮБЫЕ выражения.
Все же я считаю что константу следует рассматривать как мнемонику для литерала. Во всяком случае, в программировании. Препроцессор в сях поступает чеснее заменяя #define на литералы еще ДО компиляции, не выделяя для нее память)
var CAPS;
А еще среди питонистов и прочих жабоскриптеров ходят легенды, что если назвать _переменную с подчеркиванием вначале, то она станет приватной.
Чем больше подчеркиваний - тем приватнее.
Да вон тут гость обещал константу изменить. В общем-то, никто ему не запретит вызвать нужную функцию-член и в C++.
То что его легко нарушить не говорит о том, что его нет.
Нарушить можно и в Java (рефлекисей) и в нативном коде залезжи в память как сказал гость, и вообще всё что не прошито железно можно испорить. Константа это мнемоника для литерала а не "переменная, чье значение трудно поменять". Ну что за децкие рассуждения, ё-мае
Да точно так же.
В ECMA6 ввели const, ФФ и хром поддерживают, (опера и сафари понимают) можно юзать.
Можно ругать пайтон за то, что он не форсит контракт в рантайме, даже не пытается! (ну нет там use strict), но говорить что там контракта нет -- это не правда
Половина браузеров по-прежнему не поддерживает, const ВНЕЗАПНО работает как var.
А те что поддерживают, не матерятся при присваивании, и возвращают новое значение в качестве его результата.
Более того крокфорд прямо говорит не использовать _var как приватное.
Но нейминг общепринят.
энумы вообще покрывают 20% кода. я про такой говностиль:
Да ещё и List в качестве возвращаемого значения. Ну хоть не массивы.
Интерфейс это контракт, который класс обязуется реализовать, а не способ импортнуть себе констант. Не нужно карандашом чесать в ухе, он не для того.
Ничего плохого в объединении нет, хотя в 80% случаев ты хочешь enum сделать, на самом деле (привет старым api вроде swing, и новым вроде андроид, там везде int))
В Андроиде инты вместо энумов? Реально? Но зачем?
Видимо сказывается сишный бекграунд разрабов. Любителей спринга тошнит)
Чтоб помочь IDE, они аннотируют параметры. И IDE знает чтоэто не просто int, а туда нужно определенную константу.
C ходу:
Тошнит любителей любых библиотек, появившихся года так после 2006-го.
Очевидно, память экономят. И правильно делают.
enum Foo {
BAR("bar") // 0
SPAM("bar") // 1
String name;
В памяти
Map[Int, String] для поля name (ну или какие там еще поля будут).
Вообще я не верю что там в памяти дело:
Один enum -- один класс. Все значения его -- инстансы-синглтоны. Вот правда если лейаут параметрс сделать енумом а не интом то память кончица?
Очевидно, время. Москва не сразу строилась. В 2011 году вроде заоптимизировали.
http://developer.android.com/training/articles/perf-tips.html
Всмысле нельзя инлайново мапу задать?
В гуаве мождно
Сахара для записи мап там и правда нет, к сожалению (для массивов тока е)