Некоторые вопросы относительно реализации канала и фильтра - PullRequest
Новая
       15

Некоторые вопросы относительно реализации канала и фильтра

2 голосов
/ 28 ноября 2010

Я собираюсь разработать компонент под названием ExtractInfoFromUrl.Этот компонент имеет метод с именем addUrl(url), который принимает URL-адреса и открывает данный URL-адрес и извлекает информацию из соответствующей страницы, вызывая событие по завершении.Внутренне компонент состоит из труб и фильтров.

У меня есть 3 вопроса:

  1. Я хотел бы знать, что было бы лучше - иметь каждый Filter имеют Thread (то есть в Java наследуются от Thread) или имеют Pipe s Threads?

  2. Очевидно, что я будудолжны быть мои фильтры или мои трубы с резьбой.Но разве мне не придется использовать Thread для самого компонента?Мне нужен поток, который управляет другими, и я считаю, что поток основной программы не подходит для этой задачи, но я не слишком уверен, почему.

  3. Есть ли какой-либо другой видРеализация Java для PipedReaders / Writers, которая позволяет мне обрабатывать другие виды данных вместо char / int?Это слишком низкий уровень для меня, я бы сказал.Если бы были какие-то другие, которые вместо этого позволили бы строки, например, это было бы предпочтительнее.

Спасибо

Ответы [ 2 ]

2 голосов
/ 28 ноября 2010

  1. С одной стороны, обычно предпочтительнее реализовать Runnable, чем расширять Thread, но, несмотря на это, я не думаю, что вы захотите, чтобы ваши фильтры или каналы расширяли Thread или реализовывали Runnable, а вместо этого имели каждую трубу использоваться в новой теме.

  2. Что вы подразумеваете под «компонентом»? Вы имеете в виду визуализированный компонент GUI? Или что-то другое?

  3. Я завернул PipedWriters в PrintWriter

1 голос
/ 28 ноября 2010

Концептуально фильтры представляют вычисления в архитектуре «фильтр-труба», поэтому я думаю, что имеет смысл связывать потоки с фильтрами (если потоки используются вообще).Каналы - это «коммуникационная» часть шаблона.

Опять же, концептуально, если информация, извлеченная из найденной страницы, не зависит от каких-либо других данных, то использование потоков для них имеет смысл только в случае многопроцессорности.Я также не уверен, почему существует необходимость в главном потоке - возможно, вы можете уточнить.

Вместо использования низкоуровневых устройств чтения / записи, почему бы не рассмотреть очереди сообщений?

...