Массивы массивов в Java

Кажется, что все пытаются найти Java способом сделать это как, Вы делаете его в PHP вместо способа, которым это должно быть сделано в Java. Просто считайте каждую часть своего массива объектом, или, по крайней мере, первым уровнем массива как объект и каждый sub уровень как переменные в объекте. Сборка структура данных, которую Вы заполняете с упомянутыми объектами и получаете доступ к объектам через данные средства доступа структуры данных.

Что-то как:

class Schedule
{
  private String group;
  private String season;
  private String rundays;
  public Schedule() { this.group = null; this.season = null; this.rundays= null; }
  public void setGroup(String g) { this.group = g; }
  public String getGroup() { return this.group; }
  ...
}

public ArrayList<Schedule> schedules = new ArrayList<Schedule>();
Schedule s = new Schedule();
s.setGroup(...);
...
schedules.add(s);
...

, Конечно, который, вероятно, не является правильным также. Я сделал бы каждый сезон объектом и возможно каждый будний список как объект также. Так или иначе, его более легко снова использованный, понятый и расширяемый, чем Хеш-таблица, которой вместе создают помехи, которая пытается подражать Вашему коду PHP. Конечно, PHP имеет объекты также, и необходимо использовать их подобным способом вместо uber-массивов, по мере возможности. Я действительно понимаю искушение обмануть, все же. PHP делает его настолько легким, и таким образом забава!

Вот один способ, которым это могло быть похожим, можно понять остальных:

A = new Group();
A.getSeason(Seasons.WINTER).addDay(Days.MONDAY);
A.getSeason(Seasons.SPRING).addDay(Days.TUESDAY).addDay(Days.THURSDAY);
A.getSeason(Seasons.SPRING).addDays(Days.MONDAY, Days.TUESDAY, ...);

schedule = new Schedule();
schedule.addWateringGroup( A );

Не пытайтесь быть столь же динамичными, как PHP. Вы могли попробовать к первому , определяют , в чем Вы нуждаетесь.

interface Season
{
    public string getDays();
}

interface User
{
    public Season getWinter();
    public Season getSpring();
    public Season getSummer();
    public Season getFall();
}

interface UserMap
{
    public User getUser(string name);
}

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

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

, В чем Bruce нуждается, в, он - основа, просто справочная таблица. Ему не нужна иерархия объектов и интерфейсов; ему нужен способ искать расписание на основе сезона и идентификатора группы. Превращение вещей в объекты только имеет смысл, если у них есть обязанности или состояние. Если у них нет ни одного, то они - просто идентификаторы, и создающий специальные объекты для них просто делает кодовую базу больше.

Вы могли сборка, например, Group объекты, что каждый содержит ряд строк расписания (один в течение каждого сезона), но если весь эти Group объект делает, обеспечивают функциональность поиска, то Вы переосмыслили справочную таблицу намного менее интуитивным способом. Если он должен искать группу и затем поиск расписание, все, что он имеет, двухступенчатая справочная таблица, которая заняла больше времени для кодирования, более вероятно, будет багги и будет более тверда поддержать.

Я с теми, которые предлагают инкапсулировать функцию в объектах.

import java.util.Date;
import java.util.Map;
import java.util.Set;

public class Group {

    private String groupName;

    private Map<Season, Set<Day>> schedule;

    public String getGroupName() {
        return groupName;
    }

    public void setGroupName(String groupName) {
        this.groupName = groupName;
    }

    public Map<Season, Set<Day>> getSchedule() {
        return schedule;
    }

    public void setSchedule(Map<Season, Set<Day>> schedule) {
        this.schedule = schedule;
    }

    public String getScheduleFor(Date date) {
        Season now = Season.getSeason(date);
        Set<Day> days = schedule.get(now);
        return Day.getDaysForDisplay(days);
    }

}

РЕДАКТИРОВАНИЕ: Кроме того, Ваши диапазоны даты не принимают високосные годы во внимание:

