Если я правильно прочитал, вы говорите о проблеме, решаемой шаблоном Интерпретатор , но в некотором роде.
Есть несколько простых способов получить приятные универсальные интерфейсы, чтобы вы могли запустить остальную часть. Моя рекомендация на это что-то вроде:
public interface Interpreter<OutputType> {
public void setCode(String coding);
public OutputType decode(String formattedData);
public String encode(OutputType rawData); }
Однако есть несколько препятствий с конкретными реализациями. Например, вам может потребоваться указать «9/9/09», «9 сентября 09», «9 сентября 2009 года». Первый «вид» даты прост - числа и набор символов делителя, но любой из двух других довольно неприятен. Честно говоря, делать что-то совершенно общее (которое уже можно было бы консервировать), вероятно, нецелесообразно, поэтому я рекомендую следующее.
Я бы атаковал его на двух уровнях, первый из которых довольно прост с регулярным выражением и форматной строкой: объединение строки данных в вещи, которые собираются стать необработанными данными. Вы должны указать что-то вроде «D * / M * / YY» (или «M * / D *») для первого, «D * MMM YY» для второго и «Mm + D * e *, YYYY» для последнего, где вы определили в своих данных некоторые зарезервированные символы (D, M, Y, очевидные интерпретации) и для всех типов данных (* возможно несколько символов, + "полный" вывод, e определены посторонние символы) - эти символы очевидно, быть конкретным для вашего приложения. Затем ваш материал для регулярных выражений будет скомпоновывать строку, передавая все, что связано с каждым зарезервированным символом, в отдельные поля данных и сохраняя часть оформления (запятые и т. Д.) В некоторой строке форматирования.
Этот первый уровень может быть достаточно общим - каждый тип данных (например, дата, координата, адрес) имеет зарезервированные символы (которые не пересекаются ни с какими символами форматирования), а все типы данных имеют некоторые общие символы. Возможно, интерфейс Интерпретатора также будет иметь методы public List<Character> reservedSymbols() и public void splitCode(List<String> splitcodes) или, возможно, гарантированные поля, чтобы вы могли сделать разделитель внешним классом и передать результаты.
Второй уровень не так прост, потому что он касается той части, которая не может быть общей. На основе формата зарезервированных символов отдельные поля должны знать, как представлять себя. В примере с датой MM сообщит месяцу, который будет напечатан как (01, 02, ... 12), M * как (1, 2, ... 12), MMM как (JAN, FEB, ... DEC) Ммм, как (январь, февраль, ... дек) и т. Д. Если ваша компания была несколько последовательной или не отходит слишком далеко от стандартных представлений материала, то ручное кодирование каждого из них не должно быть слишком плохим (и на самом деле, в каждом типе данных, вероятно, есть разумные способы уменьшить количество реплицируемого кода). Но я не думаю, что практично обобщать все эти вещи - я имею в виду, фактически представляя то, что может быть представлено в виде числа или символов (например, месяцев) или целых данных, которые могут быть выведены из частичных данных (например, столетие из года ) или как получить усеченные представления из данных (например, усечение для года до последних двух цифр, а большинство нормальных чисел усекается до двух старших цифр), вероятно, займет столько же времени, сколько и почерк в этих случаях, хотя, думаю, я могу Представьте себе случаи вашего приложения, компромисс может стоить того. Дата - действительно хитрый пример, но я, безусловно, вижу такие же хитрые вещи для других типов данных.
Резюме:
- это простое общее лицо, которое вы можете обозначить своей проблемой, поэтому остальная часть вашего приложения может быть закодирована вокруг него.
- существует довольно простой и общий разбор первого прохода, имеющий универсальные зарезервированные символы, а затем зарезервированные символы для каждого типа данных; убедитесь, что они не сталкиваются с символами, которые будут отображаться при форматировании
- есть несколько утомительный финальный этап кодирования для отдельных битов данных