Какой шаблон дизайна следует использовать?

У меня есть некоторая функциональность, реализованная для хранения документов внутри базы данных.Какой шаблон дизайна следует использовать?

Теперь я хочу получить доступ к функциональности в своем модуле, но не напрямую.

Поскольку у меня есть FileInputStream со мной, и реализованная функциональность принимает строку JSON.

Итак, какой шаблон дизайна можно использовать для преодоления разрыва в входных параметрах?

Я знаю Адаптер является одним из ответов, но может ли кто-нибудь предложить что-нибудь еще?

Ниже приведен образец функциональности.

public interface DocumentService { 

    public String create(String jsonRequest); 

    public String search(String jsonRequest); 

    public String update(String jsonRequest); 

    public String fetch(String jsonRequest); 

}

источник

2014-01-13 Sam

... Не повесить трубку на то, что она называется, или какой официальный шаблон дизайна. Это не ракетостроение, вам нужно что-то, что идет от FIS к json. –

@DaveNewton Я точно знаю, что нужно что-то сделать, чтобы конвертировать из FIS в JSON. Я просто спрашиваю, является ли Адаптер единственным правильным выбором? Или даже это правильный выбор? – Sam

Зачем вам все равно, как это называется? Почему бы вам не создать объект, который будет делать то, что вам нужно, и либо создать новый объект с обоими, либо любым, что соответствует вашему точному шаблону использования (или, в конце концов, нет ничего, что говорит о том, что вы должны его правильно исправить в первый раз) и двигаться дальше? Вы повеситесь на ничего полезного: идите и двигайтесь вперед. –

Почему вы не используете шаблон DAO?

Передайте входной поток объекту DAO и преобразуйте его из потока ввода файла в JSON и вызовите методы создания.

http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm

источник

2014-01-13 11:55:49 Schokea

Просто сделайте частный метод Конвертирование

String toJSON(FileInputStream fs) { 
    ... 
}

Если вам случится нужен этот метод в нескольких местах переместить его в служебный класс.

Если этот единственный метод не является достаточно гибким для каждой ситуации, он необходим в прямо сейчас, тогда вы должны подумать о написании класса адаптера.

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

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

источник

2014-01-13 12:39:43 Ozan

Лично я отворачивался от этого, вместо этого разбивая классы, которые делают разные вещи. –

Похоже, что адаптер является хорошим выбором. Я буду двигаться вперед.

источник

2014-01-13 13:09:16 Sam

Для выяснения моих комментариев:

Попытки втиснуть каждый бит функциональности в явную «модель» не является продуктивным использование вашего времени.
Даже если это так, пытаясь найти идеальное «имя» для того, что вы на самом деле придумали, это не так.
Вам нужен вспомогательный класс, который преобразует FIS в JSON, и это все.
Вы могли бы составить службы, использующие этот помощник и ваш существующий класс, или ...
Составьте существующий класс в => JSON конвертер ФИС, или ...
Измените поток данных таким образом, чтобы вы передавать данные через фильтр, который JSONify, или ...

Другими словами, (а) «лучший» ответ зависит от вашей конкретной ситуации и (б) не имеет значения, что это называется. Сделайте что-то, положите его на полпути разумно, и если он окажется не совсем правильным, повторите его до тех пор, пока он не станет. Не теряйте время, пытаясь назвать «образец».

Это как броски и суставные замки: не ищите их, найдите их. Шаблоны скрыты в вашем приложении, обрабатывают их и реализуют.

источник

2014-01-13 14:57:18

Какой шаблон дизайна следует использовать?

ответ

Смежные вопросы