Наши сезоны похожи на это: Лето (5-1 к 8-31) Spring (3-1 к 4-30) Падение (9-1 к 10-31) Зима (11-1 к 2-28)

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

, Если использование назвало константы, где, например:

int A = 0;
int B = 1;
int C = 2;
int D = 3;

int Spring = 0; 
int Summer = 1;
int Winter = 2; 
int Fall = 3;
...

Затем константы служат большим количеством читаемых нижних индексов массива:

schedule[A][Winter]="M";
schedule[A][Spring]="tTS";
schedule[A][Summer]="Any";
schedule[A][Fall]="tTS";
schedule[B][Winter]="t";

Используя перечислимые типы:

enum groups
{
  A = 0,
  B = 1,
  C = 2,
  D = 3
}

enum seasons
{
  Spring = 0,
  Summer = 1,
  Fall = 2,
  Winter = 3
}
...
schedule[groups.A][seasons.Winter]="M";
schedule[groups.A][seasons.Spring]="tTS";
schedule[groups.A][seasons.Summer]="Any";
schedule[groups.A][seasons.Fall]="tTS";
schedule[groups.B][seasons.Winter]="t";

"Дата" должна быть параметром? Если Вы просто показываете, что текущий полив планирует сам класс WateringSchedule, может выяснить, какой день это, и поэтому каково сезон это. Затем просто имейте метод, который возвращает карту, где Ключ является буквой группы. Что-то как:

public Map<String,List<String>> getGroupToScheduledDaysMap() {
  // instantiate a date or whatever to decide what Map to return
}

Затем на странице

<c:forEach var="day" items="${scheduler.groupToScheduledDaysMap["A"]}">
   ${day}
</c:forEach>

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

Я соглашаюсь, что необходимо определенно поместить эту логику позади чистого интерфейса:

public String lookupDays(String group, String date);

, но возможно необходимо засунуть данные в файл свойств. Я не против жесткого кодирования эти данные в Ваших исходных файлах, но, как Вы заметили, Java может быть довольно многословным когда дело доходит до вложенных Наборов. Ваш файл мог бы быть похожим:

Summer=M
Spring=tTS
B.Summer=T

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

, Если Вам не нравится эта идея, возможно, можно сделать что-то вроде этого:

public class WaterScheduler
{
  private static final Map<String, String> GROUP2SEASON = new HashMap<String, String>();
  static
  {
    addEntry("A", "Summer", "M");
    addEntry("A", "Spring", "tTS");
    addEntry("B", "Summer", "T");
  }

  private static void addEntry(String group, String season, String value)
  {
    GROUP2SEASON.put(group + "." + season, value);
  }

}

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

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

Используя базу данных будет намного легче поддержать, и существует разнообразие из свободно база данных механизмы для выбора из.

Два из этих механизмов базы данных реализованы полностью в Java и могут быть встроены в приложение только включением файла банки. Это - маленький тяжеловес, уверенный, но это намного более масштабируемо и легче поддержать. Просто, потому что существует 20 записей, сегодня не означает, что там не будет больше позже из-за изменяющихся требований или излишнего усложнения.

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

Нет никакого симпатичного решения. Java просто не делает вещей как это хорошо. Решением Mike's является в значительной степени способ сделать это, если Вы хотите строки как индексы (ключи). Другая опция, если установка хеша хешей слишком ужасна, состоит в том, чтобы добавить строки вместе (бесстыдно украденный от Mike и измененный):

Hashtable<String, String> schedule = new Hashtable<String, String>();
schedule.put("A-Winter", "M");
schedule.put("A-Spring", "tTS");

и затем поиск:

String val = schedule.get(group + "-" + season);

, Если Вы недовольны общим уродством (и я не обвиняю Вас), поместите все это позади вызова метода:

String whenCanIWater(String group, Date date) { /* ugliness here */ }