T>То есть иногда требуется иметь несколько имплементаций ОДНОГО интерфейса, типы и кол-во параметров одного из методов которого в compile time не известны.
Блин, ну а я про что.
Re[21]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Trean, Вы писали:
T>>То есть иногда требуется иметь несколько имплементаций ОДНОГО интерфейса, типы и кол-во параметров одного из методов которого в compile time не известны.
B>Блин, ну а я про что.
Моя твоя не понимать:
B>вот коллекция абсолютно разнотипных объектов у который общий только Object, это ИМХО, глупость.
Я как раз привел пример когда, как раз коллекция разнотипных объектов не глупость =) У меня такая коллекция может содержать к примеру объекты разного типа: Double, Integer, String как параметры и это не будет глупо (хотя я не исключаю, что есть и другие подходы).
Re[18]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Trean, Вы писали:
T>Пажалуйста:
T> public static <E> E[] alloc(Class<E> type, int numBands) { T> return (E[])Array.newInstance(type, numBands); T> }
T>Работает без ворнингов даже =)
А теперь давайте объясним это Jdk1.3.1 или 1.4.2.06, например
Даже если вам то удастся, объясните тогда jbuilder7, что есть такие классные ребята, как javac.exe и com.sun.tools.javac.Main
И не надо мне говорить про обновление личного машинного парка или ПО Я на оффтопинге по этому поводу уже всех собак Китая сьел и скоро модераторам сниться.
T>Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI)
Если нельзя ну никак сделать это через Method.invoke && Object[] либо
Command.Execute && ParamDescriptor[], то имхо в моих дилиетентских системах координат это выглядит как ошибка дизайна.
Кстати вариант с ParamDescriptor — толстое пузатое заплывшее избыточностью безобрзие (вид в тех же координатах).
Потому что Class можно не хранить отдельно — это дело getClass().
А строковые имена-описания — debug-only requements.
я бы сделал так:
public interface CommandTemplate implements Serializable {
public String getParameterName(int index);
public Class getParameterType(int index);
public Object getDefaultValue();
public boolean isParamRequired(int index);
public int paramsCount();
}
И мэппинг сделать — класс -> CommandTemplate,
класс реализует интерфейс Command.
класс при свой загрузке регестрирует себя вшаблонозранилище, генеря про себя шаблон.
а при сериализации передаются тоько чтонить вроде Object[].
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Здравствуйте, Trean, Вы писали:
T>>Пажалуйста:
T>> public static <E> E[] alloc(Class<E> type, int numBands) { T>> return (E[])Array.newInstance(type, numBands); T>> }
T>>Работает без ворнингов даже =)
ВП>А теперь давайте объясним это Jdk1.3.1 или 1.4.2.06, например ВП>Даже если вам то удастся, объясните тогда jbuilder7, что есть такие классные ребята, как javac.exe и com.sun.tools.javac.Main ВП> ВП>И не надо мне говорить про обновление личного машинного парка или ПО Я на оффтопинге по этому поводу уже всех собак Китая сьел и скоро модераторам сниться.
T>>Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI) ВП>Если нельзя ну никак сделать это через Method.invoke && Object[] либо ВП>Command.Execute && ParamDescriptor[], то имхо в моих дилиетентских системах координат это выглядит как ошибка дизайна. ВП>Кстати вариант с ParamDescriptor — толстое пузатое заплывшее избыточностью безобрзие (вид в тех же координатах). ВП>Потому что Class можно не хранить отдельно — это дело getClass().
Ну я писал быстро и не пытался мега-шаблоны применять (обычно все на интерфейсах делаю, а тут упростил до примитивизма)
Согласен достаточно дефолтового значения у которого можно получить тип, либо если нет такогового, то только Class (очепятался я с Object value)
ВП>А строковые имена-описания — debug-only requements.
Ну можно еще для запросов параметра у юзера
ВП>я бы сделал так: ВП>
ВП>public interface CommandTemplate implements Serializable {
ВП> public String getParameterName(int index);
ВП> public Class getParameterType(int index);
ВП> public Object getDefaultValue();
ВП> public boolean isParamRequired(int index);
ВП> public int paramsCount();
ВП>}
ВП>
ВП>И мэппинг сделать — класс -> CommandTemplate, ВП>класс реализует интерфейс Command. ВП>класс при свой загрузке регестрирует себя вшаблонозранилище, генеря про себя шаблон. ВП>а при сериализации передаются тоько чтонить вроде Object[].
Да, согласен пожалуй так красивее и правильнее, просто я видел сановскую реализацию и привел ее как пример использования гетерогенных списков =)
С паттернами у меня проблема, что есть то есть (буду благодарен за книжку GoF в эл. виде =)
Re[17]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Пожалуй, если бы я знал, что есть какаянить штука типа Object[] newArrayOF(Class type, int length);, это было бы хорошо, а так для гарантии придётся сделать константрые массивы 0й длины
Так ведь такая штука есть в классе Array, она собственно в toArray и вызывается... а массив передаваемый и служит для получения type. Наверное я чего-то не просек =) Другое дело что из Object[] не получишь String[]
Кстати кто-нить знает чем отличаются (в том числе по скорости) System.arraycopy и clone() применненный к масиву?
Re[18]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Trean, Вы писали:
T>Кстати кто-нить знает чем отличаются (в том числе по скорости) System.arraycopy и clone() применненный к масиву?
Дело не в скорости, а в том что с помошью System.arraycopy элементы одного массива копируются в другой, а в случае с clone просто создается новый объект. Думаю что разница во времени, затраченном на создание нового объекта массива (которой, впринципе можно принебречь)
T>Ну я писал быстро и не пытался мега-шаблоны применять (обычно все на интерфейсах делаю, а тут упростил до примитивизма) T>Согласен достаточно дефолтового значения у которого можно получить тип, либо если нет такогового, то только Class (очепятался я с Object value)
ВП>>А строковые имена-описания — debug-only requements. T>Ну можно еще для запросов параметра у юзера
Когда есть шаблоны (описатели) команд, как понятие в системе, можно позволить себе даже такие извращения в них положить, как контекст для справки, значок, итп итд. Потому что такой описатель будет в 1 экземпляре храниться 91 описатель -> 1 класс).
НО! 98 классов напишешь нормально и не забудешь вызывать registerTemplate, а на 99м классе забудешь и всё, кирдык. В смысле такие шаблоны вводят сложности при кодировании, поэтому из классов объекто сообщений я это всё подобное (шаблоны сообщений) вырезал нафиг. В логгерыпишу имя класса соббщения и имя компа-источника. Мне хватает.
ВП>>я бы сделал так: ВП>>
ВП>>public interface CommandTemplate implements Serializable {
ВП>> public String getParameterName(int index);
ВП>> public Class getParameterType(int index);
ВП>> public Object getDefaultValue();
ВП>> public boolean isParamRequired(int index);
ВП>> public int paramsCount();
ВП>>}
ВП>>
ВП>>И мэппинг сделать — класс -> CommandTemplate, ВП>>класс реализует интерфейс Command. ВП>>класс при свой загрузке регестрирует себя вшаблонозранилище, генеря про себя шаблон. ВП>>а при сериализации передаются тоько чтонить вроде Object[].
T>Да, согласен пожалуй так красивее и правильнее, просто я видел сановскую реализацию и привел ее как пример использования гетерогенных списков =)
Но опять таки поскольку это лишня работа при кодинге с забытывабельными однотипными строчками, то лучше ограничится рефлексией по мере потребности в mutability.
Нука, накодь 100-200 классов команд, и к кадому нацепи шаблон-описатель... Сам такого не делал и не собираюсь.
Вместо этого лучше в бд с кэшированием востребованых хранить. Так у тебя описатели будут в одном месте, а этак — по всему коду.
Кстати в КП в бд храню описатели действий, класс формы указан как полное (с пакетом) имя. Всё никак не дотяусь чтобы сделать форму регистрацию действий.
T>С паттернами у меня проблема, что есть то есть (буду благодарен за книжку GoF в эл. виде =)
Оно мене нужнее чем вам потому как по ходу курсового проекта я постоянно изобретаю самоходные орудия на коровьих лепёшках.
ВП>>publicinterface CommandTemplate implements Serializable {
ВП>> public String getParameterName(int index);
ВП>> public Class getParameterType(int index);
ВП>> public Object getDefaultValue();
ВП>> public boolean isParamRequired(int index);
ВП>> public int paramsCount();
ВП>>}
ВП>>
И никто не заметил...... (имплементирующий интерфейс — это в хумор надо) я и то,только случайно, 6й раз перечитывая тему.ююююю
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Здравствуйте, Trean, Вы писали:
T>>Ну я писал быстро и не пытался мега-шаблоны применять (обычно все на интерфейсах делаю, а тут упростил до примитивизма) T>>Согласен достаточно дефолтового значения у которого можно получить тип, либо если нет такогового, то только Class (очепятался я с Object value)
ВП>>>А строковые имена-описания — debug-only requements. T>>Ну можно еще для запросов параметра у юзера ВП>Когда есть шаблоны (описатели) команд, как понятие в системе, можно позволить себе даже такие извращения в них положить, как контекст для справки, значок, итп итд. Потому что такой описатель будет в 1 экземпляре храниться 91 описатель -> 1 класс). ВП>НО! 98 классов напишешь нормально и не забудешь вызывать registerTemplate, а на 99м классе забудешь и всё, кирдык. В смысле такие шаблоны вводят сложности при кодировании, поэтому из классов объекто сообщений я это всё подобное (шаблоны сообщений) вырезал нафиг. В логгерыпишу имя класса соббщения и имя компа-источника. Мне хватает.
Дело в том, что мне это необходимо в нескольких классах, не надо мне 98 классов писать =)
Я вообще сторонник принципа "Make recent things easy, rare things possible"
Я на оффтопинге по этому поводу уже всех собак Китая сьел и скоро модераторам сниться.
потому как по ходу курсового проекта я постоянно изобретаю самоходные орудия на коровьих лепёшках.