|
|
|
methods
|
|||
|---|---|---|---|
|
#18+
mozheyko_d ???[quot Blazkowicz] ... кладу в Object[] (int, float) ... Ого. Это как так? Может отрабатывает приведение типов? Автобоксинг наверное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 18:58 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
Timm Blazkowicz На кой хер если class[] можно получить из объектов которые находятся в Object[]? Чтобы не заморачиваться с примитивными типами. Выше уже говорили. Блин и точно ведь лажа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 18:59 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs Blazkowicz На кой хер если class[] можно получить из объектов которые находятся в Object[]? Это можно сделать, только если в методе нет аргументов простых типов (int, etc). О чём, собственно, уже написали... Честно говоря не предствляю практической ценности интерфейса у которого есть оверлоады различающиеся только прмитивом или враппером. Так что, ИМХО, в подавляющем большинстве случаев можно применить это допущение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 19:10 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
Пораскинул мозгами. Вот какая версия родилась. Создаем собствеенную аннотацию. Над каждым методом прописываем её с нужной строкой. Потом запускаем цикл, котороый перебирает все методы заданного интерфейса. У каждого метода получаем значение аннотации. И складываем в мапу Map<String, Method>. Ну, а после инициализации вытаскиваем по строке метод и инвок его к чертовой бабушке. Вроде бы вопросов с примитивами возникнуть не должно. Как вам вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 19:30 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 19:42 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
mozheyko_d NotGonnaGetUs А как искать ошибки если изменится сигнатура одного из 50 методов? Проблема проектирования Это зависит от того кто является инициатором запроса к методу. Как вариант для клиент сервера можно использовать один и тот же интерфейс на клиенте и сервере. Тогда будет гарантия что у них одни и те же параметры. А вот внутренности между этими двумя уже будут заниматся всякой нужной ерундой. В любом случае на этот вопрос можно ответить только зная для чего всё это городится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 19:49 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
LINUXERЕсть интерфейс в котором за 50 методов Есть метод в котором нужно в зависимости он заданной строки выбрать какой из методов того интерфейса нужно запустить Есть ли более изящное(простое) решение чем использование рефлекшена? Если не секрет можно расказать какая среда у этой задачи? Какую проблему эта реализация должна решать? Проблему в реальном мире а не абстракцию связывания строки и метода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 19:51 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
2 Blazkowicz КРрасиво. ИМХО это хуже чем решение "в лоб": аннотации надо поддерживать (и JVM-ой, и в коде)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2006, 19:59 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
Blazkowicz LINUXERЕсть интерфейс в котором за 50 методов Есть метод в котором нужно в зависимости он заданной строки выбрать какой из методов того интерфейса нужно запустить Есть ли более изящное(простое) решение чем использование рефлекшена? Если не секрет можно расказать какая среда у этой задачи? Какую проблему эта реализация должна решать? Проблему в реальном мире а не абстракцию связывания строки и метода. Природа задачи весьма абстрактна. Мне казалось это будет совсем просто. На практике встречался с подобными задачи например проверка форм (веб-интерфейса БД) перед формированием объектов (с последуйщей отправкой в базу): туча сеттеров хотя проверка однотипна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 09:49 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs LINUXER NotGonnaGetUsлучше заменить один класс с 50 методами, на 50 классов Думаю это в любом случае не оправдано :D Чем 50 if else лучше? Хуже. Портит инкапсуляцию и вообще бардак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 09:51 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
LINUXER NotGonnaGetUs LINUXER NotGonnaGetUsлучше заменить один класс с 50 методами, на 50 классов Думаю это в любом случае не оправдано :D Чем 50 if else лучше? Хуже. Портит инкапсуляцию и вообще бардак. А почему тогда "не оправдано"? С аннотациями, кстати, отпадает необходимость в создании классов, но при этом сохраняется идея универсализации процедуры поиска метода по строке. (нужно только изменить сигнатуру слегка: Object invoke(String action, Facade target, Object... args)) Сказочные перспективы открываются :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 11:47 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs А почему тогда "не оправдано"? Блин, в смысле, конечно, if else лучше такого изврата, ещё лучше простой reflection как в первом варианте(в простых случаях) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 13:01 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
LINUXER NotGonnaGetUs А почему тогда "не оправдано"? Блин, в смысле, конечно, if else лучше такого изврата, ещё лучше простой reflection как в первом варианте(в простых случаях) Чем "простой рефлекшн еще лучше if else"? и почему только в простых случаях? он покрывает все случаи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 13:06 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
LINUXER NotGonnaGetUs А почему тогда "не оправдано"? Блин, в смысле, конечно, if else лучше такого изврата, ещё лучше простой reflection как в первом варианте(в простых случаях) А можешь простенько объяснить в чём "изврат" ? Если не трудно, то с примерами кода. Мне очень интересно почему 50 if else и один класс для 50 операций не нарушают "инкапсуляцию" и не создают "бардак", а 50 классиков (по одному на операцию) делают и то и другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2006, 16:09 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
2Timm if else дают много кода в месте вызова. Конечно можно его генерить, но если вынести общее, то вызывать методы можно одним вызовом рефлект-метода что ИМХО очень удобно и понятно 2NotGonnaGetUs Много классов не создают много кода в месте вызова Если их вынести в отдельный pakage то они даже не будут мешаться Проблема в том что методы объеденяют в интерфейсы(классов) не просто так, а потому что используют общие данные или имеют общую цель. (Например это сеттеры.) Можно дать им доступ к нужным данным и т. д. Но использовать классы не по назначению явно не удобно(в т ч для расширения). Также методы могут использоваться другими частями системы о которых я могу не знать. Т е я вижу такой подход идеологически не правильным, что может вызывать множество проблем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2006, 08:01 |
|
||
|
methods
|
|||
|---|---|---|---|
|
#18+
LINUXERЕсть интерфейс в котором за 50 методов Есть метод в котором нужно в зависимости он заданной строки выбрать какой из методов того интерфейса нужно запустить Есть ли более изящное(простое) решение чем использование рефлекшена?pattern decorator? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2006, 14:40 |
|
||
|
|

start [/forum/topic.php?fid=59&gotonew=1&tid=2148174]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
13ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 435ms |

| 0 / 0 |
