Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
да это не самое страшное. хуже всего то, что оно на нас еще и обидилос, мол...
а лучше анекдот (осторожно, скотоложство!): Наташа Ростова спрашивает у поручика Ржевского:
-поручик, расскажите, чем вы вчера занимались?
-ну, например, вчера мы ебали лошадей...
Наташа в слезах убегает и жалуется капитану:
-фу, капитан, поручик Ржевский такой пошлый, низкий человек!
Капитан:
-низкий?? вот уж нет! например, мы вчера лошадей ебали. Так вот, все на табуретах, а он таак!
в общем, мы мордой не вышли, не завшивоинтеллегентили до ее уровня.
Я заинтригован. Хочу услышать ответ автора, зачем. Если, конечно, автор - не декомпилятор. Понятно, что делать этого руками не нужно ни при каких обстоятельствах. Интересен ответ...
Хорошо говорить так, когда работаешь один. Когда в команде 85 человек, наверняка найдётся десяток-другой человек, стремящихся привнести новый стиль. Я понимаю, что для статического анализа кода, крайне полезного для крупных проектов, это большой бенефит, но читать такой код, на мой взгляд, довольно затруднительно.
судя по переопределённым методам - штоп потом в коллекцию сложить. скорее всего - в hashmap, в виде ключей, а значениями будут обработчики в зависимости от предопределенных value. хотя там логичнее бы смотрелся enum. хотя изврат, конечно, тот еще.
"value".hashCode() - отдельная няшечка.
Известно зачем.
Создаем final Property checkerExample=new PropertyImpl ("adequate");
Потом, значит, достаем откуда-то рефлексией аннотацию типа Property, которую мы написали в коде.
@Property ("mudak") User animeGovno;
Property mudakAnno=Govnokod.class.get...(...);
И сравниваем, для этого собстно hashCode и equals.
assert(!checkerExample.equals(mudakAnno) );
Примерно так.
Единственное, чего я опасаюсь - код написал сам tir, и сейчас он начнёт убеждать нас в том, что этот подход хорошо работает, несмотря на то, что код "не следует принятым правилам" (tm).
Код не мой, а ребят из неизвестной конторы - Google. Из малознакомого фреймворка - Google Guice. Единственное, что сделал я - переименовал класс, чтобы в глаза не бросалось. В оригинале было не Property, а Named.
Цитирую кусок документации:
Guice comes with a built-in binding annotation @Named that uses a string:
public class RealBillingService implements BillingService {
@Inject
public RealBillingService(@Named("Checkout") CreditCardProcessor processor,
TransactionLog transactionLog) {
...
}
To bind a specific name, use Names.named() to create an instance to pass to annotatedWith:
Возможно, это не такой уж и говнокод, как мне показалось сначала. Идея ясна, можно было бы обойтись без извращений и дырок в абстракциях, но тогда API было бы не таким удобным. Ребятам из google наверняка не легко далось это решение 🙂
Clojure решает подобные проблемы отсутствием лишних абстракций: метаинформация символов представляется там в виде обычной мапы.
Вот в weld например такая техника используется в селекторах. Т.к. нельзя написать просто new Annotation() то приходится писать реализацию интерфейса аннотации...
@Test(expectedException = TirTupitException.class)
http://upload.wikimedia.org/wikipedia/commons/5/5c/Michael_Pacher_004.jpg
а лучше анекдот (осторожно, скотоложство!):
Наташа Ростова спрашивает у поручика Ржевского:
-поручик, расскажите, чем вы вчера занимались?
-ну, например, вчера мы ебали лошадей...
Наташа в слезах убегает и жалуется капитану:
-фу, капитан, поручик Ржевский такой пошлый, низкий человек!
Капитан:
-низкий?? вот уж нет! например, мы вчера лошадей ебали. Так вот, все на табуретах, а он таак!
в общем, мы мордой не вышли, не завшивоинтеллегентили до ее уровня.
это что-то из ролевых игр?
плюсанул.
Понятно, что делать этого руками не нужно ни при каких обстоятельствах. Интересен ответ...
есть мнение, что аннотации в яве изуродовали язык, что они там не нужны, запутывают логику и вообще развращают.
Начинаю потихоньку подумывать о переходе на c++...
"value".hashCode() - отдельная няшечка.
П. С. это вам не getFillColor().length() > 0 )))))))
В команде джуниор?
Создаем final Property checkerExample=new PropertyImpl ("adequate");
Потом, значит, достаем откуда-то рефлексией аннотацию типа Property, которую мы написали в коде.
@Property ("mudak") User animeGovno;
Property mudakAnno=Govnokod.class.get...(...);
И сравниваем, для этого собстно hashCode и equals.
assert(!checkerExample.equals(mudakAnno) );
Примерно так.
static boolean equals(...) рулит.
Впрочем код не плюсовал.
Цитирую кусок документации:
Guice comes with a built-in binding annotation @Named that uses a string:
To bind a specific name, use Names.named() to create an instance to pass to annotatedWith:
П. С. Что самое прикольное оказалось - "... hashCode() specified in the Annotation Javadoc" 🙂
Вот это
http://www.cs.rice.edu/~mgricken/research/xajavac/
действительно круто.
Возможность писать так, не бенефит?
@interface And extends InvariantAnnotation {
InvariantAnnotation[] value();
}
@Or({@And({@OnlyThreadWithName("foo"), @OnlyEventThread}),
@OnlyThreadWithName("bar")})
void f() { }
>и в чем заключается крутость?
в совместимости с жавой
прямо как в http://govnokod.ru/6663
@OnlyThreadWithName("bar")})
void f() { }
по мне - это просто ЖЕСТЬ.
Clojure решает подобные проблемы отсутствием лишних абстракций: метаинформация символов представляется там в виде обычной мапы.